Commander Marquet’s book might not be at the top of the list when it comes to product people wanting to get a deeper understanding of how to level up their craft. And probably it would have not cut my list either, if one coach wouldn’t point at it when I asked ”but what can I really do, to start delegating more?”. Despite not cutting the “hottest books in product” list, I would really recommend to anyone struggling with the same question to give it a go as there were many really actionable angles in this book.

If I had to summarize this book in one sentence I would say: this is a book about applied leadership and concrete methods on how to create and drive an organization that leads itself.

Based on the true story of commander Marquet and the crew of the Santa Fe, a nuclear submarine of the US navy, in the nineties. The underlying true story makes the book relatable, even if sometimes I struggled a bit with following all the technical details, and leading a nuclear submarine isn’t exactly what comes to my mind when looking for a comparable job to mine.  Yet, commander Marquet talks about empowerment many years before Marty Cagan made the word hype in the product world, shines a light on some concrete framework for both processes and mindset that are universal, and succeeds in creating an actionable roadmap on how to start delegating more. Here are my takeaways.

There is no empowerment without willingness, time, competence, and clarity

What to me shines through the book is that delegation takes the right mindset, time, and trust that the people doing the job have the competence to do it, and the right direction in front of them.

Delegation requires mindset, mind space, and overcoming the fear of failure through others.

I think that phrasing delegation in this way, really put a light on something that I can deeply relate to. I believe that sometimes I default to ”doing it myself” not because I want to have control, but because it is either easier (and many times faster) than asking someone else to do it. Or because I believe that the person who would have to do it, doesn’t have the complete picture of what needs to be achieved.

By defining the main driver behind the fear of delegating, you can really think about them when you default to it. And the same goes the other way around - if someone doesn’t delegate a task to me, what are the circumstances? Is it mindset, mind space, or fear of failure?

Always remember that every time a leader empowers you, she/he puts its reputation on the line. This way of working requires the highest level of buy-in, trust in competence, and clarity of goals that one organization can create. If one of these fails, the balance fails, and the chances that you want to fall back to a ”let me do it”, or “I’ll get someone else doing it” approach arise.  

While reflecting on it, I came up with some self-coaching questions that I plan to ask myself:

• How can you create the best impact long-term? 
  Is it by doing something yourself, or by investing the time to get someone else being able to complete the task?

• If you feel that you can’t delegate because of fear of failure
  -how can you eliminate it by giving context or upskilling competencies?

• How can you create the space to help others get where you need them to be?

• When you feel you are not given a full mandate for a decision,
  how can you get the decision-maker to point at the competence or context that he/she is lacking from you?

• In whichever role you are in, ask yourself:

  • Do I know what we want to achieve?

  • Do I have the competencies of delivering what is asked of me?

  • Do I agree with our goals?

  • And if the answer to any of these is no, do I dare to bring it up?

How to scale good decision-making in 3 steps

I feel that many product leaders around the world really spend their time thinking about what is needed to empower a team and an organization. We all want to strive towards the idea of a team owning a problem and its solution. And as much as I love this concept, commander Marquet made me reflect on another angle - and I couldn’t start but wonder if empowerment is really the end goal.

Commander Marquet talks about the pillars on which empowerment is built: competence and clarity. Many times, especially in the context of product development, we think that empowering teams is the ultimate goal, but is it? 

Empowering means that the power is traveling downwards, from someone giving it to others. And is it really a downstream of power that we should strive for?

General Marquet introduces the concept of emancipation, and he is intentional in defining what is needed to get there. It is not about complete freedom, it is about explicit steps to create intentional decisions. I identified three concrete frameworks that can be really used to scale good decision-making and emancipate decisions.

1- Think out loud  

The simple act of making one’s action explicit can really go a long way by removing errors, decreasing uncertainty, and promoting a peer-to-peer improvement mindset. General Marquet introduced this habit for his crew to catch mistakes. And despite this has obviously a much bigger meaning in a nuclear submarine than in many many many companies’ product development, it is really fascinating to see how this simple way could also be applied to product development. Sharing as a means to get more efficient. 

How to apply this? Do not focus on perfection but create a practice to think out loud, to share fast, and to make your thoughts explicit in a different part of your organization, in order to reduce mistakes.

Examples I think about are demos, pair programming, sharing an idea as soon as you have it, and peer reviewing. Sharing is not only caring but also a way of lowering risks and mistakes.

2 -Take deliberate actions 

Put a thinking moment, something that makes you re-circle back, any time you feel that something could go wrong and have a big impact but also when you could be defaulting to certain ways of working.

When I read about this mechanism of lowering the risks of failure, I immediately thought about Jeff Bezos´s 1 door, 2 door metaphor. Where he argues that only the decisions that cannot be reverted (1 door) should be escalated. As much as I like that way of thinking, I believe that commander Marquet adds a new depth to it.

It is not only about being intentional about decisions that can get real business impact but also being deliberate about working in a certain ways and avoid always defaulting to the status quo.

By adding a thinking moment to some decisions, as commander Marquet did with his crew, we can help ourselves derisking the decision-making in different ways, and avoiding to defaulting to certain ways of working. Some cases that are not a 1 door decision that I immediately think about:

• Add a thinking moment before testing a new feature - to avoid defaulting to an A/B test when we could maybe learn more by launching it (and possibly reverting it). Being data-driven is a strength, but the alternative cost might not always be worth it.

• Add a thinking moment before prioritizing time to market above technical stability, or the other way around. In my experience organizations tend to default to one or the other, without being deliberate about it.

• Adding a thinking moment before a successful experiment that could impact other teams. The majority of us just want to scale what works, but if other metrics are dependent on the experiment, that shouldn’t be the default behavior. And being clear and putting a thinking moment, could help with alignment and expectations

As a side note - in my head, all the thinking moments should not be escalated. Explicit thinking moments could be a mechanism to help reduce the fear of failure in delegating, but most importantly I see them as a way of helping the organization learn.
The beauty of having an explicit moment is the team is to help more people understand the complexity of some questions and maybe even question the status quo.

3- Define processes to support good decision making 

I probably have a biased view on this, as I have always been a big fan of processes to streamline clarity and impact. But I think that one of the main messages of the book is that true delegation can’t exist without a system to support it.

A common misconception is that empowerment means full freedom and that processes are only a way to micromanage. Why do we have to report if we have all the competencies we need and should strive to be as independent as possible?

But what if we change the angle on this and start thinking that processes, control points, and structure are not a mechanism of control, but a way to learn together and create resilience in the organization? And a way to think out loud and take deliberate decisions?

By introducing deliberate steps in the decision making the impact of mistakes is lowered, and it is easier to capture when you have to course-correct. Of vital importance in a nuclear submarine, and extremely relevant for every organization. 

Look at all your processes with these lenses: are they there to create a control mechanism, or are they there to add perspective and derisk your development?

Commander Marquet’s principles

Throughout the book, commander Marquet lists some impactful principles that I believe are at the core of his method for delegating and creating an impactful and resilient organization. These are the ones that resonated the most with me, in no particular order:

• At the heart of a resilient organization are leaders who are competent, give clarity, and take ownership of the consequences. And above all leaders who make the time to be curious, give context, and support their organization

• As a leader, do not default to giving indications or telling people what to do. Instead, actively push them to tell you what they intend to do, and focus your feedback on that. Next time someone asks you for a solution, try to turn the question to “What do you intend to do”?

• Taking care of your people doesn’t mean protecting them from the consequences of their own behaviors - accountability is key to holding control

• Control without competence is chaos - reverse engineer what competencies you need to make a decision and make sure that you are deliberate in involving them.
  I loved this principle and I think it will be really helpful for us when defining who should be involved in the different decisions of our product development processes.

• Only organizations where everyone is treated fairly and feel that they can speak up, have the potential for self-leading. You cannot have a leader-leader approach without the right culture and the correct incentives in place.

• Don’t move information to authority, but the authority to the information. Combine this with the principle of “I intend to” and you will have the perfect loop of bottom-up, up-down in decision making

• Encourage active participation by making sure to give everyone a clear role.
  An example is meetings: do not have them to inform, but to certify, so that all participants have an active role, know what is needed from them, and act. This part reminded me of the approach we took with async ideation.

• Change needs familiarity and results - you will find friction every time you want to change something, especially if someone has not tried it before. Say things many times, until they become familiar, and make sure to show results if you really want to continue with it. You need to help others see what you are seeing.