Extreme Product Ownership

Lessons for leading a product and teams from "Extreme Ownership" by Jocko Willink and Leif Babin.

I recently had the pleasure of reading “Extreme Ownership” by Jocko Willink and Leif Babin. Jocko and Leif are two ex-Navy Seals and have spent a large portion of their training learning how to lead effectively. Their book has some excellent insights into how anyone can, and should, be a leader, no matter what their role. I read this book with the focus on Product Ownership, and have some key takeaways that I can apply everyday in my job. 

There are no bad teams, only bad leaders 

A strong leader will do everything in their power to help their team achieve their goal. They aid the team in compensating for their weaknesses, thereby continually boosting the team morale and keeping the energy levels high. 

A poor leader will do none of these things, and will always result in poor team morale. This in turn leads to bitterness and pettiness within the team, where each team member will try to pull another down rather than boosting them up. 

Have a clear vision

If a Product Owner were to begin her product vision with “I suppose we could do this” or, even worse, “I don’t have a very good product vision”, then her teams will quickly dig in their heals and be without a purpose. Team energy would immediately drop and the Product Owner would wonder why her teams were not producing good work. 

For reasons like this, leaders should be analysed and scrutinised early and often. This could be a manager, Product Owner or Scrum Master. If these key individuals do not perform from a leadership perspective, then the likelihood of a failed project inflates quickly. 

Leading the Boat Crew

In their book, Jocko and Leif give the example of a boat race they were having during training. Each boat crew had a leader. For the first race, Boat Crew II had a proven, strong and assertive leader. He was able to kick his crew into gear from the start, despite the fact he had never lead them before. 

Boat Crew VI, on the other hand, had a leader who was poor in decision making and lacked willpower. For the first race, Boat Crew II won by a large stretch. While Boat Crew II members were ecstatic and pumped at their win, Boat Crew VI were bitter and resentful towards each other. What was worse, the leader of Boat Crew VI blamed his crew for the loss, saying they weren’t up to the job. 

Then the commander had the idea to switch leaders to see what would happen. Obviously, Boat Crew II’s leader was not pleased, but Boat Crew VI’s leader was more than pleased – he was finally going to get a good team! 

The commander was surprised with what happened next. Boat Crew VI’s new assertive leader kicked them into shape from the beginning, shouting orders and getting them to work together. Boat Crew II already had some experience working together, but with a poor leader they fell apart. Boat Crew VI won. 

Leadership is the biggest factor in any team’s performance. Without a strong leader, the team will surely fail. 

Each leader should have a definite goal of what they are trying to achieve. For the Boat Crew leader, it was the beach marker. Setting small, certain goals instead of vague, far off ones will help the team focus and hold themselves accountable for reaching their target. 

Hold your team accountable

A good leader will have a high standard of performance. If she sees a weak team member, she will help in building  them up and developing the skills they lack. At the end, she is left with a better team and a grateful team member. However, people must be held accountable for substandard performance, otherwise the leader will face the situation where her team is sub-standard because she has let it become the norm. 

Above all, a leader must develop a culture of leadership. Just like a good teacher develops a culture of learning, a good leader will have junior leaders ready to step up temporarily to get a job done. She should encourage that each junior leader within the team require the highest standard of performance possible from the other team members. 

Above all, a leader must develop a culture of leadership. Just like a good teacher develops a culture of learning, a good leader will have junior leaders ready to step up temporarily to get a job done. She should encourage that each junior leader within the team require the highest standard of performance possible from the other team members. 

Check your ego 

Everybody knows and understands how many egos are associated with office politics. But it is pride that makes us think that we are never a part of it. Before you respond in a meeting or a conversation with somebody, check your ego. 

In Task Unit Bruiser, it was “insisted that our uniforms be squared away and our haircuts military regulation”. The team held themselves and each other to a high standard. They understood that humility and discipline now would lead to trust and high performance later. 

In the software industry, there are often ways that teams fall short of what is expected of them. Did you leave your documentation to the last minute? Did you avoid using Test Driven Development because it was too steep a learning curve? Did you forget to reply to that email? 

If you put your own personal incentives ahead of the team’s success or, worse yet, put more preference in your own laziness, then you will play a destructive role in the team. 

Don't give into laziness

I find it very easy to give into tiredness after a long day of meetings and not bother checking acceptance criteria correctly or leaving writing that email until the morning. It’s not that urgent, it can wait! Eventually, these shortcomings lead to some failure. They might even lead to failures you had not anticipated, and upon first glance, don’t appear that you are to blame. 

But when one of your teams makes a mistake, there is only one person to blame: you. You were supposed to lead them and in failing to do so, they have failed. Jocko advises a senior leader on what he should say for an upcoming meeting with his boss. He needs to update him and say why the product is failing miserably. 

 “Our team made a mistake and it’s my fault. It’s my fault because I obviously wasn’t as clear as I should have been in explaining why we have these procedures in place and how not following them can cost the company hundreds of thousands of dollars. You are an extremely skilled and knowledgeable superintendent. You know more about this business than I ever will. It was up to me to make sure you know the parameters we have to work within and why some decisions have got to be run through me. Now/ I need to fix this so it doesn’t happen again.” 

Are you a leader whose team suffered a heavy defeat? Don’t think it’s your fault? 

Check your ego. It’s your fault. 

Prioritise and execute 

Difficult situations often arise in the business world, particularly for team leads and Product Owners. New requirements are coming in on a regular basis for each team, new bugs are being raised against teams during their sprints, daily meeting requests fill up our calendars, and then we have to try to get some work completed. 

It is easy for any Product Owner to become over whelmed with the workload on their to-do list. In these situations, Jocko and Leif suggest you “prioritise and execute”. Leaders must remain calm in any situation. As soon as a leader loses his temper or panics, he has lost the respect of his subordinates. 

In such situations, Product Owners must take a step back to visualise the whole picture. Since the direction of projects is constantly changing, particularly in the software industry, we as Product Owners must not have our sites fixed on a single goal. Since the goal is changing, we must be able to step back to see what must be planned and prioritised. Once we have a plan and a list of priorities, we execute. 

How to prioritise and execute

Jocko and Leif give a list of tasks to prioritise and execute in a difficult situation. Practice these steps so that they become ingrained into your way of working. 

• Evaluate highest priority problem.
• Lay out highest priority in simple clear terms. 
• Develop a solution. Seek input from key leaders and team. 
• Direction the execution of solution. Focus all efforts towards that priority task. 
• Move to next priority problem. Repeat.
• When priorities shift, notify up and down the chain. 
• Don’t allow to get fixated. Step back constantly to see other problems and rapidly shift as needed. 

A key follow on from “prioritise and execute” is that we should never try to do everything at once. Trying to accomplish 5 things at the same time will lead to most of them failing or having them half completed. 

Don't panic! Prioritise and execute.

Leading down the chain of command

Most people are familiar with the concept of leading down the chain of command. Senior leaders do not need to understand the intricacies of their more junior members. By knowing too much about something, it is very possible for senior leaders to become bogged down in the details, rather than handing off the responsibility to a junior member. 

Communicate the What

As a Product Owner, I must convey the “What” to my teams as best as possible, answering their questions about requirements or at the very least, pointing them to the person that can answer the questions. Once I start delving into the “how” of a solution, I have immediately lost my position of leadership. Straight away, the team have turned from a vision-focused attitude to one of how are we to accomplish this? The Product Owner must learn to step back from the technical side and entrust it to their team. 

Communicate the Why

The above problem is common, however the more pervasive issue that occurs is where the senior leader fails to communicate the Why. Why is your team putting in this requirement? Will it help the product? How will the end user use this requirement? Without putting across the why, the team cannot understand the best solution to the problem. It is very possible that the requirement is not what the user needs to accomplish their goal. 

When a Product Owner is discussing requirements with his teams, the What and the Why are the key issues he needs to get across. By leading down the chain in this way, and entrusting the how to his teams, the requirements can move in the best direction forward. 

Leading up the chain 

Leading down the chain is a very clear concept. Essentially, it is about senior leaders leading their junior members in the best way forward by communicating the what and why. 

Leading up the chain is something many people struggle to understand. Yet once you understand it properly, it becomes a powerful skill. This lesson is the most valuable in the whole book, and rings true with my daily tasks. 

My leader isn't leading

A problem that everybody comes up against, whether you are a junior developer or project manager, is that we regularly come into situations where nobody is willing to lead. 

For example, a junior developer receives a bug in her backlog one morning when she arrives into the office. The bug contains 2 lines describing briefly what happened to the user, but there are no logs attached, no steps to reproduce, nothing except a brief overview. 

The developer looks at her screen, spends an hour trying to recreate the vague situation that has been described and eventually huffs and gives up. At lunch with her workmates she complains about how terrible the bug author is and does not know how to proceed.  

What should this developer do in such a situation? She is lacking leadership from the bug author and cannot proceed without doing something. Jocko and Leif say that if you are not being led, then lead. 

In the case of the junior developer, it is up to her to contact the bug author, and give a list of details that must be filled out before she can continue with the ticket. 

Reach out

For example, an email to the ticket author might look something like the following. 

Hi James, 

I see you raised a ticket against me this morning. Before I proceed with solving the issue, there are some details I require from your system: 

Product version 
Logs / trace files 
Steps to reproduce 

I cannot proceed with your ticket without the above details.  

Best Regards, 

clara.

Here, Clara has led up the chain of command to the bug author. 

From a Product Owner’s perspective, we come into situations constantly where no direction is being given, and communication is vague and implied. In these situations where our colleague is unwilling to lead, it is up to us to lead them. 

State the problem, propose a solution

If, for example, a senior manager contacts you as a Product Owner, asking you to assign a responsibility to one of your teams without giving any details about what is an expected outcome or what tasks are involved, do not simply say yes. 

Tell your manager that in order for your team to take on this new responsibilty, you first need a list of items that need to be completed and a list of expected outcomes. Once you have this information, you can then approach your team and communicate properly what is required of them. Otherwise, they will become frustrated that you are asking them to do something, but don’t seem to know exactly what. 

Learning to lead up the chain of command is the most valuable skill I have learned so far as Product Owner. The wall most people run into with this lesson is this: If your leader isn’t leading you, then it’s their problem. This is false. Your leader will still require you to get the job done. It is up to you to explain what you need in order to get there. If you want to stand to your senior management and colleagues, learn this and practice it every day. You will make mistakes getting it right, but will be very respected once you come out the other side. 

State the problem, propose a solution.

Summary 

Leadership is a part of every job. You do not need to be a manager or in a particular industry to utilise these techniques. Teachers, doctors, developers, recruiters can all find benefit in these skills and use them to accelerate their careers. 

If you are interested in getting started as a leader, I recommend reading “Extreme Ownership” by Jocko Willink and Leif Babin. 

To summarise: 

• There are no bad teams, only bad leaders. 
• Check your ego. 
• Prioritise and execute. 
• Lead down the chain of command. 
• Most importantly, lead up the chain of command.