Team Objectives – Empowerment

NOTE: There is so much widespread confusion out there on OKR’s, it’s a very difficult topic to discuss because everyone brings their own very different experiences and perspective to the conversation.  If your company is using OKR’s today and you believe they are truly helping you deliver consistent innovation, then no need to read further. However, if you have found that for whatever reason this technique has not delivered the promised value, then I’d encourage you to try to forget anything you may have read or heard about OKR’s, and consider the points in this series of articles with an open mind, and see if they make sense to you.

Now that we know what actions we need each product team to pursue, we need to discuss how we assign this work in such a way as to empower the team.

The essential point of team objectives is to empower a team by a) giving them a problem to solve rather than a feature to build; and b) ensuring they have the necessary strategic context to understand the why, and to make good decisions.

The most important point to understand about team objectives is that first and foremost, they are intended to give the product team the space to come up with solutions to hard and important problems.

This is in stark contrast to a typical product roadmap which is providing the team with a prioritized list of features and projects to build.  If those features or projects do not solve the underlying problems, then we fail, even though we may have delivered what we were asked to build.

Assigning Problems To Solve, Rather Than Features To Build

Some people believe that the difference is not such a big deal.  If you think you need your team to build an app, then just tell them to build the app, rather than providing them the business and strategic context, and letting them figure out we need to build an app.

But one of the major lessons our industry has learned, is how work is assigned matters.  

David Marquet, a long-time advocate for empowered teams and author of the recent book Leadership is Language, argues “even when you want to be a more collaborative leader, you can undermine your own efforts by defaulting to command-and-control language we’ve inherited from the industrial era.”

There are many reasons why this is preferred, but the most important are:

• The best people to determine the most appropriate solution are those closest to the problem, with the necessary skills – the product team.
• We want the team to take responsibility for achieving the desired outcome.
• If we tell the team the feature we want them to build, then if that feature doesn’t provide the necessary results, we can’t hold the team accountable.
• If we give the team the problem to solve, and the space to solve it in the best way they see fit, the product team will feel much more ownership of the problem.
• If the first solution the team comes up with does not produce the desired outcome, they know they must continue to iterate until they do find a solution that does.

So Team Objectives are comprised of an objective (the problem that needs to be solved) and some measures of progress (the key results).  Let’s discuss each.

Objectives

The specific objectives will of course be a function of the type of product and the responsibilities of the particular product team, but typical examples of good objectives are:

• Reduce the frequency of parcels delivered to the wrong address.
• Increase the percentage of shipments delivered with next day delivery.
• Reduce the percentage of images flagged as inappropriate.
• Reduce the subscriber churn rate.
• Demonstrate product/market fit for an existing product in a new market.
• Decrease the time it takes a job seeker to find a new job.
• Reduce the operational costs of fulfillment.
• Reduce the cost to acquire a new customer.
• Increase the lifetime value of the customer.
• Reduce the percentage of customers that require customer service assistance.
• Reduce the average time spent handling a customer service call.
• Increase the percentage of new customers that successfully create an account.
• Reduce the time for a user to produce their first monthly report.
• Reduce the time required to deploy a new or updated service to production.
• Improve the site availability.

What’s most important about all of these examples is that they are problems to solve, and not features to build. 

Some are customer problems and some are business problems, but in each case, there are any number of potential solutions.  The point is that the product team is best suited to determine the most appropriate solution.

Notice also the example objectives are all qualitative.  The quantitative dimension will be discussed in the key results.

It’s also important to acknowledge here that many of the most important objectives will require the product team to either collaborate with other product teams, or in many cases, to collaborate with different parts of the organization to achieve the goal.  That is not only ok, but very much intended, although in practice this clearly depends on having a product manager on the product team that has a deep understanding of the business.

Key Results 

While the objective is the problem to solve, the key results tell us how we define success.

And it’s essential that we define success by business results (aka outcome), and not simply activity or output.

The second most common reason that teams go wrong with OKR’s is that they end up listing activities or deliverables as their key results.  Hopefully this is clear to you at this point, but just in case it’s not, the reason this is so much of a problem is that it is very easy to ship a deliverable, yet not solve the underlying problem.  In which case, we’re back to the same old problem we have with product roadmaps.

Generally speaking, we want two key results for each objective.  The first key result is the primary measure. The second key result is a measure of quality, sometimes called a “backstop,” to ensure that the first key result is not inadvertently achieved by hurting something else.

For example, suppose we consider the objective of: 

• Reduce the frequency of parcels delivered to the wrong address.

Now, the primary key result would likely be the actual percentage of incorrect deliveries.  But if we were to achieve that by burdening the ordering and fulfillment process, it’s possible to reduce the percentage, but also significantly reduce the absolute number of deliveries, which would not be a helpful solution.  So, potential key results could be measured by: 

• Reduce percentage of incorrect deliveries
• While ensuring that total deliveries continues to grow

Notice that while these key results do imply specific KPI’s, we don’t yet have the expected values or timeframes, because those will need to come from the team. 

The reason for that is that if we were to provide to the team explicit measures of success including time frame, they won’t feel that ownership over the commitment that we want in an empowered team.  So the actual quantitative values will come from the teams.

It’s also important to note that sometimes the most appropriate measure of success or KPI is not yet clear, especially in the case where it’s a problem we haven’t worked on before.  In this case, the team may need some time to better understand the dynamics and the most appropriate measures.  

A related issue is to be sure the team is not “letting the tail wag the dog.”  What that means is that sometimes a team will be tempted to define their key results by something that is easy to measure, rather than what’s most meaningful to measure.

Sharing Strategic Context

If we are to give product teams the space to solve hard problems, we must also provide these teams with the context necessary to make good decisions.

We need to share the strategic context, especially the product strategy, with the product teams for four main reasons:

First, it’s critical that the team has a deep understanding of the ultimate goal, and why this is an important problem to solve.

Second, we want teams to start thinking about how they each might be able to contribute to solving the key problems.

Third, we want the teams to start thinking through the implications of the upcoming work.  Perhaps there are dependencies that are not immediately visible. Or technologies or skills that we will need to acquire.

Fourth, we love it when teams express a special interest in working on specific problems.  We can’t always accommodate every team working on the problems they request, but we are certainly motivated to try.

With these principles in mind, we’re now ready to assign objectives to specific product teams.