How to Create Good OKRs

 

Sign up here for our newsletter on globalization and localization matters.

OKRs is the world’s most popular goal setting framework.

It stands for Objectives & Key Results, and is used by companies and individuals alike to define goals and track their outcomes.

• Objectives are qualitative descriptions of what you want to achieve. They are short and inspirational. E.g. Increase application speed.

• Key Results are a set of metrics that measure your progress towards the objective. E.g. Bring API response time under 1 sec for the 95th percentile.

They were famously introduced at Google by John Doerr, in the early 2000s, and they spread rapidly across big tech and startups alike.

However, OKRs are way older than that.

John Doerr learned about OKRs from Andy Grove during his time at Intel. Grove introduced them in his seminal book High Output Management, in 1983, but Doerr recalls hearing about them as early as in 1975!

Despite almost 50 years in the business, there is still controversy on how to create good OKRs. Companies struggle with the right formulation, cascading goals, following up with their teams, and more.

Examples online are often incomplete, and it isn’t clear how to adapt them to your use case.

This article is a primer on OKRs and how to work with them. We will cover:

• What makes OKRs special — why they are so successful and widespread.

• Outputs vs Outcomes — the key separation to make OKRs effective.

• Beyond OKRs — frameworks and ideas that complement OKRs.

• How to create OKRs with your team — a lean process and tips to get started.

• Real-world Examples — from the likes of Atlassian, GitLab, Buffer, and more.

Let’s dive in.

What makes OKRs special

OKRs are so dominant because they bridge a painful gap in every company’s life: the one between goals and operations.

On the one hand, companies have broad goals that are set on a yearly or multi-yearly basis. On the other hand, they have operations that run the business. It isn’t trivial to make sure that the latter work effectively towards the former.

OKRs do so by providing alignment and scalability.

• Alignment — they make the team focus on a small set of outcomes, on a short timeframe.

• Scalability — multiple teams can contribute to the same OKRs by cascading goals. This is what makes OKRs work for big companies like Google, and small startups as well.

The first time I encountered OKRs, I remember asking myself: is this so hard that it requires a framework? Why is it any better than just having teams decide what to do for the quarter?

In my opinion, the secret sauce that sets OKRs apart is that they focus on outcomes rather than outputs.

Outputs vs Outcomes

OKRs describe what you want to achieve (objectives), and how to measure success (key results). They are not prescriptive on how to get there, which stays under teams’ control.

Teams are responsible for defining initiatives that lead to matching relevant key results.

This separation between key results and initiatives is crucial, but it is not easy to pull off. Sometimes it is hard to find good measures for key results, so you may resort to using deliverables.

Let’s make an example: we want to improve the observability of our software by instrumenting it with dedicated tools and automatic tagging of logs. On a first try, we may create the following OKR:

• Objective: Improve how we instrument our software

• Key Result #1: Integrate an APM tool (e.g. Datadog)

• Key Result #2: Create labels to tag logs automatically

The problem with these KRs is that they are things to do, rather than outcomes. Integrating a tool and creating labels isn’t a measure of success.

Better KRs for the same objective might be:

• Key Result #1: X% of all user-facing requests travel through instrumented services.

• Key Result #2: Y% of errors from logs are labeled automatically.

Now we are onto something. This is at the same time 1) less prescriptive, and 2) more focused on the outcome.

The separation between key results and initiatives is not black or white — there are situations where using the latter is fine. It is so when:

1. Delivering the initiative is a good proxy for success.

2. You are reasonably sure about the way to go, so it’s ok to be prescriptive.

In this case, for example, you may add a third KR about setting a ceremony to review the metrics:

• Key Result #3: Hold 3 monthly meetings to review the instrumentation status

This is prescriptive and looks like a thing to do, but it is fine — having the monthly reviews puts the process in place and already sounds like success.

Finally, when it comes to goals and key results formulation, both Matt and Julien from the Refactoring community report using the SMART format. This is useful and may act as a checklist to validate items against.

Beyond OKRs

Although widely used, OKRs do not cover everything you need about goals and planning. Here are a couple of other ideas that I love and can be used in combination with OKRs.

GEMs

The separation between KRs and initiatives is so important that some people believe the OKR framework is a bit flawed because it doesn’t address the latter explicitly.

Kathy Keating proposes an alternative format to OKRs called GEMs, which stands for Goals, Measures and Experiments. It explicitly adds the experiments part to the objectives and key results (now called goals and measures).

It might look like a simple change, but names do matter and I love it. You can find here the original article: 📑 Get your OKRs out of my GEMs.

Service Level Objectives (SLOs)

OKRs are for improving something or achieving something new. As a company, though, you also want to maintain what you achieved in the past and avoid regressions.

Avoiding regressions is just as important as improving things, and arguably heavier to track. At any given time, in fact, while you may focus on a few KPIs for improvement, you need to maintain all the rest of them.

Tracking these with OKRs is cumbersome because you would need to add a bunch of items that aren’t attached to any new initiative, and would therefore pollute the “real” OKRs.

SLOs were born to fill this gap. They stand for Service Level Objectives and collect the KPIs you want to maintain at a certain level.

You can set SLOs in combination with OKRs. Here is how Atlassian does it: 📑 How we work — a combination of OKRs and SLOs.

How to create OKRs with your team

Creating OKRs is a collective process. By involving your team in the creation process, you create focus and commitment towards the goals.

 

 

The ideal journey is a blend of top-down and bottom-up input. In a startup it may look like this:

1. Objectives — the leadership team sketches high-level goals. These are mostly qualitative, non-measurable, and based on themes that may span multiple quarters.

2. KRs — some initial KRs are created top-down, involving managers of the respective teams / functions. These KRs are totally provisional and serve as a basis for discussion.

3. Initiatives — the initial version of the OKRs is presented to the team. People come up with initiatives to achieve the KRs and adjust KRs themselves in the process.

4. Iterate — KRs and Initiatives are challenged and improved over a couple of rounds of iteration.

For a thorough description of an effective planning process, you can check out this great article by Lenny Rachitsky and Nels Gilbreth: The Secret to a Great Planning Process.

Julien Evano, Head of Engineering at IXUP, also shared with the Refactoring community their process to run OKRs across the company, from vision & mission down to the single Sprint: OKRs at IXUP.

You can find plenty of articles on how to create good OKRs. No company is the same, though, and everyone needs to iterate to eventually find out what works for them. Here are some tips that have worked well for me in the past:

• Don’t obsess over the right formulation — yes, KRs should be numeric, but you can really write them any way you like, as long as they measure success. Look at your KR and ask yourself “would I be happy to achieve this?” — if the answer is yes, then it’s fine!

• Avoid personal OKRs — if you are new to the process, start with team OKRs. Personal OKRs are tricky and can also backfire spectacularly if mismanaged.

• Max five — Five is kind of a magic number for OKRs. Don’t create more than 3-5 KRs for each objective, and have at most 5 objectives for each team. Ideally, the full OKRs should fit on a single page.

• Timebox the process — don’t spend a full month preparing quarter OKRs, leaving your team with two months to work on them. Give yourself tight deadlines to create good-enough items. Done is better than perfect.

• Don’t assume you will only work on OKRs — over the OKR period there will be setbacks, maintenance, and unexpected opportunities you will want to catch. Leave some slack to allow your team to work on them. After some iterations, we settled on assigning only 50% of the time to OKRs.

• Have someone accountable — appoint someone to be responsible for the whole creation process. This person should collect the materials, set meetings and deadlines, follow up with people, and make sure everything is done on time.

• 70% vs 100% rule — there is advice around creating stretch goals that people are happy to achieve at 70%, and there is also counter-advice around creating achievable goals to make people happier. To me it doesn’t really matter, as long as you are consistent with the strategy you choose. People adapt quickly to either way.

• Follow up — grade OKRs regularly: bi-weekly or monthly at most. Do not just create them and revisit them at the end of the period. You can attach the OKR check-in to other review ceremonies you already have to make it more natural.

Do you want to contribute with an article, a blog post or a webinar?

We’re always on the lookout for informative, useful and well-researched content relative to our industry.

Write to us.