OKRs: Mistakes I’ve made and seen

Recently I was another year doing the exercise of defining our OKRs, and came to my mind all the mistakes I’ve made and seen in all the cases I’ve been working on OKRs, so I thought that could be useful to gather and share them, maybe you’ll feel identified, or maybe helps you to avoid making some mistakes I’ve made, which I don’t regret in any case, they were useful learnings.

For those who aren't familiar, the Objective and Key Results (commonly known as OKRs) framework is a very useful tool to foster alignment and focus within a Company. In a nutshell, it consists of defining an objective, a goal to achieve, and some key results that will let us know the progress we are making towards that objective. 

Here are some of the mistakes I’ve made and why they are such a mistake.

Using OKRs as budget

The first mistake was to use budget goals as objective on the OKRs. Setting an objective like “Reach our planned EBITDA of 15M$” might sound pretty good for a CEO or the finance department, and definitely is something that we all want to achieve, but does it help to align the company and keep focus on the relevant topics? Not really, as everybody will have their own idea on how to achieve the budget goals, and that’s one of the reasons why we need the OKR framework besides the budget.

As an extra tip, in my experience on the OKR framework the objective should be qualitative, unmeasurable, and have the Key Results quantitative and measurable. Otherwise we wouldn’t need the Key Results, measuring the objective would be enough.

Use OKRs for VCP or bonus

Another issue I’ve seen or made is to use OKRs as the objective for salary bonuses or Variable Compensation Parts (VCPs). This is very tempting, because if you have done the exercise of setting OKRs properly, you have the things that matter, and you want to put your team effort on those things, and reward them if we achieve the relevant results. However I would discourage it, because OKRs should be an exercise of alignment and agreement top to bottom and down to top, and we have to be ambitious on them. Literature would say that good OKRs should have a degree of accomplishment around 70-80%. Your team will be much reluctant to set up ambitious goals if their salary is in play. In my opinion it is probably better for VCP to have a mix of budget and personal development goals and leave OKRs out of salary implications. 

Use OKRs as a roadmap

Another common thing I’ve seen is to use OKRs as a sort of a roadmap, setting up specific milestones as Key Results. An example of this could be to have an OKR like the following:

Objective

• Expand business to northern Europe to become a relevant European company

Key Results

1. Release website in Germany
2. Release website in Sweden
3. Release website in Norway

Here the key results are defining milestones of a defined plan, a roadmap, but this is not as useful as it should be for several reasons:

1. A milestone, or more in general a key result that is measured with yes or no is not very useful, as it doesn’t allow you to measure progress.
2. It is focusing on a feature, not on the impact of the feature. The correlation between the key results is actually not clear: What happens if we release the website in Germany but we don’t have users? Should we consider that we are progressing towards the expansion of the business in Northern Europe?

In this case I would opt for abstracting from the plan or roadmap we already thought of and think of metrics that really let us understand the progress. For example in this case could be users coming for northern Europe, or sales done to customers from that region. You’ll probably need to release the website to achieve so, but don’t mix the impact and the feature, don’t mix the why and the what.

Too many derived OKRs

When we work on OKRs we start with the Company OKRs, defining the Company’s objective and their Key Results. However these OKRs might be a little bit too generic for some departments, so we create derived OKRs for those departments. More specific OKRs that they can impact or influence, that if doing so they would be affecting the more general company’s OKRs.

This is very understandable, fine and healthy I would say. However we need to acknowledge that everytime we derive OKRs we are creating a small misalignment. So if we have Company’s OKRs and we create 3 departments’ OKRs, then the OKRs between those departments will be a little bit misaligned. If we create other OKRs for other sub departments, then the misalignment gets bigger, exponentially.

Think of it as the broken telephone game, the more steps there are, the more chance that what we get as result something that has nothing to do with the original phrase.

Here I would recommend to do a little bit introspective: If you feel that you can understand if your work is pursuing an objective and impacting some key result, then you don’t need to derive anything. So if you think that your department can impact directly on the Company’s OKRs you don’t have to create your own department’s OKRs. If that’s not the case, then probably you need to go a bit more specific.

Use OKRs as personal development plan

A consequence of the previous topics of deriving OKRs too much is to reach personal OKRs, which in my opinion is perverting the concept of OKRs, that remember, serve to create alignment by having multiple departments or people with the same objective. If objectives are individual they are going to hardly create any alignment. 

Added to this when there are personal OKRs they are usually mistaken with a personal development plan, setting up objectives for the individual to improve his/her performance and skills, which obviously is good for the Company, but will have a very loose link with the objective and definitely will not help create alignment and focus.

These are some of the mistakes and misunderstandings I’ve made and seen with OKRs. There are probably more, but no matter how you use them, just think about why you are using that framework, and if you are achieving that why. 

If you use them for alignment check if teams are more aligned after; if you use them to keep focus, check teams’ focus; or even if you use them to foster some data driven culture, check if you have achieved so. And keep on measuring, sometimes we focus a lot on setting up the OKRs, but the process of checking and aligning periodically is probably much more important, as focus and alignment is not a one off topic, but a process and a culture.