OKR
OKR — Objectives and Key Results — is one qualitative goal paired with a few measurable outcomes that prove it happened. OKRs are a goal-setting and alignment tool — the moment they become a task list or a performance rating, they stop working and usually get blamed for it. This page covers outcomes versus outputs, committed versus aspirational goals, the cadence, scoring and the difference from KPIs.
- Origin
- Intel → Google
- Per objective
- 2–5 key results
- Cycle
- Quarterly
The two halves
An Objective is a short, qualitative statement of where you are trying to get to. It should be memorable and slightly uncomfortable — something a team could repeat from memory and would be proud to achieve. No numbers belong in it; the numbers are the other half's job.
Key Results are the two to five measurements that would convince a sceptic the objective was actually met. Each needs a number and a deadline. If you can achieve every key result and still have failed the objective, the key results are wrong — and that test, run out loud before the quarter starts, catches most bad OKRs in about a minute.
The mechanism is not new. Andy Grove built it at Intel out of management by objectives, adding the insistence that goals be paired with measures and reviewed on a short cycle. John Doerr took it to Google in 1999 and compressed the whole thing into one sentence worth memorising: "I will [objective] as measured by [key results]." If a draft OKR does not fit that sentence, something is wrong with it.
Key results are outcomes, not outputs
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.
Outcome (a real key result)
- Cut median checkout time from 90s to 45s
- Raise week-4 retention from 22% to 30%
- Reduce support tickets about billing by half
- Lift change failure rate from 15% to under 5%
Output (a disguised task list)
- Redesign the checkout page
- Ship the onboarding tutorial
- Rewrite the billing FAQ
- Migrate to the new CI pipeline
Notice that the right-hand column can be fully delivered while the business gets nothing. That is not a hypothetical — it is the normal result of measuring output, because a team that is graded on shipping will ship, whether or not it helps.
The redesign in the right-hand column is not forbidden — it is simply an initiative, the work you believe will move a key result. Initiatives belong in the backlog; key results belong in the OKR. Keeping the two apart is what makes it possible to abandon a redesign halfway through without abandoning the goal, which is the entire practical benefit of the framework.
Guardrail metrics
Any single number can be moved in a way nobody wanted. Halve the support tickets about billing by hiding the contact link; raise sign-ups by making cancellation hard. The standard defence is a guardrail: a metric you commit not to worsen, published alongside the key results. "Raise sign-ups from 4% to 6% with refund rate staying under 2%" is a goal that cannot be won by cheating, and it costs one extra line to write.
Committed and aspirational OKRs
The advice to "aim for 70%" is repeated so often that it gets applied to goals where it is actively wrong. Google's own guidance 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.
Committed
- The organisation agrees these will be achieved
- Expected score: 1.0
- Missing one triggers a post-mortem, not a shrug
- Resources and schedules are adjusted to hit them
Aspirational
- A stretch: how the world would look if it went well
- Expected score: around 0.7
- Consistent 1.0 means the ambition was too low
- Often survives several quarters before landing
Label each OKR as one or the other when you set it, not when you score it. A compliance deadline, a contractual delivery and a security remediation are committed by nature — telling that team 70% is fine is nonsense. A tenfold improvement in activation is aspirational by nature, and demanding 1.0 on it guarantees the next quarter's goals will be timid.
Alignment is not cascading
The intuitive way to scale OKRs is to cascade them: the CEO sets objectives, each VP takes one as their objective, each director takes one of theirs, down to the team. It is tidy, it is what most organisations try first, and Google's own guidance argues against it.
The reason is practical rather than philosophical. 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 contribute the one it can actually see.
The guidance that comes out of Google's experience is a rough split: around half of OKRs should originate from the teams rather than being handed down. Leadership sets the direction; teams propose the key results they believe will move it, and the two are reconciled in a conversation rather than a hierarchy. The reconciliation is real work — it is where a team says "that key result is not ours to move, but this one is" and the direction gets sharper.
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 all OKRs openly is what makes that work — alignment here comes from everyone being able to read everyone else's goals, not from the tree structure.
The cycle that makes it work
OKRs set in January and opened in March are a filing exercise. The framework only pays off if the cycle is run, and the cycle has four moments — none of which take long, and the middle one is the one that gets dropped.
| Moment | When | What actually happens |
|---|---|---|
| Setting | Before the quarter | Direction from leadership, key results proposed by teams, both reconciled and published openly. |
| Check-in | Weekly or fortnightly | Fifteen minutes: current value of each key result, confidence, and what changes as a result. |
| Mid-cycle review | Around week 6 | The one chance to drop or rewrite an OKR the quarter has proven wrong, while there is still time to act. |
| Scoring and reflection | End of the quarter | Score, then ask what was learned and what it implies for the next set. The reflection is the valuable half. |
Doerr pairs the whole cycle with a companion practice he abbreviates CFR: conversations, feedback and recognition. The point is that OKRs handle the goals and nothing else — the continuous one-to-one conversation about how someone is doing, the feedback between peers, and public recognition of good work are what a performance system needs, and they are deliberately kept separate from the scores.
Scoring, and the line to compensation
OKRs are scored 0 to 1, usually as the average of the key result scores. For aspirational OKRs the healthy landing zone is around 0.6 to 0.7. Consistently scoring 1.0 on aspirational goals does not mean the team is excellent — it means the goals were set where success was already known.
| Score | Reads as | What to do next |
|---|---|---|
| 0.0–0.3 | Real failure or a wrong bet | Ask what was learned; do not punish |
| 0.4–0.6 | Genuine progress on a hard goal | Usually worth continuing |
| 0.7 | The intended landing zone for a stretch | Keep the ambition level |
| 1.0 every quarter | The goals were too safe | Raise the ambition |
This only holds 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. This is not a cultural nicety: it is the incentive arithmetic, and it works the same way in every organisation that has tried it.
OKR is not KPI
The two get merged constantly, usually by putting the existing dashboard into an OKR template. They answer different questions and both are needed.
| Aspect | OKR | KPI |
|---|---|---|
| Question | What should change this quarter? | Is the business healthy right now? |
| Lifetime | One cycle, then replaced | Ongoing, tracked for years |
| Ambition | A deliberate stretch | A threshold that should hold |
| Coverage | The few things being changed | Everything that must not break |
The practical link is that a KPI drifting the wrong way is often the reason a new OKR is set, and a KPI that must not move is often the guardrail attached to one. Turning the whole KPI dashboard into OKRs, on the other hand, produces twenty objectives, no focus, and a quarter in which nothing was chosen.
How this shows up in real delivery
A working OKR changes what a team says no to. If the quarter's key result is week-4 retention and a stakeholder asks for a feature that plainly will not move it, the OKR gives the team language for declining that is about the goal rather than about capacity. An OKR that has never caused anyone to decline anything is decoration.
Where it degrades
- Key results that are a roadmap in disguise — every one is a thing to ship by a date.
- 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.
- Set in January, opened in March — no mid-quarter check-in means no course correction.
- A single number with no guardrail, which invites the cheapest way of moving it.
- The existing KPI dashboard copied into OKR format, which chooses nothing.
When to use it
Use it when
- Teams need to align on outcomes without being told exactly what to build.
- You can actually measure the outcomes you care about.
- Leadership will let teams propose roughly half the goals.
- Scores can be kept entirely separate from compensation.
- Someone will run the check-ins — the cycle is the framework, not the document.
Avoid it when
- The organisation intends to use scores in performance reviews.
- The work is a predictable delivery schedule — use a plan, not a goal framework.
- No usable metrics exist yet — build the measurement before the goals.
- Leadership wants OKRs as a reporting layer over work that is already decided.
Found this useful?
Share it with someone who is working on the same problem.