OKR

One team’s OKRs for a quarter, finished

Most people who look up OKRs want to see a good set. Here is one, for the customer team of the online shop from the WBSWBSWork Breakdown Structure — the project’s scope as a treeA tree of everything a project will deliver, broken down until each piece is small enough to estimate and give to one owner — and, by definition, nothing the project will not deliver. Its children must add up to exactly their parent, which is what makes it a scope boundary rather than a task list.Full article →All terms and epicsepica large backlog itemA large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.Full article →All terms pages, for one quarter. Each objective is labelled committed or aspirational when it is written. Each key result has a starting value and a target. The guardrails and the initiatives are written next to them, and are not scored. Later sections cite the lines by number.

1. 1.Objective 1 — Buying again feels effortless (aspirational)

   1. 1.1Week-2 return visits from 18% to 25%
   2. 1.2Median time from sign-in to a paid repeat order from 4 min 10 s to under 1 minute
   3. 1.3Share of orders placed by returning customers from 41% to 50%

2. 2.Objective 2 — Paying never lets a customer down (committed)

   1. 2.1Payment success rate at or above 97.5% in every week of the quarter — now 96.8%
   2. 2.2Customers charged without an order: zero a week, from 11 a week now
   3. 2.3PCI DSS self-assessment signed off by 15 August

3. 3.Guardrails — must not get worse; not scored

   1. 3.1Refund rate stays under 2%
   2. 3.2Unsubscribes from reminder emails stay under 0.5% per send
   3. 3.3Support contacts stay at or below 6 per 100 orders

4. 4.Initiatives — the work we believe will move them; in the backlog, not in the OKR

   1. 4.1Reorder from order history — the epic on the epics page
   2. 4.2Saved baskets
   3. 4.3Reorder reminder emails
   4. 4.4Automatic retry and refund for payment-provider timeouts

What Grove, Doerr and Google actually wrote

The method has a short, documented lineage. Peter Drucker described management by objectives in 1954: managers and the people who report to them agree goals, and work is judged against them. Andy Grove rebuilt it at Intel in the 1970s and insisted on the second half — every objective paired with measurable key results, reviewed every quarter. He described it in a few pages of “High Output Management” (1983). His test for a key result, as John Doerr quotes it: “The key result has to be measurable. But at the end you can look, and without any arguments: Did I do that or did I not do it?”

Doerr learned the method as a young engineer at Intel in 1975. In 1999 he presented it to the founders of Google, then a company of a few dozen people, and in 2018 he wrote it up in “Measure What Matters”, with a one-sentence template worth keeping: “I will [objective] as measured by [this set of key results].” If a draft does not fit that sentence, something is wrong with it.

Intel’s own OKR, second quarter of 1980

Doerr reproduces one of Intel’s corporate OKRs, from the campaign against Motorola described in the cases below. The objective: “Establish the 8086 as the highest-performance 16-bit microprocessor family, as measured by” — and then four key results, each with the score it got at the end of the quarter.

Three things are worth noticing. The average is 0.625, and the quarter is remembered as a success. One key result scored zero, and the method survived it — a zero was information, not a verdict. And all four key results are deliverables: publish, repackage, get into production, sample. By the rule the next section argues for, every one of them is an output.

What Google added

Google’s published guidance, on its re:Work site, sets the working range: “pick just three to five objectives”, about three key results each, an average score of 0.6 to 0.7, OKRs public to everyone, and the sentence that matters most — “OKRs are not synonymous with employee evaluations”. Google’s internal playbook, published by Doerr’s team, adds the split the earlier page version got only half right: committed OKRs are ones “we agree will be achieved”, scored against 1.0; aspirational OKRs “express how we’d like the world to look”, scored against an average of 0.7.

Key results measure outcomes — and carry a guardrail

This is the failure that quietly kills most OKR programmes. An output is something you did; an outcome is something that changed because you did it. Outputs are entirely within your control, which is exactly why they make comfortable and worthless key results. A team graded on shipping will ship, whether or not it helps.

The redesign in the right-hand column is not forbidden. It is an initiative — the work you believe will move a key result — and initiatives belong in the backlog, as group 4 is kept apart in the set above. Keeping the two apart is what lets a team abandon an initiative halfway through without abandoning the goal. If reminder emails (4.3) do nothing for return visits after three weeks, the team stops sending them, and key result 1.1 is untouched.

Twelve key results as teams write them

Guardrails, and why group 3 exists

Any single number can be moved in a way nobody wanted. Halve billing tickets by hiding the contact link; raise sign-ups by making cancellation hard. The defence is a guardrail: a metric you commit not to worsen, published beside the key results and chosen as the thing that would break if the key result were gamed. Group 3 is exactly that. Reminder emails could raise return visits by annoying people, so unsubscribes are capped at 0.5% a send; faster reorders could raise refunds, so refunds stay under 2%.

Committed or aspirational — and how a score is computed

The advice to “aim for 70%” is repeated so often that it gets applied where it is wrong. Google splits OKRs into two kinds with different rules, and mixing them is a reliable way to get an argument at the end of the quarter.

Label each OKR when you set it, not when you score it. A compliance deadline, a contractual delivery and a security fix are committed by nature: telling that team 70% is fine is nonsense. That is why objective 2 in the set above is committed, and why its key results may be thresholds and dates rather than stretches. A tenfold improvement in activation is aspirational by nature, and demanding 1.0 on it guarantees timid goals next quarter.

Computing a score

A key result is scored by where it landed between its starting value and its target: the distance travelled divided by the distance planned. Key result 1.1 started at 18%, aimed at 25% and ended the quarter at 22.9%: 4.9 points of 7 is 0.7. Key result 1.2 runs the other way — from 250 seconds down to 60 — and ended at 1 minute 57 seconds: 133 seconds saved of 190 planned, also 0.7. An objective’s score is usually the average of its key results.

A committed key result is read differently. Line 2.1 asks for 97.5% in every week; twelve good weeks out of thirteen is not 0.92, it is a missed commitment that needs an explanation. That is why a committed objective needs enough key results to define it completely — the sixth trap below — and why committed key results are often pass-or-fail.

Google’s six classic traps

Google’s playbook names six ways OKRs are written badly. Each is easy to recognise once it has a name, and every one of them appears in the twelve rows above.

Alignment, and the quarter week by week

Alignment is not a cascade

The intuitive way to scale OKRs is to cascade them: the chief executive sets objectives, each vice-president takes one as their own, each director takes one of theirs, down to the team. It is tidy, it is what most organisations try first, and Grove’s own principles pull the other way. Doerr lists one of them plainly: roughly half of a team’s OKRs should originate with the people doing the work.

The reason is practical. Cascading takes as long as the org chart is deep, so by the time the quarter’s goals reach the team, the quarter has started. It also throws away the knowledge of the people closest to the work: a team told exactly which key result to own cannot offer the one it can actually see. Leadership sets direction; teams propose key results they believe will move it; the two are reconciled in a conversation, which is where a team says “that one is not ours to move, but this one is”.

One consequence surprises people: a team’s OKR does not have to be a subdivision of its manager’s. Two teams may share one key result outright, and a team may own a key result that belongs to another department’s objective. Publishing every OKR openly is what makes that work — alignment comes from everyone being able to read everyone else’s goals, not from the shape of a tree.

The cycle that makes it work

OKRs set in January and opened in March are a filing exercise. The framework pays off only if the cycle is run, and the cycle has four moments. None takes long, and the middle one is the one that gets dropped.

Christina Wodtke’s “Radical Focus” (2016) gave the weekly check-in its most copied shape: a page in four squares — this week’s priorities, a confidence score out of ten for each key result, the big pieces of work coming in the next few weeks, and the health metrics that must not slip. Commitments are made on Monday and wins are shown on Friday. The confidence number is the useful part: it falls before the key result does, which is exactly when there is still time to act.

The chart is line 1.3 from the set above. In week 4 the marketing team launched a first-order discount, and new customers’ orders doubled. Returning customers kept ordering more, but their share of all orders fell, and the team’s confidence on 1.3 dropped to two. At the mid-quarter review the team rewrote it as orders per returning customer per month, from 1.2 to 1.4 — a number only returning customers move — and told marketing why. The first version was not the team failing. It was a ratio whose denominator belonged to someone else, and the review exists to catch exactly that while there is time to act.

Doerr pairs the whole cycle with a practice he calls CFRs: conversations, feedback and recognition. OKRs handle the goals and nothing else. The continuous one-to-one conversation about how someone is doing, the feedback between colleagues and public recognition of good work are what a performance system needs, and they are deliberately kept apart from the scores.

OKR beside KPI, and the line to pay

The two get merged constantly, usually by pasting the existing dashboard into an OKR template. They answer different questions and both are needed.

The practical link runs both ways. A KPI drifting the wrong way is often the reason a new OKR is set — payment success sliding to 96.8% is why objective 2 exists. And a KPI that must not move is often the guardrail beside one, as refunds and support contacts are in group 3. Turning the whole KPI dashboard into OKRs, on the other hand, produces twenty objectives, no focus, and a quarter in which nothing was chosen.

The line to compensation

Everything above holds only if scores carry no consequence for pay or promotion. The moment an OKR score feeds a performance review, every rational person sets goals they know they can hit, and the organisation loses the one thing the framework was for. That is not a cultural nicety. It is incentive arithmetic, and Google states it in one line: OKRs are not synonymous with employee evaluations.

The research behind goal-setting cuts both ways, and both halves matter. Edwin Locke and Gary Latham summarised thirty-five years of studies in 2002: specific, difficult goals consistently produce better performance than being told to “do your best”. That is the case for aspirational OKRs. In 2009 Lisa Ordóñez, Maurice Schweitzer, Adam Galinsky and Max Bazerman answered with “Goals Gone Wild”, arguing that goal-setting is prescribed like a harmless supplement when it has systematic side effects. Locke and Latham replied that the side effects come from misuse. Read the OKR rules as the dosage instructions both sides were arguing about.

Four cases, and the rule each one shows

Two of these are the method’s own origin stories. The other two were not OKR programmes at all. They are here because they show, at full scale, the mechanism two of the method’s rules exist to block: a number tied to pay, with nothing beside it.

Operation Crush began at the end of 1979, when Intel concluded it was losing the 16-bit market to Motorola’s 68000, which many engineers thought the better chip. Rather than redesign the product, Intel changed what it sold: development tools, support, a roadmap and a promise of future generations. The yearly target was 2,000 design wins — commitments by customers to build the 8086 family into their own products — and the quarterly OKRs, like the one reproduced above, were the steps chosen to reach it. Intel’s own history page counts almost 2,500 design wins. One of them was a small IBM team building a personal computer; the IBM PC, launched on 12 August 1981 with the 8088, made the architecture the industry’s default for the next forty years. The quarter’s scores were mixed. The yearly outcome above them is what the campaign was judged by.

Wells Fargo is the guardrail case. Its retail bank pursued cross-selling under a target of eight products per household — “eight is great”, as the chief executive put it — with daily sales goals for branch staff and incentive pay attached. On 8 September 2016 the Consumer Financial Protection Bureau, the Office of the Comptroller of the Currency and the City of Los Angeles fined the bank $185 million over about 1.5 million deposit accounts and 565,000 credit-card applications that may not have been authorised; the bank had fired about 5,300 employees. Product sales goals for retail staff were abolished from January 2017; the board’s own investigation, published that April, blamed the sales culture; a review that August raised the count of possibly unauthorised accounts to 3.5 million; and in February 2020 the bank agreed to pay $3 billion to the Department of Justice and the Securities and Exchange Commission. Every number the bank watched went up. Nothing beside it measured whether the customer had asked.

Where it degrades

An OKR programme rarely fails on the day the goals are set. It fails at the end of the quarter, when the scores are read and nothing about the next quarter changes. Almost every such failure is one of these:

• Key results that are a roadmap in disguise — every one a thing to ship by a date, with no outcome above them.
• Key results with no starting value, which can only be scored by argument.
• Scores tied to bonuses, which guarantees safe goals within one cycle.
• Ten objectives per team, which is a backlog with a new name and no focus.
• Every OKR treated as a stretch, so committed deadlines quietly become optional.
• Every OKR treated as committed, so the set describes the plan the team already had.
• Set in January, opened in March — no weekly check-in, no mid-quarter review, no correction.
• A single number with no guardrail, which invites the cheapest way of moving it.
• Objectives cascaded down the org chart, so the quarter has started before the team’s goals arrive.
• The existing KPI dashboard copied into OKR format, which chooses nothing.

The honest limit is that OKRs can force a choice and make it visible; they cannot make it right. A team with a perfectly written set — outcomes with starting values, guardrails, every objective labelled — can still pick the wrong objective, and the method will report a good score on it. The objective is a judgement about what matters, and no format checks a judgement. What the method does guarantee, if the cycle is run, is that a wrong key result is noticed in weeks rather than at the end of the year — as line 1.3 was.

The practical check takes an hour. Read each key result and ask whether it has a starting value; whether all of them could be met and the objective still missed; and whether any of them is something the team would ship anyway. Find the guardrail for each. Check the label on each objective. Then find out whether any score is read in a pay review — if one is, fix that first, because nothing else on this page survives it.

When to use it

Related pages

• ManagementEpics, Features, TasksEpics, features and tasks are the levels of a work hierarchy, from a bet a leader makes for a quarter down to a step an engineer takes today. No standard defines them: the Scrum Guide uses none of the three words, and Jira, Azure DevOps and SAFe each put the epic at a different size. The page opens with every level on one screen and one epic taken down to tasks, then covers where the words come from, what each level is for, writing an epic as a bet with an exit, features, enablers and tasks, why rolled-up estimates mislead, five episodes from the hierarchy’s history, and where it degrades.
• ManagementMetrics & KPIA metric is a number with a written definition that a team steers by, and a KPI is one of the few metrics a team or a company has agreed to be judged on. The craft is building a chain from something the team can move this week to something the business needs this year, keeping every number honest under pressure, and reading it without fooling yourself. The page opens with one team’s finished set of metrics, then covers the words and the chain, writing a definition, Goodhart’s law and guardrails, one number at the top and the tree beneath it, reading a number, four numbers that misled their owners, and where it degrades.
• ManagementAgileAgile is a set of four values and twelve principles for building software, written in 2001, that puts learning from working software ahead of the plan. It is not a methodology — Scrum, Kanban and Extreme Programming are the methodologies built on top of it — and it has no meetings, roles or artefacts of its own. The page opens with the Manifesto in full, numbered so a line can be cited, then covers the layer it occupies, what each value trades, the bet it makes on the cost of change, feedback loops as its real mechanism, each principle as a test you can run on your own team, six programmes it decided, and where it degrades into theatre.