11 Aspects Most Startups Get Wrong About OKRs and How to Fix it

Objectives and key results (OKRs) can be a powerful tool. But as with any framework or methodology out there, just applying it as others do will likely not yield the best results. It can even harm your organization.

I was asked countless times what I think about OKRs and if I would recommend them, so it is time to write this article. Unfortunately, the answer is not as straightforward as you would like. 

A Brief OKR Introduction

OKR stands for "Objectives and key results." OKRs are an almost ancient tool. Andy Grove introduced OKRs in the 1970s as the CEO of Intel. They gained popularity at Google around 2000.

An Objective describes a desired outcome. It sets the directions and answers the question, "Where do we want to go?"

A Key Result is a measurable outcome required to achieve the objective. It helps to measure progress toward an objective and answers the question, "How do we know if we are making progress?"

An Initiative is a project or a task that helps us achieve key results. Initiatives describe how we will reach our destination. They answer the question, "What will we do to get there?"

In the classic implementation, OKRs were defined quarterly to set the focus for the next three months. (More about this below.)

First, Ask "Why"

As with every tool, framework, or methodology we want to introduce in a company, we usually do well when we slow down, step back, and identify the problems we hope to solve.

We can only answer whether OKRs are the right tool and which shade of OKR we need when we understand the problem well.

What challenges do you want to solve through OKRs?

Problems OKRs Might Solve

• OKRs can help to create focus and alignment across the organization. Objectives express what matters most.

• OKRs can help to communicate what teams see as a focus for the next time horizon.

• Defining key results helps teams clarify how they can understand if they are making progress.

• OKRs help to define outcomes and monitor progress.

Where Things Go Wrong

Lured by the seeming success that other companies had with OKRs in the past, startup leaders sooner or later introduce them in the hope of supporting their company's growth. They often do so without understanding the preconditions needed and reflecting on the parameters that might need adjustment to make OKRs suitable for their organization.

Here are some of the mistakes I have seen in the past and how to avoid/fix them.

1. OBJECTIVES DON'T MATTER

The higher the pressure to develop objectives, the more people tend to bloat up their objectives with artificial ones.

A great litmus test for objectives is whether they serve the customer or the team. Every objective should either serve the customer or the team. Everything else is bloated.

Why?

In a startup, only customers and the team matter.

The customers, because they bring feedback and ultimately revenue and profits. The team, because they are the backbone of an organization and make or break the company.

OKRs should, therefore, either serve customers or the team (or both). Otherwise, the objectives are unlikely to create real business value.

2. LACK OF FOCUS

OKRs are a tool for focus and alignment. This means we should have few objectives. What "few" means depends on the size and shape of the company. A small startup might have 1-3 objectives for the entire company. A big corporation might have 1-3 objectives per team.

Whatever you do, objectives should align all the people needed to achieve the objective on that objective, which brings us to the next mistake.

3. TEAM-LEVEL OBJECTIVES

Many companies misunderstand the desire to combine self-organizing teams and OKRs and urge teams to define team-level objectives, that is, separate objectives for each team.

While it is commendable not to use OKRs to top-down instruct the team what to achieve and (worse) how to achieve it but allow the teams to figure it out themselves (based on higher-level objectives and a company mission), team-level objectives are not always the answer.

Team-level objectives work great when teams are value-stream aligned and own the stream from customer ideas to customer value entirely. This often isn't the reality of software startups still figuring out the value streams, how to structure teams, and how to deal with their growth.

Creating team-level objectives will harm those companies. Once every team has invented their objectives and invested time in making them clear and finding good key results, they will find it unpleasant or difficult to make time for other teams that depend on them to create value. Suddenly, teams have conflicting objectives that hinder the creation of business value.

Ultimately, companies should evolve their team topologies to support fast flow and team autonomy. As long as this isn't the case, having fewer and higher-level objectives is usually better and encourages cross-team collaboration.

4. EVERYTHING IS AN OBJECTIVE

Sometimes, an unhealthy dynamic can be observed around OKRs. Instead of congratulating teams for having great focus when defining only one or two objectives, teams are urged to do more.

This is the wrong approach. Having many objectives is not a great thing. It is a sign of confusion and lack of focus.

Furthermore, this often leads to creating objectives for all the work, even though it doesn't make sense. OKRs, for example, don't make sense for operational work. Teams with high amounts of operational work probably need fewer objectives.

5. USING OKRS AS KPIS

OKRs are not KPIs and should not be confused with such. We want to set ambitious goals with OKRs. They will lose their effectiveness if we use key results to measure performance.

Teams will define less ambitious key results when their performance evaluation or incentives are tied to how well they achieve the results.

OKRs done right increase focus and alignment and likely increase performance. However, they must not be used to evaluate the performance, or they won't have that effect. 

Measuring performance is a tricky and mostly harmful thing. Traditional management is so used to measure that they are willing to pay the price of reduced performance to have a feeling of control. In contrast, in high-performing organizations, less effort is spent on measuring performance, and more effort is spent on making performance possible.

6. SETTING QUARTERLY OKRS

Initially, OKRs were set in quarterly cycles. This made sense for companies like Intel and Google when they introduced OKRs. Some leaders claim that the rhythm of their company is quarterly and that it is sensible to have OKRs with that rhythm.

Companies are shifting towards delivering value continuously rather than in quarterly releases, making quarterly objectives less practical. Fast-moving companies learn quickly, within days or weeks, making quarterly goals seem too fixed. Engineers in these companies find aligning quarterly objectives with agile software development hard because things change too rapidly.

The length of planning cycles for a company should match how well it can predict the future and how clear its goals are. Startups with clear and specific goals should plan with shorter cycles, like six weeks or a month, instead of longer quarterly cycles with vague goals.

The worst combination would be quarterly cycles with very specific objectives, as the desire to develop those usually results in huge amounts of upfront planning, guessing, and discussion in a misguided attempt to remove the uncertainty. You are likely on the wrong track if you do this in your company. A better approach: Run more experiments, don't overthink the objectives, and get moving with your best guess. Action followed by feedback removes uncertainty.

7. A HEAVY OKR PROCESS

I see objectives as a way to formulate our best guess about the future, draw a picture of a desired state, and communicate it with others. I see key results as a way to make those objectives tangible and help us to understand our progress throughout the cycle.

This implies that it is okay to throw objectives overboard if we learn something new that renders them obsolete. It also means that if we have achieved the objective without achieving all the key results, that is also okay. If we see OKRs as a lean approach to creating focus and alignment that enable autonomy, we should not overdo them.

Companies often have a huge planning and alignment process around their OKRs spanning weeks or months. Usually, the failure to guess correctly in the last cycle leads to more planning and discussion for the next cycle. This reduces performance and increases frustration.

Less is more in the OKR setting process. Objectives are usually obvious and follow what was learned before. If it is a lot of effort to write OKRs down or align teams around them, there might be something off in the organization. 

Take this signal and reflect on how teams are structured, how the vision is communicated, how long the cycles are, how many objectives the company has, how connected teams are to customers, ...

Time is better spent on tackling these challenges than getting OKRs right.

8. OKRS SET IN STONE

With a heavy OKR process, it often follows that people are afraid of changing the objectives mid-cycle. After all, the investments in the objectives were so high and painful.

It is much better to have a lightweight OKR process to create alignment, focus on best guesses, and allow for change when the feedback from actions removes uncertainty. Nothing is worse than following the wrong objective because we don't listen to signals mid-cycle.

9. NOT THINKING ABOUT INITIATIVES

People new to OKRs sometimes fall into the trap of thinking too much about the O and the KR but not the I. After all, it isn't part of the acronym.

Nonetheless, this is where it gets exciting. Only when we map out the activities we plan to do to achieve the objectives and key results will we discover which skills we need, which people could help, and how much effort it will be.

This has the potential to uncover that a team needs another team to achieve their objectives. In other words, cross-team collaboration is required. Thus, cross-team objectives should be defined rather than each team's objectives.

10. INTRODUCING OKRS TOO EARLY

OKRs are one methodology for creating focus and alignment in a company. There is, however, danger in reducing agility too much in this attempt. Some companies are afraid of their team's seeming chaos and confusion and try to solve it with OKRs.

From my observation, this is often a sledgehammer approach. Sometimes, there isn't even clarity and understanding of the company's purpose.

The power of a purpose well understood by everyone in the company and used to guide daily decision-making must not be underestimated. It is way more powerful than OKRs and much more future-proof. Especially for young startups, I would recommend focusing on the purpose before investing time in an OKR process.

Only when purpose and mission are insufficient to guide the team or subgroups in the organization should a few objectives be introduced that make the direction more tangible.

11. NOT TRAINING AND INVOLVING THE TEAM

Whatever shade of OKRs you plan to introduce and for whatever reason, make sure to involve the team. This helps to find the best shade of OKRs for your company and promotes understanding of the process.

Additional training or coaching might help teams get used to the process and find an efficient and impactful way of working with OKRs.

Conclusion

Leaders tend to introduce OKRs too early, for the wrong reasons, or in the wrong shade. OKRs can be a powerful and supportive tool for company growth. They facilitate alignment and focus if done right.

Before introducing OKRs, go back to first principles: What are we trying to achieve? Why are we trying to achieve it? Which problem are we trying to solve?

This might lead to introducing OKRs but will give you much more clarity on how and in which form to use them. Or it might lead to something else that suits your company better.

What are your thoughts on this? Which challenges have you encountered when using OKRs? I would love to hear your success stories, too!