How to Make OKRs Actually Good 🎯
Outputs vs outcomes, a simple process to get started, and examples from successful companies.
OKRs is the world’s most popular — and divisive? — 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.
So, 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 works 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: