Great Leaders Ask Great Questions

May 20, 2016 by 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.

Free the office slaves

Mar 29, 2016

Free the office slaves: No more working day.

The 9-5 working day has come to signify office slavery.

In actual fact though, most knowledge workers work longer than 8 hours a day. A 2011 survey (ASHE) suggests that the average manager in the UK works over 9 hours per day, while extreme hours among certain groups (bankers and lawyers in particular) regularly involved sustained periods of working up to 120 hours a week.

What do set working hours signify?

Extreme hours hurt us. A study by Alexandra Michael, published in 2012, followed investment bankers over a 9 year period. The report concluded that people suffered physical, mental and emotional problems, including depression, a greater number of sick days and relationship breakdown.

Even normal hours often hurt us though. Studies suggest that those in the office spend a large proportion of their time unproductively. They might be checking personal emails or social media sites, or simply carrying out their basic work in a very un-productive fashion. Anyone spent ages staring at a spreadsheet unable to make head or tail of it? Ever fallen asleep in a meeting when supposed to be coming up with ground-breaking new ideas?

The energy cycle

Energy, creativity and brilliance rarely arrive on demand. Instead, human beings work in cycles. We can focus for limited amounts of time. After that we need rest in order to recover.


The ‘ultradian’ pattern, as it is known, normally depends on working in cycles of 90 minutes, with energy troughs in between – normally of about 20-30 minutes. The working day takes no notice of this, however.

Sometimes of course, we enter that wonderful state that Mihaly Csikszentmihalyi referred to as ‘flow’ – where we are hardly aware of the passing of time because we are so absorbed by what we are doing. When we manage to achieve this, the idea of cutting it off with a commute home or a lunch hour seems crazy.

Manage energy, not time

Radical companies understand the need to manage energy, not time. Sometimes that means that workers can work far in excess of the normal working day – developer stories of being so absorbed in a problem they didn’t leave the office until 3am are common. At other times it means workers do far less than the traditional 8 hours and in a different way – starting late, for example, leaving early to pick up children; taking a walk.

No working day means that life and work are more closely blended. It’s not unusual for radical managers to answer emails late at night or to come up with ideas as they sit on a beach with their family. They are not oppressed by this (“oh no! the phone is beeping again!”), partly because they are just as capable of taking a nap when they feel like it or running errands in the middle of what others would call the ‘working day’.

Being Radical

Leo Widrich is a co-founder of Buffer, a company which allows people to manage multiple social media accounts more easily. He manages his own day by splitting it into 90-minute windows and then achieving a certain number of tasks – one per window. A side benefit is that this helps increase focus on just one task at a time, eliminating much of the cost of task-switching. He then tries to plan his rest periods. Instead of allowing these to be filled up with emails or meetings, he goes out for a snack or reads a book. This ensures genuine downtime that allows the brain to recharge and creative ideas to swim up from the subconscious.

So what should we do?

It’s simple really – set people free to work as much as they want, when they want.

There’s no need to say ‘do you mind if I leave early today because blah blah blah’. Just go. It can help to share with others what you’re doing and how to get hold of you so they can co-ordinate with you, but there’s no need to ask permission.

Nor is there any need for that irritating parade of being the last to leave the office, or the first to get there. If someone is emailing late at night it’s because she had a thought and wanted to communicate it, not to demonstrate how dedicated she is.

Some managers might start sweating in light anxiety. How do you know the person won’t bunk off, won’t take advantage, won’t drop their productivity etc.? The answer is that regardless of hours put in people know if someone isn’t pulling their weight or isn’t performing. You can still ask poorly performing people to buck up or get out. But most people want to do well and want the company to do well so they work hard, but you’ve created an environment that helps them work effectively.

You can just trust them.

And just that one piece of advice – trust – frees up a lot of your own time in or out of the working day.

By: Helen Walton from Gamevy

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

Spark the Change : inspirer les entreprises françaises grâce à des retours sur expérience concrets

May 14, 2018

Selon un sondage récent de l’Ifop, 91 % des jeunes cadres français pensent que leur entreprise est en train ou va se transformer. Mais pour 47 % des entreprises, la transformation reste aujourd’hui synonyme de « digitalisation ». Elle ne concerne l’évolution du style de management que dans 21 % d’entre elles et la relation client dans seulement 20 %. Pourtant, ces cadres pensent que la priorité devrait être mise sur l’évolution des modes de rémunération des salariés (37 %), l’évolution des styles de management (33 %) et la formation et le développement de compétences (33 %).

Les jeunes cadres français ont bien compris que loin de se cantonner à la digitalisation des processus, la transformation concerne de nombreux aspects de la vie de l’entreprise, et surtout sa culture et son organisation. « Une entreprise ne peut réussir sa transformation digitale si elle n’a initié une profonde transformation en interne » explique Jean-Christophe Conticello, fondateur et CEO de Wemanity.

« L’apparition d’Internet et des technologies associées a bouleversé en profondeur le monde de l’entreprise. Les modes de consommation ont évolué, le temps s’est accéléré, ce qui a entrainé également une profonde évolution des modes de travail. La nécessité de changer est devenue vitale : on ne compte plus les entreprises qui, en hésitant à changer de recette, n’ont pas réussi à se renouveler et ont disparu : Kodak, Virgin Megastore, Nokia, BlackBerry, Yahoo!, etc. Non seulement, la nouvelle génération a compris cette nécessité de changement, mais elle le suscite avec les nouveaux modes de travail qu’elle privilégie. »

« Spark the Change » : décrypter et inspirer les bonnes pratiques  

Pour illustrer et expliquer cette évolution, l’événement « Spark the Change » a été créé à Londres en 2014 par Helen Walton et ses associés de Gamevy, avec le soutien de Wemanity, puis décliné en Australie, aux Pays-Bas, en Inde et au Canada. La première édition française sera organisée à Paris, le 26 juin prochain au Théâtre de la Madeleine.

Centré sur le futur du travail et les moyens de repenser l’entreprise de demain, « Spark the Change » propose aux entreprises françaises un programme de conférences de qualité, basé sur des retours d’expérience.

18 experts se succèderont sur scène pour décrypter les tenants et aboutissants de la transformation des entreprises. Parmi eux : Ludovic Huraux, CEO et fondateur de Shapr ; Dirk Ahlborn, CEO Hyperloop Technology ; Anthony Gooch Galvez, Directeur de la communication et des Affaires publiques à l’OCDE ; Anamita Guha, Product Manager, IBM Watson ; Marianne Syed, Executive Director chez Positive Planet UK. Et bien sûr, Arie Van Bennekum, seul rédacteur européen du Manifeste Agile, aujourd’hui Agile Thought Leader chez Wemanity et Jurgen Appelo, CEO et fondateur d’Agility Scales et expert du management 3.0.

3 thèmes principaux

Animées par des professionnels de toutes nationalités qui souhaitent faire évoluer le monde du travail, les conférences « Spark the Change » sont réparties dans trois sessions principales :

  1. Créer l’entreprise de demain : les différentes étapes pour insuffler un véritable changement dans l’entreprise, sur la base d’un apprentissage continuel, d’une maîtrise totale des technologies et d’une organisation plus agile et réactive.
    Jurgen Appelo, CEO et fondateur d’Agility Scales, expliquera notamment dans quelle mesure il est essentiel pour une entreprise d’aider ses collaborateurs à maîtriser continuellement le changement, par exemple via la ludification et d’autres nouvelles pratiques.
  2. Libérer les talents : développer le potentiel de chaque collaborateur, instaurer le bien-être au travail, booster la collaboration et créer un environnement de travail basé sur la confiance.
    Anthony Gooch Galvez, Directeur de la communication et des Affaires publiques à l’OCDE, détaillera ainsi « l’Indicateur du vivre mieux » de l’OCDE qui permet de comprendre ce qui contribue au bien-être des individus et des pays, et d’identifier comment susciter plus de progrès pour tous.
  3. « Sparking disruption » : privilégier l’innovation, voire la disruption ; remettre en cause le statu quo ; et valoriser le progrès social, technologique et culturel.

Dans cette session, Dirk Ahlborn, CEO Hyperloop Technology, dévoilera la genèse de la création d’Hyperloop qui, au-delà des records de vitesse et des nombreuses innovations qui le caractérisent, propose surtout de révolutionner l’expérience des usagers du train.

« Spark the Change a été créé pour inspirer les entreprises, à l’heure où elles sont confrontées à plusieurs évolutions stratégiques : la transformation numérique, l’évolution démographique, la co-innovation voire la “coopétition” sur des marchés mondialisés » explique Sabri Ben Radhia, Responsable de l’événement chez Wemanity. « Si Wemanity était présent lors des premières éditions internationales de Spark the Change en tant que sponsor, nous avons repris la marque et sommes devenus son organisateur principal. Réservé à la fois aux entreprises et aux institutions publiques, l’événement a pour objectif de couvrir l’ensemble des aspects relatifs à la transformation des entreprises, sur la base de très nombreux retours d’expérience. Il vise également à aider les entreprises à développer les compétences nécessaires pour mener à bien leur transformation ».

Le programme de la journée a été construit pour privilégier l’échange d’expériences et le networking. 750 personnes issues de l’ensemble de l’écosystème de l’innovation européen sont attendues le 26 juin prochain au Théâtre de la Madeleine.
Aurons-nous le plaisir de vous compter parmi eux ?


Plus d’information sur l’événement :

Les experts qui interviendront dans les conférences :

Inscription :

Also published on Medium.

Leave a Comment

Your e-mail address will not be published. Required fields are marked *

Comment *