Great Leaders Ask Great Questions

May 20, 2016 by lsmit@wemanity.com in  Blog

For the last few years, I’ve been working with and studying some of the best teams in the world; Red Arrows teams, SAS and US Navy SEAL units, Racing yacht crews, a Formula One pit crew, etc. I set out to study teamwork. In particular, I wanted to know how these teams have become world class. In the course of my studies, I identified six common characteristics, which differentiated these incredible teams.

Interestingly, I didn’t set out to study world class leadership. However, when I found world class teams, I also found world class leadership (I know, I probably should have expected that!). So, as well as studying teamwork, I also began to look at the characteristics that differentiated world class leadership. One of the most powerful insights that I discovered is this…

Great Leaders Ask Great Questions.

In fact, the great leaders that I encountered often didn’t provide any answers! Instead, they realise that the group has the potential to generate a better answer than they could on their own. It’s a principle that James Surowiecki outlines in his book, Wisdom of Crowds. When I shared this idea at an educational conference last year, a Head Teacher responded by saying, “That’s rubbish. Are your trying to tell me that Einstein should ask his class for the answer, and that the class will have a better answer than Einstein?”. “No”, I said, “Einstein is part of the class. So by engaging the class you get Einstein plus the class, not instead”.

Knowing that great leaders ask questions is one thing. Knowing what constitutes a ‘Great Question’, is another. So, what makes a question ‘Great’?

Here are some of my thoughts and reflections…

To me, ‘Great Questions’ are simply the right question, asked at the right time. To ask great questions, we need to understand the problem we’re trying to solve and where we are in the process. Do we need to ask a strategic question, or a tactical question, or one that’s related to implementing and executing a plan?

Strategic Question – Why?

Tactical Questions – What? …. How?

Action & Implementation Questions – Where? …. Who? …. When?

Very simply, it makes sense to understand why we are doing something (and whether we should be doing it), before deciding what we’re doing or how we will do it? Equally, it makes sense to know what we’re going to do, before deciding who will do it, when and where.

To me, ‘Great Questions’ are also well defined and simple. Sometimes it takes time and thought to frame a question well. The world class leaders that I saw at work often ask simple questions, which engage their team to collectively solve a problem. Some of the most powerful questions I’ve heard simply begin with the words, “How could we…?”.

To find out more, read Stronger Together; How Great Teams Work and hear from world class leaders sharing their wisdom on Be World Class TV.

By: Simon Hartley, Founder of Be World Class.

http://www.be-world-class.com/node/251

Why we should lean into risk in Brexit Britain

May 10, 2016

I was going to write a blog about risk. I’d whip through the theory, focus on the practice, and back it up with science.

Then the referendum happened. And now, depending on your view, the country’s either deep in the mire, or free to succeed. The markets have crashed, but might bounce back. Hate crime is up, but might be a blip. We’re living in uncertainty, and we don’t even know how long it’ll last.

All of that feels uncomfortable and risky. So to write about risk without acknowledging the uncertainty around us feels a bit absurd. We’re already awash with political analysis, so I won’t add mine. But whether you’re delighted, devastated or unmoved by these events, it’s an interesting moment to take a look at the parallels with organisational and personal change.

Major change throws the status quo in the air. Before it settles, as it inevitably will, we can make some choices. We can pretend it’s not happening. We can choose to step back and see where the pieces fall. And we can choose to take a risk and lean into uncertainty. These are decisions organisations are making now – as they’ve done before and will again. Individuals are doing the same.

Unless you’re very lucky, pretending nothing’s changed will leave you baffled, and your colleagues disengaged. It’s also, counter-intuitively, a lot of effort. Our ability to adapt is part of what defines us as human. So while adapting might be hard, refusing to is exhausting. Sometimes, of course, the wisest move is to hold your horses and wait for a new normal. But you forfeit the chance to shape it, and risk being left behind.

Choosing to shake hands with uncertainty can be complicated and uncomfortable. It can also be profoundly creative. If you can lean into that, there’s scope to experiment with new ideas and products, have different conversations and make unexpected connections. You might fail, you might succeed, you might create something a bit… ‘meh’. But you only find out if you take the risk. And whether or not it’s sparked by external events, embedding a culture of testing, adapting and improving will reap benefits well into the future.

Thing is, it’s not easy. There’s a gap between intention and doing. And however much you want to, crossing it can seem boring, painful and hard work. And once you do cross it, there’s no guarantee it’ll work. Ugh. Why bother? It’s somehow easier to feel disrespected afterwards than to challenge in the moment. To feed back to your friends instead of your colleagues. To work within stasis than to venture an alternative.

But that ‘ugh’ is worth the bother. It’s when things shift, and when you learn. Plus you reinforce in yourself and colleagues that, whatever the outcome, you are people with the agency to create change. You’ll be more likely to do it again, helping build a culture of creativity in yourself and others.

So where to begin? Here are three initial suggestions.

1. Acknowledge fears, but don’t draw them out. Give yourself three minutes to project the potential range of outcomes from best to worst. Then begin, ditch or adapt. You’ll only find out what actually happens by taking the risk, so don’t waste time on the fundamentally unsound, or delay the great.

2. Solicit feedback; ask, listen, learn, adapt. And be specific: work out exactly what you want feedback on, and ask questions within a clear remit. This shifts the focus away from egos (easily crushed, despite denials) and towards ideas. Seeking feedback can feel like a massive risk in itself. But the more you do it, the easier and more useful it becomes.

3. Build networks. It’s exhausting taking a risk on your own and it takes ages. Talk to people who disagree: diverse opinion makes for robust ideas. And test the idea as soon as you can, drawing on your network for support. Make sure your network includes people unconnected to your idea, but who can help you reflect on progress and remain resilient. Action learning sets and peer mentors are ideal.

I’m not suggesting all ideas are sensible or risks worth taking. But change is definitely coming. New systems, new products and even new industries may emerge. I hope that as organisations and individuals we’ll be inspired to lean into risk when we encounter it. Start experimenting, adapting, innovating. The status quo has been shaken, and will rebuild. The space in between is yours to shape.

By: Kamala Katbamna from Chirp

http://www.chirp.org.uk/new-blog/2016/6/29/risk-taking-in-a-post-brexit-britain

Brace yourself Spark the change is coming..To France!

Nov 22, 2017

 

 

Also published on Medium.

Nine things I didn’t know nine years ago

May 19, 2016

 

Image from page 400 of “The Palm of Alpha Tau Omega” (1880)

It’s coming up on nine years since I first started slinging code in a professional setting. Professional here meaning with a salary, in an office, with other engineers, decent coffee and unreasonable deadlines.

Back then I was barely newly minted from school, and what I lacked in understanding I certainly carried in hubris. I remember being vaguely offended not to be on the list of Sweden’s top coders that year. No idea how they would’ve found me, but I still remember being annoyed by it.

What I’ve lost in hubris in the last nine years, I’ve gained in experience. I thought it’d be useful to punch down a few things that it would have been nice to know nine years ago — maybe it can help you, if you’re just about to take your first steps out of school.

In no particular order, here are nine things I wish I’d known when I started out:

  1. Experience counts for something. This is obvious, and maybe a bit condescending. But I remember the first time I saw a colleague in a live, heated situation pull up YourKit and hone in on the fact that we’d have two ServerInstanceFactories, not one, and that caused the entire app to go belly up. Or when I got literally smacked on the fingers for not using two-phased locking correctly. And a thousand other things. My first two years of working, what I mainly learned was that I basically didn’t know shit.
  2. People are messy. I’d love to know how many hours humanity as a total spends every day mediating between two or more angry 40-year old men. Most of the time, you’ll find reasonable people that don’t share your point of view on things, and you are not obviously right. There are tradeoffs. And sometimes people hold on to stupid ideas longer than they should, simply because they’re people. It’s a great irony that software development demands literal, logical, unambiguous reasoning while being complicated enough that you need to collaborate with ornate, arbitrary, ambiguous humans.
  3. You’re not logical, you’re biased. If there was one thing I was certain of was that I reasoned with logic and soundness and that I thought things because they were true. Things such as — we hire people only because of merit. Obviously. What I’ve learned is that any point can be argued from many angles, and who I am, where I was raised, what I studied and who my friends are all influence what I think is obviously true. I’ve also learned that I’ll likely never be Spock, and that the only reasonable defense is to invite different points of view, and accept that reasoning from different premises can lead to different conclusions, and still be logical and sound.
  4. You can use engineering for other stuff. As a flipside to above, I’ve also learned that the method of engineering that you learn in school and hone over the years is useful for a ton of other stuff than just programming. What engineering is to me is a way to define, decompose and reduce a problem space, and from that reason a solution under balanced constraints. Really, figuring out what you’re asking, and then answering that. And turns out that anything from sales, marketing, finance, design to analytics are super-susceptible to this. Don’t be afraid to dive in. It’s usually pretty simple to get stuck in.
  5. Users are not stupid. This one is a big one. When users complain about your product, it’s usually not because they’re stupid. Your dad, uncle or whatever that don’t really understand Facebook are not stupid. They just know other shit, and they haven’t learned this stuff yet. And that’s Facebook. They have literally hundreds of user researchers making Facebook simple. When your uncle doesn’t understand your app, it’s probably because it’s pretty unusable. Don’t blame users for that.
  6. Engineers have professional responsibilities. If you work with software in a company that makes money, chances are you have users. Even if you’re building Spotify, not a pacemaker, you still have a responsibility to your users. They’ve chosen your product, and if it sucks, they’re suffering and it’s your fault. This means that if you’re out chugging beer, the systems you maintain go down, and no one else can pick them up, you get a cab home and fix it. Obviously, don’t let a company take advantage of this responsibility. You should get reasonably compensated. But it’s still a responsibility. You can’t laugh off service disruption.
  7. Inverting a tree is useful, but not in the way you think it is. I’ve always been a strong believer in academic knowledge, and I loved taking the hardest courses. Particle filtering, non-linear signal processing, abstract algebra, advanced algorithms, etc. If it looked hard I wanted to know it. However, the point of Red-Black trees is not Red-Black trees. The point of graph traversal is not graph traversal. The point is, the tools you have shape how you solve problems. And the deeper the understanding of graphs you have, the easier it will be for you to see that a problem is a graph problem. Just like if you know enough economics, you can see business problems as market problems. And so on.
  8. Integrating early is always better. This is really mundane compared to all the other grand advice, but if you’re a bunch of people working on a piece of code, avoid branches and avoid submodules as much as possible. It’s really not better to work on your own branch until all is nice and then merge back. Merge early. Merge often. Otherwise you’ll spend a month merging. I promise. Like, I really, really promise … and actually, I guess there is grand life advice here as well. If you and someone you depend on disagree on something fundamental, don’t hold a grudge. Hash it out, as early as possible. Make sure you see eye to eye. The process and the product will be all the better for it.
  9. Simpler is literally always better. I saw someone write something like “Software engineers spend their first two years building complexity, and the rest of their careers managing it”. This is true. Really true. If you can avoid it, never write a dispatcher. Never write an orchestration framework. Don’t use Java if a bash script will do. Solve the problem you have now, not the problem you might have later. Nothing makes you feel as smart as a well architected, abstract framework for solving really complicated, general problems. Nothing makes you feel as stupid as not understanding how to debug it.

Anyway. This is my list. The nine things I wish I knew nine years ago. It strikes me now that current me would love to see the list Nine Things I Wish I’ll Remember In Nine Years. What stuff have I forgotten that would warp my perspective? I’d love to hear your take on either this, or what I missed on this list.

By: Marcus Frödin from Spotify

https://medium.com/@marcusf/nine-things-i-didn-t-know-nine-years-ago-fcbc757b268b#.9xksp8f8t