Extreme Ownership For Product Teams
Over the last few weeks, I have been listening to Extreme Ownership by Jocko Willink and Leif Babin. The book covers lessons learned by Navy Seals Leadership in Iraq. I enjoyed the principles they teach in this book and saw how they apply leading great product teams.
I identified how to apply the strategies laid out in this book to product development. The book is extremely well organized and this post retains the same structure. The book has three main parts Winning the Battle Within, Law of Combat, and Sustaining Victory.
Part 1: Winning the Battle With In
Principle #1 Extreme Ownership
No matter what the reasons for failure, as the leader, you are responsible for the outcomes. This is no different on the battlefield than it is in the product management field. I am not talking about failures during the experimental process of build, measure, learn, but product leaders must take responsibility for the internal failures such as bugs, miscommunications, setting and missing unrealistic targets, slow development velocity, and so on. As a product leader its incumbent to take on responsibility for those team failings. Extreme Ownership is about turning the blame back on yourself as the leader: The team released a bug or poorly designed feature because the product leader didn’t provide enough clarity or ask the right questions. The team missed the goals set because the leader set goals that were unrealistic or hadn’t communicated the importance of meeting those goals to the team. The team didn’t deliver in a timely manner because the leader hadn’t conveyed the urgency or made reducing technical debt or using best practices a priority.
Principle #2 No Bad Teams Only Bad Leaders
This principle is basically a follow-on from the above. If leaders don’t accept responsibility and instead blames external circumstance or their direct reports, the team will fail. If a leader exemplifies ownership and demonstrates what’s expected of the team, than the team will follow suit.
Additionally, “it’s not what you preach, it’s what you tolerate”. If you tolerate people on your team not accepting responsibility or dragging the team down, you have enabled those team failings. It’s often easier to blame another person for dragging down the team, but if you, as the leader, don’t provide feedback or coaching than you are now equally responsible.
Principle #3 Believe (in the Mission)
In product teams, it is important to believe in the mission. Nothing reduces the velocity and quality of product development more than people “not believing in the mission”. Always clarify the mission or purpose. Once you understand why the product goals are the goals, or why this feature is the most important to do next, you need to relay that information down the chain to your team.
Additionally, put yourself in a manager’s or leader’s shoes. Why are they asking this of your team? You might think it’s counterproductive or overly challenging, but what are the high-level needs of the business or users? Sometimes leaders need to push teams to accept pain and sacrifice now to excel or avert disaster in the future. It takes courage to admit when you don’t understand the mission set out by the company leaders. If you can’t understand why, ask.
Principle #4 Check the Ego
See #1 and #2. It’s your fault, always. No matter how much you want to blame someone else. Part II Laws of Combat
Principle # 5 Cover and Move
In larger tech companies people can get really focused on their goals, KPIs, and narrow scope. They can often forget the broader mission of the company. It’s important for teams to have that kind of focus and ownership.
However, it can get in the way of partnering to create an even better experience for users. The cover and move strategy is a defensive maneuver where different units, often from entirely different groups, support one another while moving through enemy territory. In spite of their different missions. Product teams need to be able to collaborate with other teams even when they have different strategic objectives. It’s about the wider product mission, not just your team’s goals.
Principle #6 Simple
I’m currently working with new graduates to launch new products as part of an onboarding program. They have very limited time to launch and iterate their products. To accomplish launching and iterating on such a short time frame we have to rely heavily on simplicity. Cut away any features that are nice to have but not necessary to provide the core value.
As a product leader, you also need to be able to simplify the product mission, the KPIs. Communicate simply and concisely. The authors drive home that simple directions are often easier for teams to implement than complex ones.
Principle #7 Prioritize and Execute
Building products is basically an exercise in prioritization and execution. It’s easy to feel like everything is a priority or that the priorities are changing daily. Having a weekly, bi-weekly or whatever works for your team cadence for setting and executing priority keeps people focused and less stressed.
You do need to be able to react quickly as a product team, but if priorities change frequently they can cause paralysis for a team. Having the discipline to wait a couple days to change team priority can ensure focus and execution with minimal loss in agility.
Principle #8 Decentralized Command
Teams, including product teams, shouldn’t be larger than 4–6. Every team I have been on has been in this range or when it got larger it split almost naturally.
Part III Sustaining Victory
Principle #9 Plan
Planning is a key part of accomplishing the mission. Keeping the plan as simple as possible makes it easier to communicate, execute and change when needed.
The same goes for product teams. When designing features keeping them simple makes them easier to implement. Keeping products simpler makes maintaining and improving them easier. In general, make sure plans are simple and easy to follow.
Principle #10 Leading Up and Down the Chain of Command
This principle has two parts: up and down. For leading up the chain as a leader you should be identifying what the needs of the people up the chain are and understand how they might be making decisions at a higher level. This means, that if you need to provide status updates, try and identify what someone at that level needs to know. If they keep asking you for more detail it means you aren’t providing the right level of detail. Basically it’s your job to help others lead from above. If you are having issues, it’s your fault not theirs.
Conversely, you need to help provide the bigger picture to people who report to you. They can often get lost in the details. Make sure that you are helping lift their heads up and see the bigger picture. This helps them understand both the motivation of their work and also raise issues they may see with their work and accomplishing the broader mission.
Principle #11 Decisiveness amid Uncertainty
This principle can be distilled into understand the downside risks of action or inaction. The example provided in the book involves life or death, but in products we can often have some pretty big downside risk: losing critical data, privacy, identifying theft, etc.
Users can be forgiving when the result wasn’t due to reckless negligence. Deciding between shipping a buggy product or not, you have to consider the downside risk. Will a bug result in loss of money, privacy, or identity, or will it just lead to an imperfect experience. In the former case, I wouldn’t ship it, but the latter is less clear. If we were able to learn it might be the right choice to ship the product with known issues.
Principle #12 Discipline Equals Freedom-The Dichotomy of Leadership
Being disciplined creates a kind of freedom. Sometimes you have to make a disciplined decision that goes against what’s comfortable or easy. Maybe you have fallen in love with your failing product? You want to keep working on it, but the metrics are always against you. You need to make the right call and end the product. Move on to a product with more opportunity for success.
Jocko is personally disciplined as well. This has resonated with me and what got me to read this book. He hypothesizes that creating these disciplines will actually provide more freedom. If you are disciplined in time management, regular sleep cycle, morning routine, etc, you will have more energy and time to dedicate to what matters. The freedom to accomplish what matters, not the YOLO “freedom” to chase the ephemeral.
In the technical field we undervalue discipline. We take pride in wearing t-shirts and jeans, having toys and messy desks. Bucking the corporate structures and superficial order. I wouldn’t want us to implement a dress code or military cleanliness expectations, but there are disciplines that can generate high performance. That enable people to focus, execute and achieve high impact. I have been seeing the fruits of those disciplines in both my work and personal life, even while my desk is a mess and I wear a t-shirts, jeans and have long hair.