OKR mistakes and how to avoid them

Using OKRs is popular at a lot of companies and has become a golden standard for a lot of companies. But just like how companies start their agile transformation because they heard it was good but without understanding what it is really about. I've seen the same thing happen where OKRs are misunderstood.

What is OKRs?

OKR stands for Objectives and Key Results. An objective is a higher level goal and does not necessarily need to be easily measurable. Each objective can then have a number for Key Results (KR) to measure progress towards that higher level goal.

Mistake #1 - Treating OKR as a single thing

The largest mistake I've seen is when OKRs are treated as a single thing (Objective Key Results AKA Key Performance Indicators (KPI)) when it's really a combination of two things with a clear hierarchy. When every single KR have their own objective, you also tend to make mistake #2 and/or #4 below.

Note that using KPIs instead of OKRs is not a bad if you know you are using KPIs. But if you are trying to use OKRs, using KPIs (without the objective) is a mistake.

Mistake #2 - Os and/or KRs are just tasks

This typically happens in an organization where individual OKRs are used. Everybody need their own KRs so the easiest way to accomplish this is to just take something that needs to happen and call it an OKR (ex: "Implement the Foo component").

Mistake #3 - Objectives change every quarter

If objectives change all the time it means priorities change all the time or the objective is too short term. And organization where this happens should look at if some of the objectives really are KRs and/or consider what is the longer term objective to achieve.

Mistake #4 - Os and/or KRs defines the how

Since Os and KRs typically span over a longer period of time, if they define how something is expected to be implemented (or released) the team will be bound by an early decision on how to achieve a goal rather than letting the team make that decision when needed. By defining early how to do something you risk exploring the wrong solution or will have to spend time on changing OKRs.

Mistake #5 - KRs cannot be measured

Not every detail of work needs to be measured but if you have a KR that cannot be measured (or can only be measured as a binary - either you are done or not done) it will be time consuming to follow up on the KR and see how it progresses. This can somewhat be mitigated by defining how a HR is measured upfront (ex: "If the KR is implement Foo, we call it 10% complete when design document is approved").

Mistake #6 - 70% success on each KR is the goal

There is a recommendation that every team should aim high and hence 70% success on KRs is considered success. For some KRs this could make sense when you set an aggressive target like increase performance by 20%. But there is a risk that you end up with all your KRs being 70% done rather than actually reaching a certain goal. And if all your goals are ambitious and you never reach them the team will likely over time feel dissatisfied since they can never reach any goal set. Actually meeting 70% of the KRs and care less about lower priority KRs is probably much better for the organization both long and short term.

Note that this mistake is particularly bad when combined with mistake #2 as nothing will be completed. The team just ends up with a lot of unfinished work.

Mistake #7 - every layer of the organization needs objectives

Not everybody needs objectives. They make sense for large organizations and most teams. But a smaller team or individual can just consider the higher level Os and make their own KRs instead of spending time of breaking down a big O into a smaller. That just tends to be reusing a higher level KR as a lower level O. For example if a sales organization has an objective of being the market leader with their product and the KR is to achieve 50% market share. Then a smaller sales team that want to contribute by making 10 sales do not need their own objective in my option. And if you really want them to have their own objective I would suggest using the 50% market share as the small team objective.

Mistake #8 - No stack ranking of Os and KRs

Just like any backlog your Os and KRs need to be stack ranked. This way teams and individuals can easily negotiate to help each other by looking at what KR their work contributes to. There is a mistake within the mistake to be made here. All KRs that belong to the most important O is not necessarily more important all KRs of the second most important O. The objective stack ranking serve as a guidance to the KR stack ranking since most KRs of a high priority O should be higher priority than most of the KRs of a lower priority objective.

Good OKR mind-set

The O should explain why something needs to happen and the KR defines what needs to happen. The how it is achieved should be left to the teams to figure out.

You should also have a mix of long and short term Os and KRs. The longer term Os and KRs guide the organization at a high level and you then use shorter term Os and KRs to guide where you want the organization to focus short term. By long term I mean 1+ years and by shorter term I mean 1-2 quarters.

You should also think of Os as being defined top-down while KRs are defined bottom-up. I.e. stakeholders define the desired outcome with Os and the teams figure out how to bet measure success with KRs. Stakeholders and teams then agree on the KRs.

It is also OK to change Os or KRs at any time if needed based on new information, but I think you have a good set of Os and KRs if changing Os or KRs only happens if there is a significant and unexpected change in organization priorities. If you expect KRs to change often, you have the wrong set of KRs.

Good OKR process

I have come up with this process because I have seen it work well a couple of times. 

First of all you want an objective that essentially never would change (ex: be the market leader in X). That objective also needs one or two KRs that represent yearly goals so it would be adjusted every year (ex: we have 40% market share in X). Both of these are defined top-down in the organization.

If needed you might also have one or two objectives for the year (ex: become market leader in Europe) that help guide the organization on where to focus. Finally for a quarter you can further guide the organization with an objective (ex: become market leader in Germany).

I would have each team lead figure out what good team specific KRs would look like for each OKR cycle (ex: make 10 sales in Berlin). 

Finally with all these Os and KRs in place it is up to the team to suggest what activities would contribute to the goals already set. But those activities are not Os or KRs - it is just a backlog for the team on how they plan to achieve the given KRs.

The KRs should be picked in such a way that they are easy to objectively measure and hence become easy to put on a dashboard. That way you can continuously follow up on where you are compared to the goal of each KR.

Every team is different

The Os and KRs will likely look very different depending on what type of work the team is doing. And they are really just tools to guide the team (on a higher level) on what is important and how progress towards those goals look like.