About the book
In October 2015, former Navy Seals Jocko Willink and Leif Babin published “Extreme Ownership — How US Navy Seals Lead and Win”. The book would go on to become a #1 New York Times bestseller and currently holds an impressive 4.8/5 star review on Amazon, based on over 10,000 reviews.
In their work, the authors explain twelve leadership principles they learned during their time in one of the world’s most elite special forces units. They go on to describe how the application of those principles can be applied to leadership in the civilian sector.
Why this book could be interesting for Scrum and Agile
Scrum is relatively quiet on the topic of leadership, only describing the Scrum Master as a “true leader” and previously as a “servant-leader”. Thus a book about leadership raised my curiosity, even coming from a field that I would normally not have associated with Scrum or Agility: the military. I was surprised how well the book’s lessons are in line with many of Scrum’s ideas and complement the Scrum Guide well.
Principles of the book
Let’s take a look at each of the twelve principles presented in the book:
1. Extreme Ownership
To achieve success in complex endeavors, establish an attitude of Extreme Ownership. Briefly summarized, this can be described as making the default assumption that you are responsible for any outcome and should take (extreme) ownership.
When you lead a team, assign a task to somebody, and that person fails, assume it is your fault, not theirs. You could have given clearer instructions, checked in with them more frequently, and found better ways to prepare or support them.
While this runs counter-intuitive initially, it acknowledges your sphere of influence: blaming others for failing does not generate the results you all wish to see. In the corporate world, this may result in a project failing. On the battlefield, it may very well mean death.
2. No bad teams; just bad leaders.
The authors share an anecdote from their SEAL training, where a high-performing team and a low-performing team had their leaders switched, leading to both having similar performances. The less is that leadership in a team has enormous impacts on the performance of a team; leaders must be aware of this and live up to it.
3. Believe.
A leader must believe in the mission they are conveying to those they are leading. A lack of belief on the leader’s side will result in a lack of buy-in from the team. The same will happen if the leader cannot explain the mission in a way that allows the team to understand and honestly commit to it.
4. Check your ego.
This one can be understood as a requirement for taking extreme ownership. While confidence is a valuable trait, it must be differentiated from cockiness. You should have the humility to question your own knowledge and your own ways, actively pursuing the possibility that you may be wrong.
Furthermore, you should never underestimate your competition, be it an enemy combatant on the battlefield or a competing company in the market.
5. Cover and move.
This principle derives from the way SEAL units advance on the battlefield: one part advances while the other covers them from enemy fire. This requires a great deal of coordination, communication, responsibility for each other, and trust. Teams are only successful if they have each others’ backs, either figuratively in the workplace or literally in a combat zone.
6. Simple.
Mission objectives should be formulated clearly and concisely enough for everybody to understand them intuitively. Overcomplicated mechanisms may result in incentives turning in the opposite direction. This is illustrated in an anecdote in which a company’s bonus system is so convoluted and complicated that it leads the employees to pursue a direction that is not desirable by the management.
This idea mirrors a supposed Einstein quote: “If you can’t explain it simply you don’t understand it well enough”.
7. Prioritize and execute.
This principle is the acknowledgment that neither humans nor teams can truly pursue multiple objectives well at the same time. Rather, different problems must be assessed as calmly as possible, prioritized, and then worked off sequentially. This concept is summarized in the SEAL directive “Relax, look around, make a call.”
8. Decentralized Command.
Command structures, or more broadly communication structures in a team, should reflect human beings’ natural limits. We cannot manage many more than around eight people, so decision-making must be decentralized, flowing from an overarching objective at the top of the chain down into concrete implementational steps left to those executing them.
9. Plan.
This principle describes primarily the process of planning, rather than the outcome. It is critical that when a plan needs to be devised, the deeper meaning is understood. The desired end-state must be clear, and different paths to realizing goals must be evaluated. This process, especially when dealing with a particularly complex problem, must span different hierarchy layers to generate buy-in across the organization.
Not every level in a chain of command needs to concern themselves with every aspect. Thus, planning consists of breaking down large problems into smaller units and delegating the further work to those next in the chain, who may repeat this approach until it arrives at the level of those executing the plan.
10. Lead up and down the chain of command.
As a leader, you are responsible for leading those under you in the chain of command. You are, however, also responsible for leading up the chain of command. As with the first principle of extreme ownership, take responsibility for both directions of the chain. This is summarized powerfully by the quote:
“If your boss isn’t making a decision in a timely manner, or providing necessary support for you and your team, don’t blame the boss — first blame yourself. Examine what you can do to better convey the critical information for decisions to be made and support allocated.”
11. Be decisive.
The key job of a leader is to make decisions for themselves and others. Decisions may often need to be made on partial or incomplete information. A leader’s responsibility is to make necessary decisions without 100% certainty, but at the same time to own potentially negative outcomes and be flexible enough to change course as new information becomes available. In many situations, it is more important to move forward than move in the perfectly right direction.
12. Discipline equals freedom.
While this may at first seem paradoxical, there is an inherent logic to the statement. The authors argue that discipline, when practices correctly, aids creativity and allows for freedom of decisions in teams. The disciplines they describe are committed humility without passivity, confidence without cockiness, attention to details without an obsession with minutia.
How this relates to Scrum and Agile
I argue that all principles can be applied to a Scrum Team and can be useful for Developers, Scrum Masters, Product Owners, and those working with Scrum Teams.
Principle 1, Extreme Ownership, can support and foster the ideas of a cross-functional, self-managing Scrum Team. Everybody is accountable for the collective outcome of the team. There is no point in a Product Owner pointing towards the Developers and assigning blem when a Sprint doesn’t yield a usable increment. The sense of responsibility to support each other, even in areas not specifically assigned to you, spans all roles and leads to better outcomes.
Just because the Product Owner is the person usually closest to the stakeholders, this does not make them a proxy for communication. Developers need to incorporate the responsibility of working with the stakeholders into their field of work if it can help improve the outcome.
When multiple Scrum Teams work on one product, they often fall into a sense of separated responsibilities: “These modules of code are ours, those are yours. We take care of ours, you take care of yours”. While a focus on your own domain may be valid, the objective should not be to take care of your own things exclusively but fulfill the overarching goal. For this, it is often necessary to take ownership of things outside your immediate responsibility. In this context, ownership should be understood as taking an active stake in something, to take responsibility for a positive outcome.
Principle 2, the idea that leaders ought to take responsibility onto their shoulders, applies to Scrum Teams as well. Scrum supports the idea of teams without internal hierarchical structures. However, this does not mean that there is no leadership within Scrum Teams, but rather that everybody needs to be able to take a leadership role.
The Product Owner needs to take the lead by providing the direction in which the product will be developed.
When a Sprint Review reveals that the Developers developed something different from what the Product Owner expected, it is their responsibility as a leader to question their own communication and improve it for the next time.
The Scrum Master, as the owner of the Scrum process, must take responsibility for the outcome and question what they could have done better first.
The same applies to the Developers. On top of this, individual Developers must be willing to take leadership on technical issues within the “team of the Developers”.
Whenever an initiative failed, the one who pushed it forward should first ask themselves what they could have done better!
Principle 3, the idea of creating goals that are clear and others can buy-in to, is one already integral to Scrum. The Product Owner must formulate a Product Goal that provides guidance and motivation to the Developers implementing the Product Backlog items. Poorly formulated Product Goals, lacking focus, clarify, and an understandable why will lead to a lack of direction for the Developers, resulting in poorer results overall.
The same holds true for the Sprint Goal and is especially important because it is crafted together. This process may be driven forward by individual members of the Scrum Team — most often the Product Owner — but it is crucial that all members of the team understand the goal. Only that way will they be able to commit to it and be able and willing to work toward it.
Principle 4, advocating humility in every direction, is a cornerstone relevant for all teams, including Scrum Teams. Scrum integrates the idea of humility indirectly through the Sprint Retrospective, which follows the idea of constant improvement.
All members of a Scrum Team need to have the humility to assume that they may have made a mistake and have the courage to admit to those mistakes, allowing themselves, and ideally others, to learn from them.
This principle is also important for a Product Owner to keep in mind concerning their product. Improvements on a product are always possible and most often necessary to remain competitive. Countless products and entire companies have failed because they believed to have the perfect product already. They stopped to keep an eye on the competition carefully and were eventually outperformed by them.
Principle 5, titled “Cover and Move”, applies in an abstract sense to Scrum Teams. Cooperation within the team and between different teams is crucial for the success of any endeavor. Succesful cooperation relies on those cooperating to trust one another, an aspect which Scrum emphasizes with its values.
In a situation with multiple Scrum Teams working on one product, this idea can also be understood as teams coordinating to support each other for the greater good, even if doing something undesirable. If Team A wants to develop feature X and needs support from Team B, Team B should feel responsible for helping out, even if it would much rather work on developing feature Y on their own at the same time. For this to be successful, it requires all teams to be willing to be the one to move and to be the ones to cover evenly.
Principle 6, simply titled “Simple.”, can support many aspects of Scrum. The idea is to simplify plans, missions and goals to a level that everybody can understand them.
Product Backlog items are a prime example: lengthy, convoluted tickets in Jira that nobody fully grasps will more often than necessary lead to misunderstandings and miscommunications. Therefore, it is the responsibility of the Product Owner to make those items as simple as possible.
The same holds true for the Product Goal, Sprint Goals and the Product Owner’s explanation of why a Sprint will be valuable. Scrum deals with complex problems, and one key way to deal with that complexity is to break it into single instances of more simple problems, which everybody can work on together more easily.
Principle 7, “Prioritize and Execute”, is an idea built into the Product Backlog in Scrum but can support other aspects as well. The Product Backlog ordering reflects what is believed to deliver the most value, and those highest value items will (likely) be pulled into the next Sprint.
The same idea is found in Scrum Guide with regard to the Sprint Retrospective, in which the highest priority items should be addressed first.
Many Development Teams benefit from applying Work-in-Progress (WIP) Limits, a concept that is essential to Kanban. What this does is acknowledge that doing too many things at once can easily become chaotic. Therefore, only a small number of things are started and finished before the next ones are started. This idea is highly in-line with the Prioritize and Execute principle.
Even meetings can benefit from a prioritized approach. This is one of the desired outcomes of the time-box.
Principle 8, dealing with the decentralization of command, shows interesting parallels to Scrum’s team model. Communicating with too many people becomes overly complex. Thus teams are broken down into more manageable units and equipped with a high degree of decision-making power on the specific issues with which they are dealing.
In turn, this requires a clear overarching goal, which guides developers in their daily decision making. This emphasizes the need for clear Product Goals and Sprint Goals and potentially for company goals.
Furthermore, it requires the specific empowerment of these small units to be allowed to make a decision; without this, decisions will simply not be taken. In this sense, this principle’s appeal is particularly to those managing Scrum Teams; encouraging them to gradually delegate more and more decision making power into the Scrum Team.
Principle 9, “plan”, is partly reflected in Scrum in the form of the Sprint Planning. Going beyond that, it outlines good practices for work in scaled Scrum environments.
Even when several or even many Scrum Teams work on one product, only one Product Owner is responsible for the product. While a Product Owner with one Scrum Team may do most of the Product Backlog management themselves, in scaled Scrum, more responsibility needs to be handed to the Developers.
How this is done is left to the Scrum Teams, and principle 9 provides a useful guideline. The Product Owner should retain the planning on a very abstract basis, determining the general direction and finding ways to communicate those clearly. The Product Vision and current Product Goal are useful tools for this.
A group of representatives from the Developers of the different Scrum Teams may then take the current Product Backlog and — in line with the current Product Goal — take responsibility for different items or blocks of items. In the next step, each team then refines and prepares the items: autonomously, but lead by the Product Owner via the clearly communicated vision.
Principle 10, dealing with leading up and down the chain of command, is applicable to how the Scrum Team deals with its management. Rather than being reactive to orders and announcements by the management, the Scrum Team as a whole should identify the responsibility in itself. Almost always, there are ways to make the needs of the team more transparent towards the management. Almost always, there are ways to prepare solutions that the management can work with.
It may at times be easier to establish an attitude of “The impediment now lies with the management, it’s their issue now. If we cannot work properly, the blame for that is on them”. The result of this is, however, a negative outcome overall. The product will be delivered later, worse, and/or with a higher budget than it could be.
A crucial aspect of self-management in a Scrum Team is thus to lead not only itself but also to take leadership towards its own leadership.
Principle 11, decisiveness, is a key characteristic that Scrum Teams need to establish. Scrum Teams typically deal with complex problems, meaning there is no way to know all the facts in advance and to find the perfect solution. While no team should start working without a plan, it is also not necessary to have a perfect plan.
The willingness to do something, even at the risk of that something turning out to be wrong, is crucial for creativity.
Product Owners must be willing to run experiments, even if it means that a week of work of the Developers yields nothing beyond the insight that it didn’t work. This attitude is important for a Product Owner to establish with themselves and, perhaps more so, with stakeholders. A mature Product Owner is willing to make decisions decisively, even when they are risky.
Analogously, Developers need to be willing to make decisions. Any decision will result in something on which feedback can be gathered later, and new insights can be gained.
Principle 12, highlighting the apparent paradox of “Discipline equals Freedom”, should immediately resonate with Scrum practitioners. Sticking with the Scrum framework’s flow, diligently conducting the Scrum events, and internalizing and practicing the values may all be difficult and require discipline. However, doing so provides the basis for freedom in many other areas.
Following Scrum makes self-management possible, moving more decision-making ability, i.e., freedom, into the Scrum Team’s hands.
My Personal Comment
The ideas presented in the book may come from a source, which many people associate with rigid hierarchies and “traditional leadership”. It seems clear to me, though, that the principles are clearly applicable and helpful in agile environments.
Boiling down the entire book into a single statement, I would say that the core idea is — as the book’s title says — Extreme Ownership. Principles 2–12 are supporting and expanding on the idea of that first, core principle.
When working in an environment where quick reactions are necessary (i.e., an agile environment), there is simply no time and no value in clearly dividing all responsibilities and hoping that it will work out exactly that way.
What some call “whole product focus” or “shared ownership of the product” boils down to the idea that every single person involved in the development should have an active stake in its success and do whatever is necessary to help it succeed. Excuses like “not my job” simply do not cut it if you wish your product to be successful.
Establishing and fostering an attitude of Extreme Ownership within yourself and within your team(s) will make them move agile, more innovative and creative and speed up your empiricism.
The book is definitely worth a read, especially for Product Owners and Scrum Master.
