Extreme Ownership: How it looks like in software development teams

Written by ex-navy SEALs Jocko Willink and Leif Babin, Extreme Ownership is a book that encapsulates their leadership experiences in the service and explores how those lessons can be applied in the business world.

Let’s start with a closure

In a nutshell, I grasped one main rule from Willink and Babin – before you seek help or problems’ causes outside your universe, first figure out what you can do to improve the situation. Whether it is your fault or not. In short – be responsible; own it!

Willink and Babin claim that teams who understand this rule will outperform because every team member reports how they will fix a situation. They will not just argue about the situation or why it might have happened.

In their book, the authors identify 12 principles of leadership and explore examples from the battlefield alongside applications in the business world. Drawn to this structured approach, I was curious to apply those principles to my own working experience in software development teams.

• The principle – summary of the principle from the book
• Personal story – corresponding example of my work experience
• Advice to myself – what I would do differently next time to improve the situation
  

So, let’s get started:

Extreme Ownership

The principle:
(p30f.) The leader owns everything, and there is no one else to blame for failure. They must ensure that subordinates can execute their mission by mentoring and training them and being clear about the goal. The leader must also deal with the consequences if a subordinate can’t meet the standards to fulfill the mission. In that case, to ensure the mission and to protect the team, the leader must replace the underperforming team member.

Personal story:
At times, the team becomes so absorbed in finding solutions and building that they forget about the overarching goal or the team’s mission.

Once, I worked with a team on the website performance of an online shop. We started by analyzing different reasons why the website was so slow under some conditions. Soon we had a long action item list on how to improve the situation.
We worked through the to-do list by first tackling the low-hanging fruits. Such as deleting redundant content from the page, improving image handling, and enabling asynchronous content loading for faster website delivery.

Despite taking the aforementioned steps, we were still unable to achieve the expected results. One proposal was to switch to a faster framework, but that option would require considerable effort. Instead, we opted for an experimental approach, starting with a proof of concept for just a single-page type.

After just two iterations, we stopped with the experiment as it only marginally improved things. At that moment, it dawned on me that we had lost sight of our objective. Improving the website’s performance was never the end goal. Rather, it was to remove any obstacles impeding the user journey and obstructing their purchases on the site.

After implementing some quick and easy improvements, we had already boosted the website performance. While high-loading times were one of the main obstacles, there were several other obstacles in our path.

It took several iterations for the team to get back on track. Also, the team started having “new goals,” such as refactoring the website and, as a hidden agenda, learning how to use that fancy new framework. Luckily, following SCRUM cycles allowed the team and me to identify that things had gone sideways.

During our biweekly progress reviews and stakeholder meetings, we discovered that we had addressed one obstacle. But it wasn’t resolved perfectly; however, it was resolved well enough. Now, we need to get back on track and examine other obstacles along the way.

Advice to myself:
To be clear about a goal means to repeat it regularly until it changes. The team certainly has a sprint goal, but team members, or even subsets of the team, are likely to experience distractions. They may have ongoing learning initiatives, appointments on other topics, or personal matters that unexpectedly occupy their time.

A leader takes responsibility for the outcome and refrains from blaming their team. It’s easy to lose track of goals in today’s busy world, which is why a leader must frequently repeat what the objective is and ensure everyone stays on the right track.

Call to action:
Have you had a similar experience with your team as a leader or team member?

No bad teams, only bad leaders

The principle:
(p.54f) “It’s not what you preach, it’s what you tolerate.” Good leaders never tolerate substandard performance; instead, they are eager to overcome challenges and improve continuously. Their mindset gets adopted by all team members who strive for excellence.

Personal story:
Working as an Agile coach, I preached having a proper sprint goal for every sprint. I insisted the team and the product owner have at least something written down that could be used as a goal. Although these goals were not adequate, I reluctantly went along with them.

However, the goals were essentially in the form of a to-do list and were neither specific nor broken down into manageable tasks. Consequently, sprint after sprint, there was no progress toward meeting these objectives.

I was mad at the team that they ignored my advice and mad at all of us that we were content with the poor goals we defined. But to be self-reflective: I tolerated the inadequate goals.

If I had really owned the process, I would have stopped this and realized something was completely wrong. And I knew what was wrong. Actually, I was aware that the overall goal – the product vision, was ambiguous and too ambitious. I overlooked all those warning signs.

Advice to myself:
If you realize that you’re constantly preaching and nothing changes, find out the root cause. People usually have only a few reasons not to support an endeavor: either they don’t understand the objective, they don’t know about it, or they don’t want to achieve it.

Try to understand what’s the matter and remove the obstacles by digging deeper into what is holding people back. Some teams use, for example, the famous technique “The 5 Whys” (or as many whys as you need). For further reading, check out this article.

Advice:
Start with an explanation of why you want to use this technique and what the rules are. Repeatedly asking someone “why” they did something can come off as offensive to some, which is why – be respectful with your teammates, be transparent about your goals, and ask questions until you get them. Then change it.

Call to action:
Have you had a similar experience with your team as a leader or team member?

Believe

The principle:
(p. 76 f.) If there is a mission to accomplish and there is doubt about it, it is on you, as a leader, to get all the information so that you, too, can understand the strategic reasons and the why behind it. Only if you believe in the greater cause of a mission will you be able to inspire your team and convince them to follow. But if you have doubts, they will have doubts as well.

Personal story:
We had a client who asked for a very unconventional and artificial representation of their KPIs. As the product owner of this project, I had serious doubts about the idea’s cost-effectiveness. Consequently, I wasn’t keen on persuading my team, and naturally, they also refused its implementation.

In my opinion, there was a more effortful way to build a customized dashboard, and we already had a tight schedule. But after several rounds of discussions and our first simple versions of the dashboard, the client still insisted on their idea.

I took a step back and wondered why the client was so persistent. So I started to ask myself why they were so fond of the idea and what would happen if we didn’t follow the client’s idea. Also, I wondered how this would fit into our working environment.

At last, I understood the sound justifications behind their idea, which subsequently convinced the team as well. And voilà, the solution we longed for was built! All we needed was a clear understanding of the purpose. Once we believed the effort was worth it, everything fell into place.

Advice to myself:
As a PO, you need to make sure that you work on the right things that bring value. At the same, you need to keep the costs of implementation and the timeline under control. Sometimes this is hard enough, but there is at least one point you must always remember – your product’s users. And if the users and/or some advocates of those users ask you repeatedly to deliver a specific thing, even if you don’t see a good reason for it, chances are high that they indeed have a very good reason. And it is on you to ask as many questions as needed until you truly understand it.

Call to action:
Have you had a similar experience with your team as a leader or team member?

Check the ego

The principle:
(p.100f) Never get complacent. Control your ego and be humble enough not to overlook risks or justified critique.

Personal story:
As previously mentioned in the example of the third principle, “Believe,” which I disregarded at the beginning stages of the job: Allowing one’s ego to take the reins can lead to a default position of disbelief. In my case, this was precisely what happened: Instead of exhibiting humbleness and faith in the client’s and the users’ feedback, I presumed I knew better. But I only knew it better from the developer’s and cost-driven product manager’s perspective. I did not understand what was relevant from a user’s perspective.

Luckily, there was a big resistance to just letting my product development team continue with its ignorance, and at one point, we realized that we needed to put on the user’s shoes to understand.

In retrospect, it was a valuable lesson: when developing a product, the driving force should always be the user’s needs – not my own, not the developers’, and not even the clients’. Ultimately, user satisfaction is the key to success.

Advice to myself:
To actively enhance your understanding of other perspectives and be more empathetic: do interviews, visit users, apply an empathy map with your team, and do the customer journey. These methods will help you put on another person’s shoes and forget your ego.

Call to action:
Have you had a similar experience with your team as a leader or team member?

Cover and move

The principle:
(p.121f) “Cover and move” means that all team members, different divisions, and supporting assets must help each other, break down silos and work together to accomplish the common mission. Nobody wins unless everybody wins, and it is the leader’s duty to take care of the collaboration of all mission members.

Personal story:
In the past, I often didn’t follow the cover and move principle. In times of disrupting technologies, when old technologies compete with new ones, it is hard for teams to see a bigger common goal, especially when it is connected to personal fear of losing status, influence, or even one’s job.

When I was working with a TV broadcaster, the classical TV departments weren’t eager to work with the online streaming departments. Similarly, when I was working with a publisher, the classical print divisions weren’t interested in supporting the departments that took care of the online platforms.

It took years and shifting revenue streams before the mindset started to change. Back then, it was easy to get overwhelmed by emotions. Instead of figuring out how all parties could benefit, people switched easily into a defence mode by building a sworn community with their peers. The result of such an environment – the competing groups with different agendas.

As a mid-level manager, I initially disregarded the conflict at hand. However, upon reflection on the second principle – “It’s not what you preach, it’s what you tolerate” – I now realize that addressing this conflict, or let’s call it a change process, would have likely accelerated overall company performance significantly.

If you already lose too much energy on inside competitions, there is no energy left to win over the outside competitors. Looking back, I wished I had leaders around me who reminded everybody that we should help and support each other as best as possible since we were one team and there were enough other company teams out there who wanted to beat us.

Advice to myself:
When you sense misalignment or competition between teams, make efforts to understand the root cause. Start with personal communication like a phone call, a lunch date, or a coffee talk to avoid misunderstandings. Consider conducting a workshop to collaborate on creating a win-win outcome. Written communication can be confusing and is best avoided.

For a workshop format, check out the game from a famous game-storming website: https://gamestorming.com/even-flow/

And remember: “Alone you can walk fast, but together you can walk further.”

Call to action:
Have you had a similar experience with your team or as a leader or team member?

Simple

The principle:
(p. 140) Simple, clear, concise orders or plans are essential to accomplish a mission. When things get too complex, the chances of failure and flaws increase. Therefore the leader is responsible for everyone in the team to understand their role and what they are supposed to do. A leader must encourage open communication about anything that might be unclear.

Personal story:
The “simple” principle is perhaps one of the toughest ones to implement, particularly in the inherently complex field of software development. Complexity means that you’re operating in a field with many unknowns. However, the complexity doesn’t have to come from the software itself.

For example, some rather straightforward apps could be done in a couple of days if the engineer involved had some uninterrupted time. But, the reality is often different. Instead of being alone, the engineers have their teammates and stakeholders who all have their ideas for the app, as well as different knowledge about the purpose and how to build it, and in almost all cases – different meanings of the words they use when they try to align on a product.

Consider the questions such as these being asked: We need to automate our business processes. => Saying this, the following questions should have been explored rigorously:

• What is our understanding of automation? 
• Will we need to train AI, or are simple rule-based mechanisms enough? 
• What business processes are we talking about? 
• What is our common understanding of a business process? Do we maybe have different understandings?
• With what process should we start?
• (And most importantly) Who or what will benefit most from automation? Who has a stake in it?
  

I once worked with a team where such questions remained unanswered, and ideas went unexplored. Despite our efforts, we were unable to obtain the necessary clarity from management and stakeholders, and there was no open communication to discuss the problem. As a result, we not only fell short of delivering the desired outcome, but we also failed to prioritize that goal from the outset since everything was unclear and simply not simple enough to execute any of it.

Advice to myself:
Don’t hesitate to stand up and ask for clarification. Even if you are the only one on your team who doesn’t understand the whole picture, it is worth insisting on more details. You are a team member, and your efforts are needed to accomplish the goal.

How can your team get the best of you if you don’t get what it is about? It’s not just in everyone’s interest but also everybody’s responsibility to simplify things.

Call to action:
Have you had a similar experience with your team as a leader or team member?

Prioritize and execute

The principle:
(p.161f) As a leader, follow the priorities and execute the process: 

• Find the highest-priority problem 
• Explain in a simple manner to the team (principle 6) 
• Elaborate and determine a solution together with the team
• Put a complete focus on the prioritized task 
• Move on and repeat with the next highest priority task.
  

Be aware of shifted priorities, communicate them, and don’t get too fixed on the target to maintain the ability to see other problems that need to be solved first.

Personal story:
The “prioritize and execute” principle sounds quite obvious, for which we have popular frameworks and tools to make it happen, such as SCRUM, Kanban, and XP; meanwhile, there are also many more variations of lean development approaches.

 I’d bet, though, that everybody has a very good example of a time they worked on a prioritized topic, and instantly the priority changed.

In software development, the shift in priority usually happens to teams when the Marketing or Sales teams close a deal or a nice new service is released, and the team must integrate it ASAP (or, of course – there is a pandemic that changes everything, everywhere, all at once).

 Let’s face it, unexpected events can occur and cause delays – that’s life. However, it’s important that there’s a valid reason and that the delay won’t be a disaster for the company. Luckily, the disaster scenario is very unlikely – I’ve seen many changing priorities, and none of it ruined the company. Typically, leaders, including CEOs and upper management, are mindful of these risks and take necessary action.

And yes, there is usually always a good reason for a changed priority. What often is missing, though, is the communication of why this new topic is so much more important than any other one and why the focus switch is worth it. 

The most frustrating conflicts I remember emerged when the team wanted to focus on fixing technical debts and refactoring tasks. And suddenly, there was an essential money-earning feature that the product management people brought up. This is a trap many teams can fall into. But the trap was built by the team itself beforehand.

And suppose a team encounters a situation where technical debt becomes the most important high-priority topic. In that case, it is on the team to communicate the reason in a simple way, work on a plan, and execute it. 

Advice to myself:
Regarding technical debt: there will always be technical debt no matter how much the team takes care of TDD and QA, DoDs and Clean Code, etc. As a consequence, a team should always – in each iteration – take care of technical debt items. 

Frankly, there will never be a time when the leadership will tell you: “Dear team, we don’t mind if you do a feature freeze for as long as you want. Your salaries are safe forever. Just go ahead with your refactoring tasks.”

On the contrary, there will be for sure now and then an opportunity a team must take because it will be for the financial sake or the company’s fame. Don’t expect technical debts ever to be the most important topic in your backlog, and take care that they’ll never need to be.

Call to action:
Have you had a similar experience with your team as a leader or team member?

Decentralized command

The principle:
(p.183f)
All team members up and down the chain must know the overall intent. The overall intent must be known by all team members up and down the chain. The teams must be split into smaller ones (4-6 people in military troops) so that clear communication can be maintained even in stressful situations when it is not possible anymore to talk to more than a bunch of teammates.

Leaders at every level must comprehend the ‘why’ of the mission and the ultimate goal. Trust is crucial from senior leaders appointing junior leaders to junior leaders making decisions within designated boundaries. Regardless of the outcome, the backing of senior leaders is a guarantee, empowering junior leaders to act.

Junior leaders must be proactive to enable their leaders to get all the necessary information they need on a higher level (principle 3 Believe). Leaders should not get lost in details to keep the higher overview – micromanagement must be avoided.

Personal story:
Willink and Babin state that junior leaders must understand the commander’s intent (the broader mission) and the strategic mission. And senior leaders must constantly communicate and push information to them (see p. 184). 

The abstract mentioned above perfectly reflects the trend of installing autonomous teams. These teams have the power to make decisions and implement them effectively. There is just one issue with autonomous software development teams: It sounds great to the management to install autonomous teams, aka to decentralize their command, since it will mean they have less work and less to worry about.

For this idea to succeed, the management must provide the necessary information, including a strategic mission, guidelines, and ultimate goals. Most importantly, they must maintain a continuous stream of new information for the team – this is the crucial element for the success of this approach.

I’ve seen this going wrong several times. One team knew about the ultimate goal but had no guidelines for making their own decisions which led to too much research time, postponing decisions, and wasting time, which is bad in an industry where time to market always matters.

Another team had guidelines and a goal, but the strategic mission was unclear, which led to a software solution that solved one problem. However, they soon realized that their tech stack couldn’t meet the upcoming requirements. The dilemma left them puzzled.

Yet another team was aware of the strategic mission and the goal and even had some guidelines. But the continuous flow of information did not work since they were disconnected from the decisions of the upper management. Guess what happened – they walked in the wrong direction far too long, and after a reconnect, they were weeks of work away from the actual strategic mission.

Advice to myself: 
Don’t be a lazy leader. If you start a mission with a team, you need to invest time to constantly feed them with updates, guidelines, your strategic plan, and the ultimate goal or outcome you want to achieve. If this is not possible, find somebody who can take over either within or outside your organization. Never let a team or teams start without any guidance. It will only turn out to be a waste of time, energy, and money.

Plan

The principle
(p.204f):

1. Analyze and understand the mission: what is the higher strategic intent, and what should the end state (goal) look like?
2. Identify capabilities needed: “personnel, assets, resources, and time available.” (p. 207)
3. Decentralize and hand over part of the plan creation to junior leaders. 
4. Determine the course of action, which should be the simplest and the best from what you know at that time.
5. Empower key leaders to take over further development of the determined plan.
6. Analyze the likely contingencies that can happen through each operation phase.
7. Take action to control the risks that can be mitigated.
8. Stand back and delegate portions of the plan to key junior leaders.
9. Continually monitor emerging information and check if the plan still fits the situation.
10. Keep briefing the plan to all involved parties, include the higher strategic mission again, and engage people to ask questions to achieve alignment on all levels.
11. Conduct lessons learned after the operation and implement them in your next planning.

Personal story: 
This Plan Checklist makes total sense. If I didn’t exactly know that I copied it from the Extreme Ownership book, I would have guessed it was from any project management or even an Agile methodologies book. 

If you compare it with the software product development approach, it is quite similar:

Advice to myself:
Not all of this happens always. And it takes some discipline from the whole team not to skip any of those steps.

But to be honest. I would have loved having such a list at the beginning of my career. Many mistakes were made because I did not check the risks with my team before starting the project. I didn’t do Lessons Learned meetings after a project, especially when we used the waterfall method; I rather turned to the next task without learning from old mistakes. Skipping and looking at failures is surely the easier way, but not the best.

Advice:
Make use of the checklist to not skip essential parts that will help you and your team to get better with every iteration.

Leading up and down the chain of command

The principle: 

Leading down the chain:
(p229f.) As a leader, you must ensure all subordinates understand the bigger picture. Therefore you need to give a strategic overview brief to everyone regularly so that they can understand what has been accomplished and how they contribute to the mission’s goal.

Don’t get soaked up in details but communicate face-to-face regularly with your teams to understand what they need from you to fulfill the mission. Such behavior enables principle 8, “Decentralized command.”

Leading up the chain:
(p.230 f.) As a subordinate, you must be cautious and professional to lead up the chain. Remember that your leader wants to fulfill the same mission but might have more strategic insights than you. First, consider what you can do, what you need to know, or what kind of information you should provide primarily to your leader so they can support you. Present an action plan, don’t ask for one.

Personal story:
For both directions, up and down, I have countless examples under one headline: miscommunication and non-alignment.

In one of my former roles, I worked in an environment where transparency was not among the highest values. The back-then routine was top-down management. So I was told what to do without getting the bigger picture or why my team and I should do something. So this example fits failure on both sides: I could not give my team a proper brief of the current mission or strategic goals simply because I didn’t even know it. The good thing was I could always talk to my boss up the chain, who supported me in finding the strategic goals.

Therefore she pushed the managers of other departments to explain those goals to me and the team. Thus, I agreed with the other department to have regular briefing meetings about the goals and current achievements. We started to communicate more and got aligned, and the ugly feeling of just being told what to do and not understanding the why vanished.

Advice to myself:
One thing is important to mention. In software development, it’s rarely about life and death. So the look in the mirror and the will to take action highly depend on how safe one feels in the working environment.

I had a great boss, and we had a trustful relationship. So in office life, this is a precondition before you, as a boss, expect that your employees talk to you openly. Make sure that they trust you.

And if you’re in a position where you don’t feel comfortable talking to your boss – reconsider the reasons for that feeling and either be brave and address the issue or consider the “love it, change it, or leave it” strategy.

Decisiveness amid uncertainty

The principle:
(p.254) As a leader, you will never have a complete picture of the current situation or what will happen in the future. Therefore you must be ready to act on the information at hand at that specific moment when decisions are needed.

Personal story:
The “decisiveness amid uncertainty” principle goes hand in hand with the agile approach in that in a complex environment (which is usually true for software development), the only thing you can do is trust that you took the right decision with the information you’d had at a time since you analyzed them thoroughly beforehand.

It might turn out to be the wrong decision, and as soon as you know, you can pivot your approach with the new information at hand. This kind of situation happens all the time in software development.

In one of my teams, we used a library for a React app that helped us quickly complete a feature we needed. Over time, when the application grew and got more complex, that library led to a very high level of memory consumption, which became a functional blocker. Our fault was that we reacted too late to the problems we saw arising during development. So, in the end, we had to do an expensive (it took us over one month) refactoring of that part of the app and replace the library.

Advice to myself:
In software development teams, there is a very good reason to set up monitoring of the tools to measure KPIs like memory consumption – you need to act as soon as you realize things are going sideways. The later the team acts, the more expensive it will get. There will always be some uncertainty. However, you can mitigate risks by continuously gathering information and being courageous enough to change your direction as soon as the information you monitor indicates that something is not okay.

Discipline equals freedom – the dichotomy of leadership

The principle:
(p.274f) A good leader will always find the right balance between acting too much and acting too little in various areas. A leader must be confident but not arrogant; they must take risks but not be careless. Willink and Babin had many more examples, but one is, for me, the most important: A leader must lead and be aware of when to stop leading and start following.

Personal story:
Luckily, all the leaders I worked with so far did quite a good job finding the balance. 

But one spectrum – to be “aggressive but not overbearing” (p.278) – is, from my experience, very hard to balance.

A typical failure story is about tech stack decisions that were supposed to be made by the software development team and were done in the end by the upper management. It is related to being “able to execute Extreme Ownership while exercising Decentralized Command” (p.278).

The story is about teams who weren’t confident enough to argue against an aggressive and, in the end, overbearing tech stack decision from upper management. Even the tech leads didn’t have a say in the end, so Decentralized Command was installed but not exercised.

I believe that upper management people are very wise to be more aggressive than the rest of their colleagues because they usually deal with essential decisions that can even ruin a company. So, on the one hand, if a team doesn’t want to be overwhelmed by upper management tech stack decisions, it needs to have very good arguments and be willing to spend an amount of counterforce.

Such a decision, on the other hand, requires that the upper management does their job in communicating the overall goal, the mission, and enough details that enable the team to make good decisions. Remember Decentralized Command.

Advice to myself:
The whole team is often communicated with about these kinds of decisions, but some team members may not want to express their disagreement even if they have one. I would ask upper management for a NUM0 session to make my standpoint clear and get more information from them. (They usually have more details.)

Sometimes team members need to be disciplined enough to take over and lead up the chain. Eventually, people will only follow if they see that somebody else is willing to take over and can prioritize and execute (principle 7). 

Acknowledgment

I share personal stories here based on my individual experiences and perceptions. Team members’ examples may differ from mine. You should reflect on all shared examples rather than taking them as a personal critique.