I was listening to the Lead.Dev podcast at the backend of last year, and the guest Rob Zuber recommended that listeners had a look at “Turn the Ship Around!” by L. David Marquet. I watched a couple of YouTube videos on the topic, including his talk at Google, and then bought the book to get the whole story. Despite being a compelling read, it’s been a bit of a slow burn due to my schedule. Now I’ve reached the end I thought I’d share some of my key takeaways from the book, parallels I’ve drawn with my own experiences, and what I hope to take forward from the book.

The Leader-Leader Model

For those of you that don’t know, the book itself covers the real life story of L. David Marquet’s command of the nuclear attack submarine USS Santa Fe, the challenges encountered by that particular ship, and how he addressed those challenges by removing the top-down management style and replacing it with a self-managing structure where the crew were empowered to make their own decisions.

Marquet explains that the Navy has historically been based on a Leader-Follower mentality. A Captain provides instruction, and their subordinates obey. This can lead to problems; for example, what if the Captain is wrong? What if they don’t understand a system or situation correctly? It places a lot of responsibility at the top of the structure, and means that the performance of a ship almost directly correlates to the performance of the Captain.

This also resulted in Captains having a short term focus, as they would be reviewed based on their ships performance while they were on board, not how it performed after they left. There was no guaranteed continuity of performance following the end of a Captain’s placement. Marquet provides some guiding principles that can be used to move away from the Leader-Follower mentality, allowing an empowered workforce that is responsible for it’s own decision making and addressing some of these issues. The book focuses on some principles that can be used in all businesses and how these can be applied.

Clarity, Not Control

This principle emphasises the importance of expressing intent and desired outcomes rather than dictating specific actions. Leaders focus on what needs to be achieved and why it needs to be done, leaving teams and individuals to deal with how it should be done. Outside of leadership, the individuals also express their own intent when performing an action; “I intend to….”. This gives their colleagues around them the opportunity to correct any inaccuracies before they happen and helps avoid mistakes.

I’ve been fortunate enough in my career up to this point that this has nearly always been the case. When work has been required, I’ve almost always been given a desired outcome and left to develop my own approach to the solution. It’s something that should I ever move into management I would like to continue. My main takeaway from this principle was to do more to express my own intent. That might be talking to my manager about what I’m planning on doing to keep them informed, or writing some documentation on how I intend for something to work so that other developers can see what I’m aiming to do.

Competence, Not Compliance

The idea is that we aim to build competent teams rather than obedient ones that just follow orders. By investing in training and creating an environment in which learning and development are prioritised, people can be more confident in their own decisions, and are more likely to take ownership.

This is something that I’ve historically struggled with. Not so much from a training others perspective - I’m always happy to give my time, share knowledge, and encourage people to take time to learn - but more my own prioritisation of learning. It’s something that I’m definitely trying to work on, and I’m actively trying to spend more time on personal development. I also want to try and share more of that knowledge in the workplace - this site is great for sharing with the wider world, but we have our own internal blogs as well where I aim to start writing.

Empowerment through Decision Making

Push the authority to make decisions to the people closest to the information. This can lead to better informed and faster decision making. By allowing the people closest to the work to make decisions without getting sign off from various layers of management, things can move faster, as well as fostering a sense of ownership and accountability. Some of this also links back to the intent based model I mentioned earlier. Decision making at an individual level could lead to mistakes - regardless of how close you are to the information. In combination with “intent” however, colleagues get the opportunity to help avoid the mistakes.

It’s not the first time I’ve heard of this, and I’ve heard it most succinctly described as “Genchi Genbutsu”. Akio Toyoda, the former CEO of Toyota who used to regularly follow this principle of going to the source and speaking to the people closest to the information.

In my career, I know of countless times when time and effort could have been saved by just going to the source - asking the developers closest to the information and most importantly listening to their advice.

Building a Culture of Ownership

This focuses on creating an environment where everyone is invested in the success of the organisation by fostering a sense of pride and responsibility for their own work.

The biggest problem that I have encountered in my career with this is the desire to ship things quickly. Developers often seem to find ourselves so focused on delivery that we don’t take the time to think about the quality of our codebase. I think this can also be exacerbated at large businesses and in large development teams, where you feel like a small cog with few tangible deliverables and large legacy codebases. In situations like these, you can find yourself lacking the sense of ownership that helps unite everyone behind a goal.

In my day to day, I often find myself working with a legacy codebase, and my current approach (when I’m not building something entirely new) is to try and tidy up what’s there. Make small improvements to performance or readability and gain an understanding of areas that I previously didn’t know. By doing this, I’m starting to feel more like I own some of the code that was actually written years before I joined the company.

Life in a Mirror

One of the main things the book made me do was think about my career and draw parallels with the leadership teams at the businesses I’ve worked at over the last decade.

When it comes to Empowerment, something that really resonated with me was the difference between Empowerment and Emancipation - the difference between permission within boundaries and genuine autonomy - especially when empowerment initiatives are imposed from above. I’ve worked at businesses in the past where these initiatives are kicked off with good intentions, but fundamental decision making structures remain unchanged. This artificial empowerment can sometimes feel like more of a mandate than an opportunity to take ownership. Don’t get me wrong, this has triggered some change when I’ve seen it in the past, but it hasn’t been the long-lived change I think the business was looking for.

Another comparison I drew was with Marquet’s perspective on reward, in which he talks about the importance of immediate recognition and the negatives of having a competitive reward structure. I’ve worked at businesses where there has been a limited budget for financial reward, which, from a business point of view, makes perfect sense, but leads to a situation where people are essentially competing for a share of the budget. When combined with things like annual pay reviews that mean you’re not rewarded immediately you can run the risk of a seriously demotivated and demoralised workforce.

The final comparison I made was with going to the source of the information, and empowering those decision makers. Often times at some businesses I’ve worked at, someone in Leadership will ask when something can be delivered by. I’ve seen first hand when these questions come down the chain to the person closest to the source, they answer with a reasonable deadline and then that information is lost along the way back up the chain. By the time it reaches the original person asking the question, the answer from the source has been lost and replaced with an unrealistic delivery date. Could some of these leaders get a more accurate view by employing “Genchi Genbutsu”?

Next Steps

For myself, reading this book really made me think about how I would want to lead a team should I decide that is the path I want to follow. What could I be doing to live by these principles and have a truly competent and empowered team? It also made me think about what I could be doing now to improve the lives of my colleagues and my manager.

Most of all though, it made me reflect on where I have worked and the management practices employed in those places. It made me evaluate my managers, past and present, and consider what they could take from L. David Marquet.

Overall, I’d highly recommend reading the book if you haven’t already. Or at the very least, head over to YouTube and spend ten minutes watching this summary.