Why OKRs might not work at your company

After many years of being a very vocal advocate for the OKR (Objectives and Key Results) technique, in the majority of companies I meet, I have stopped recommending the practice.

That’s because, in so many companies, even though conceptually the technique is simple and sound, it ends up proving a waste of time and effort, and yields little if any results.

How can something so conceptually simple have such a hard time being applied in practice?

The short answer is that most companies are not set up to effectively apply this technique.

As I see it, there are three fundamental reasons for this:  

Feature Teams vs. Product Teams  

If the company is still using feature teams , as most unfortunately are, then the OKR technique is going to be a cultural mismatch, and almost certainly prove a waste of time and effort.

The OKR technique came from companies that had empowered product teams in their DNA.  OKR’s are first and foremost an empowerment technique .  

The main idea is to give product teams real problems to solve, and then to give the teams the space to solve them.

Yet the telltale sign of mismatch out there is that companies think they can “check the empowerment box” by giving the team objectives, yet still continue to tell them the solutions they are supposed to deliver – nearly always in the form of a roadmap of features and projects with expected release dates.  

Manager’s Objectives vs. Product Team Objectives  

The second issue is that the purpose of a cross-functional, empowered product team is to work together to solve hard problems.

Yet, in so many companies, each manager – the manager of engineers, the manager of designers and the manager of product managers – creates their own organizational objectives, which are then cascaded down to their employees.

While this may sound reasonable, and is not necessarily a problem for other parts of the company, in practice this means that these employees – when working with their cross-functional colleagues in a product team – are all working on their own objectives, rather than working collaboratively on the team objectives.

To make matters even worse, in many companies, there’s an additional level of complexity and dilution because they also try to implement individual objectives, so not only does the engineer inherit the objectives from her manager, but she also has to work on her own personal objectives.  

The Role of Leadership

And finally, and really the root of the problem, is that in the vast majority of companies I see that are struggling to get any value out of OKR’s, the role of leadership is largely missing in action.

They literally think that the idea is to let teams identify a set of objectives, and then let them pursue those objectives, and we’ll see where we are at the end of the quarter.

They think that empowered product teams, and this technique especially, is about less management.  But it’s actually about better management.

It is really any wonder why so many companies get so little value from this technique?

It’s no secret that most of the leading tech product companies use the OKR technique, or one of the variants.  And it’s also no secret how much success these companies have had.

Yet people are confusing correlation with causation.

Those successful companies aren’t successful because they use OKR’s.  They use OKR’s because it is designed to leverage the empowered product team model.  

And as I have tried to make clear with years of articles and talks, the empowered product team model is a fundamentally different approach to building and running a tech-product organization.

You can’t take your old organization based on feature teams, roadmaps and passive managers, then overlay a technique from a radically different culture, and expect that will work or change anything.

So in terms of actually getting the benefits of OKR’s, there are three critical prerequisites:

1. Move from the feature team model to the empowered product team model
2. Stop doing manager objectives and individual objectives, and focus on team objectives
3. Leaders need to step up and do their part to turn product strategy into action

The majority of my writing has been about the first topic.

For the second item, this is mainly education.

It is the third item that needs much more discussion, so in the upcoming series of articles on team objectives, we’ll discuss the role of leadership in effective team objectives.

First, we’ll discuss specifically how we empower teams through team objectives.

Then, we’ll discuss how we execute on our product strategy through action .

Next, we’ll discuss how leaders manage a portfolio of risk by sharing with teams how ambitious they would like them to be as they pursue the problems they’ve been asked to solve.

It’s critical to note that sometimes it’s not about the level of ambition, but rather, we need to occasionally make what’s called a high-integrity commitment , and we need to discuss how these are made and managed.

One of the common misconceptions about team objectives is that only a single product team should work on a specific problem.  On the contrary, much of our best work requires collaboration between teams, and there are several important forms of collaboration we’ll discuss.

As with any difficult technology-based endeavor, we need to actively manage this work, always being mindful to manage by coaching and servant leadership, and not to regress to command and control style management, and lose the benefits of empowerment.

Along with empowerment comes accountability , and we need to discuss what this means in practice.

Finally, we’ll summarize with the most important points to getting the real value out of team objectives.

Special thanks for Christina Wodtke and Felipe Castro for reviewing a draft of this article.