How to Turn a software Ship Around

How to Turn a software Ship Around

Software development leaders who have read Turn the Ship Around! by David Marquet will intuitively understand that the approach outlined by the author can be applied to software dev environments. Still, it might be helpful to chart a clear course between operations on a nuclear submarine, and those of software development teams. 😃

These are some key learnings, particularly from the perspective of accelerating the pace at which decisions are made and work is done. For context, the approach described in the book is anchored in a leader-leader philosophy, which means treating every team member as a leader and allowing them to make decisions in areas where they have the most expertise. 

#1. Managers must relinquish control

If an organisation would like to reap the benefits of a leader-leader model, it's clear managers must be prepared to encourage a questioning attitude from their people, foster genuine curiosity, allow people to step up and, most importantly, relinquish control.

Whilst this might seem like a scary prospect for many experienced managers, it was clearly fundamental to the leadership approach that the author seems to have inspired in the US Navy. And one has to wonder...if traditionally top-down led armed forces crews saw huge success from this approach without compromising on safety or security, then surely software teams would benefit too?

Of course it is not recommended that managers simply let go of the rudder - or even that organisations abandon their leadership structure entirely. That would lead to chaos. Instead, the suggestion is to have an intentional plan around communication, goals and training.

#2. People empower themselves

The most important learning from this book is around empowerment and the fact that leaders do not empower others. People empower themselves. Software development professionals in particular are motivated by having ownership and decision making ability over their work and are often very passionate about what they do. If given the opportunity, many will take ownership or lead.

A leader's role, therefore, is to push decision-making down the organisation as far as possible, so that the decision is made by those people who have the most context. In addition, focus on defining clear responsibilities and decision making authority to allow people to focus on getting their jobs done rather than navigating uncertainty. 

#3. Prioritize Clarity and Alignment

As leaders attempt to reduce their level of control, clarity on organisational purpose, strong communication and clear guardrails become critical.

The author talks about the fact that organisational legacy stories can be incredibly helpful in helping team members deeply connect with the purpose of the organisation, in addition to inspiring them. These can often go hand in hand with organisation values, which many software organisations have given some thought to in recent years. Ultimately the aim is to engender certain behaviours across the organisation. 

Guiding principles are also important, and their true impact comes from integrating them into every aspect of team operations, including daily communication, success metrics and recognition practices. The book highlights examples of guiding principles such as ‘courage’ and ‘openness’ on the USS Santa Fe. Examples of strong guiding principles in well known software organisations are:  Customer Obsession (Amazon), Growth Mindset (Microsoft), People Over Process (Netflix).

Often overlooked when people remember this book, the author emphasizes the value of standard operating procedures as a foundation for clarity, empowerment and good decision-making. He explains how the crew continuously integrated any lessons learned into their procedures. While this might seem too rigid for software environments where many shy away from process, simple guidelines (that are repeated often) can still provide clarity, improve alignment, and prevent recurring mistakes. 

Finally, the author talks about setting specific goals but giving people the freedom to achieve those goals in their own way, as long as it aligns with the organisational values and principles. An added benefit of focusing on the ‘what’ and ‘why’ but not the ‘how’, is that it promotes diversity of thought and innovation.

#4. A culture of learning is not optional

In order to reduce top down control, a high level of competence is required at all levels of the organisation. As the author points out, empowerment without competence is a recipe for disaster. Leaders must ensure that their people have the requisite competence (in addition to clarity) to make successful decisions. The author shares how he supported on-the-job learning for all crew members and how that investment paid off in terms of being able to delegate responsibility and speed up operations. 

Many software teams benefit from dedicating time during the working week for team members to up-skill in job specific areas. Building expertise not only improves individual capabilities but also improves development flow, often saving more time overall than the initial investment.

So, what will managers do when teams become highly skilled, self-organizing, and the [software] ship starts to steer itself? The author suggests shifting focus to developing people and understanding their needs as individuals. As well as fostering accountability among managers at all levels to support their teams and ensure they have the resources and tools needed to succeed.

Often this also allows managers to zoom out and take a systems view, in order to see if there are any ice bergs on the horizon.