OKR Framework: Objectives and Key Results Explained

Created by Andrew Grove - https://en.wikipedia.org/wiki/Andrew_Grove

Overview

OKR stands for Objectives and Key Results, a goal-setting method in which a team states what it wants to achieve and then names the few measurable results that will show whether it got there. The Objective is the direction. The Key Results are the evidence. Google's own guide to the OKR framework, re:Work's Set goals with OKRs, sums it up in a handful of rules: objectives are ambitious and may feel somewhat uncomfortable, key results are measurable and easy to grade with a number, OKRs are public, and they are neither an employee evaluation nor a shared to-do list.

The method comes from Andy Grove at Intel. In High Output Management, his 1983 book on how he ran the company, Grove framed goal setting around two questions, as re:Work summarizes them: where do I want to go, which gives the objective, and how will I pace myself to see if I am getting there, which gives the key results. Grove built on Peter Drucker's Management by Objectives. According to What Matters, Grove's own name for the system was "iMBOs," for Intel Management by Objectives, and he made two changes that separate OKRs from MBOs: the goals were quarterly rather than annual, and they were divorced from compensation.

John Doerr carried the method out of Intel. He says he was first exposed to OKRs there in the 1970s, while the company was moving from memory chips to microprocessors (Betterworks interview with Doerr). The Wikipedia article on OKRs, citing Doerr's book, places this in a course Grove taught inside Intel in 1975. Doerr, by then at Kleiner Perkins, presented OKRs to Google's founders; What Matters dates that presentation to 1999, while Google's re:Work guide says early 2000. Doerr later wrote the standard book on the practice, Measure What Matters, published in 2018, and What Matters credits him with crafting the name "OKRs" itself.

The mental model behind OKRs is that focus, transparency and measured ambition beat long, private, vague goal lists. A team picks a small number of objectives, so the act of choosing forces trade-offs. Everyone can see everyone else's OKRs, so dependencies and duplicated work surface without a meeting. Google's re:Work guide grounds the approach in goal-setting research, including Locke and Latham's review of 35 years of goal-setting studies, which it cites for the findings that committing to a goal can improve performance and that more specific goals can result in higher performance. Key results are written as outcomes with numbers, so the end-of-cycle question "did we do it?" has an answer nobody needs to argue about. And because many OKRs are meant to stretch, a partial score is expected: re:Work puts the sweet spot for a grade at 60% to 70% and says that someone who always fully attains their objectives is not aiming high enough (re:Work).

Google also distinguishes two kinds of OKR, and the kind decides how a score should be read. Google's OKR playbook says a committed OKR is expected to score 1.0, and a miss needs an explanation, while an aspirational OKR has an expected average score of 0.7 with high variance. What Matters adds a third kind, the learning OKR, for cycles where the most valuable outcome is finding something out (What is a Learning OKR?). Labelling each OKR tells the team, and the teams that depend on it, how much of it they can count on.

OKRs are a planning and execution method. They do not choose the strategy for you, they are not a project plan, and they are not a performance review. Their natural neighbors are KPIs, which track the ongoing health of the business, and team-level practices such as check-ins and retrospectives, which keep the goals alive between planning and grading. Doerr pairs OKRs with what he calls CFRs: conversations, feedback and recognition, the ongoing dialogue that keeps goals from being set and forgotten (What Matters on OKRs and CFRs).

The method also has serious critics. Marty Cagan of SVPG, long an advocate, says he stopped recommending OKRs in most companies he meets: where teams are still feature teams working from a roadmap, he considers the technique a cultural mismatch and almost certainly a waste of time and effort. Jeff Gothelf argues in Harvard Business Review that OKRs work at the team level and fall short when applied to individual contributors. Both critiques point at the same thing: OKRs amplify an organization that already gives teams problems to solve, and add paperwork to one that does not. The pages below, and tools such as Hamster, which can hold a team's OKRs as shared context for people and agents, assume you want the first kind.

Core Principles

Separate the Objective from its Key Results

An Objective is qualitative and says what you want to achieve; its Key Results are quantitative and say how you will know. Google's playbook calls objectives the "Whats" and key results the "Hows" (Google's OKR playbook). Collapsing the two, by writing a metric as the objective or a vague aspiration as a key result, removes either the meaning or the measurement. Keep them distinct, and check that the key results together would prove the objective.

Write key results as outcomes

Key results describe what the work changes. re:Work's test is blunt: if a key result contains words such as "consult," "help," "analyze" or "participate," it is describing an activity (re:Work). An activity key result can be completed without changing anything for customers or the business. Write the change you expect to see, and keep the task list somewhere else.

Focus on a few objectives

OKRs cover the handful of priorities that matter most. Google often uses three to five objectives with about three key results each, and re:Work warns that more leads to over-extended teams and diffused effort (re:Work). What Matters suggests teams piloting OKRs start with an even smaller set (How to Roll Out OKRs). Business-as-usual work stays on the team's plate; it just does not need an OKR.

Label ambition: committed or aspirational

Every OKR should say whether it is a promise or a stretch. Google's playbook treats failing to make that distinction as the first classic trap, because a commitment marked as aspirational gets deprioritized and an aspiration marked as committed makes the team defensive (Google's OKR playbook). The label also tells dependent teams what to plan around. What Matters suggests simply marking each OKR with a "C" or an "A" (Committed vs. Aspirational OKRs).

Make OKRs public

Transparency is how OKRs create alignment without a chain of approvals. re:Work states that OKRs are public so everyone in the organization can see what others are working on (re:Work). Laszlo Bock, quoted by What Matters, describes Google's approach as market-based: the top OKRs are known, everyone else's are visible, and teams that are badly out of alignment stand out (Bottom-up OKRs). Private OKRs lose that benefit.

Keep OKRs out of compensation

Tie OKR scores to bonuses and people will set targets they know they can hit. Grove made the separation part of the method, and Doerr repeated it in a 2014 interview: do not tie OKRs to bonus payments, except for sales quotas (Betterworks interview with Doerr). Bock tells What Matters that early Google once tied product usage OKRs to pay and people started gaming the system (Why You Should Divorce Compensation From OKRs). What Matters recommends divorcing OKRs from the individual performance review and using them as one input into the performance conversation.

Check in during the cycle, grade at the end

OKRs set in the first week and read again in the last week do little. re:Work recommends a mid-quarter check-in before the final grade, and says some teams revisit their OKRs a few times a quarter to adjust to new information (re:Work). What Matters separates the two conversations: check-ins are about support and course correction, and grading is a judgment on the goal, not on the person (Weekly OKR check-ins). The grade then feeds the next cycle's planning.

OKRs Compared with Other Goal Systems

OKRs share parts with several older and neighboring systems. The differences decide which one fits a given problem.

Steps

1. Share the strategic context Before anyone drafts an OKR, leadership states what the company is trying to achieve this year and this quarter, and what it is choosing not to do. Doerr's typical OKR cycle has senior leaders start brainstorming company OKRs 4 to 6 weeks before the quarter and communicate them 2 weeks before it begins. Without that context, teams write good-looking OKRs that point in different directions. The output is a short statement of company OKRs or themes, plus explicit non-goals. Keep it short enough that every team lead can repeat it.

2. Draft a few qualitative objectives Each team lists its candidate priorities and narrows them to the few that would make the biggest difference this cycle. For each, it writes an objective that is significant, concrete, action-oriented and ideally inspirational, the four qualities What Matters names. Avoid maintenance language such as "keep" or "continue," which re:Work lists as a sign of a status-quo goal. Test each draft by asking whether achieving it would change the team's position. See Writing Effective OKR Objectives for the full technique.

3. Write measurable key results Under each objective, write about three key results, each with a baseline, a target and a date. Each one should describe an outcome and include evidence of completion that is available and credible, as Google's OKR playbook requires. Check that scoring 1.0 on every key result would in fact deliver the objective, which is the playbook's test for insufficient key results. Pair a quantity result with a quality result where pushing one could hurt the other. How to Write Key Results covers the patterns.

4. Label each OKR and calibrate ambition Mark every OKR as committed or aspirational before it is published. Committed OKRs should credibly consume most, but not all, of the team's capacity, and committed plus aspirational should credibly consume somewhat more than it has, according to Google's OKR playbook. If the whole set could be hit without the full team, the playbook calls that sandbagging. The label tells the team what failure means and tells other teams what they can depend on.

5. Align across teams Compare drafts across teams before committing. Each team's OKRs should connect to at least one company OKR, though not every company OKR needs to appear in every team's set (re:Work). Where a result needs several teams, the playbook asks that each contributing team carry an OKR for its part. Look for dependencies, conflicts and gaps, and settle them in one working session rather than a chain of approvals. OKR Alignment Across Teams describes the process.

6. Publish and check in regularly Publish the final OKRs where anyone in the organization can read them, with an owner and baseline for every key result. Then keep them in the team's regular rhythm: What Matters recommends weekly 1:1 conversations (CFRs) that ask about OKR progress and blockers, with formal OKR sessions on a quarterly rhythm (Weekly OKR check-ins). Treat an off-track key result as information and decide what to change. Add a fuller mid-cycle review, as re:Work suggests. OKR Check-In Meetings gives formats.

7. Grade, reflect, and feed the next cycle At the end of the cycle, grade each key result and average the grades to score the objective, with rough weighting where needed. Google grades from 0.0 to 1.0 and expects an average of 0.6 to 0.7 across its OKRs (re:Work); committed OKRs are expected to reach 1.0. Follow the numbers with a reflection on what helped, what got in the way and what the team would write differently. Carry unfinished aspirational OKRs forward instead of dropping them quietly. The OKR Scoring System covers grading in detail.

When to Use

• An organization has a strategy but its teams pull in different directions, and leaders cannot say in measurable terms what a good quarter looks like. OKRs turn the strategy into a few shared, visible targets.
• A company has grown past the point where everyone hears every priority in person. Public OKRs let teams see each other's goals and dependencies without adding a layer of coordination meetings.
• A product organization wants to move from shipping features to changing outcomes. Outcome key results make the difference between "launched it" and "it worked" visible every quarter.
• A team is attempting something it has never done and wants to aim high without being punished for falling short. Aspirational OKRs, scored against a partial-success norm, give it permission to stretch.
• Leadership is making a major shift in direction and needs every team to show how its work supports the new bet. Aligned OKRs make gaps in that support obvious early.

When Not to Use

• The company has not decided its strategy. OKRs help teams execute a direction; they do not choose one, and without a strategy they give a tidy structure to scattered effort.
• Leadership insists on tying OKR scores to pay or ratings. Google's own experience, reported by Laszlo Bock, is that people then game the targets, and the method's stretch disappears.
• Teams are feature teams handed a roadmap with dates. Cagan's view is that OKRs are a cultural mismatch in that setting until teams are given problems to solve.
• The team is very small and already talks about priorities every day. The planning, alignment and grading overhead may cost more than the coordination it buys.