OKRs — Objectives and Key Results

---

Origins

OKRs were developed by Andy Grove at Intel in the 1970s and popularized at Google by John Doerr beginning in 1999.¹ Doerr's Measure What Matters (2018) captured the practice as it had matured across Silicon Valley over two decades. The framework is now used by tens of thousands of organizations worldwide — with widely varying success.

The Anatomy

An OKR has two parts:

• Objective: a qualitative, ambitious description of what the team wants to accomplish. Memorable, motivating, narratively complete. "Become the default reporting tool for marketing teams."
• Key Results: three to five quantitative measures that, if all achieved, would mean the objective was reached. Specific, time-bounded, observable. "Reach 5,000 weekly active users; achieve 40% week-2 retention; close 20 paying teams."

The objective is the story; the key results are the evidence. The pairing is what distinguishes OKRs from KPIs — the qualitative ambition prevents the quantitative measures from drifting into meaningless precision.

The Doctrine

Classical OKR practice carries several principles:

• Quarterly cadence. Set at the start of a quarter, scored at the end. Long enough to make meaningful progress; short enough to adapt.
• Stretch goals. Hitting 70% of an OKR is considered success. If teams routinely hit 100%, the OKRs were too modest.
• Public visibility. Every team's OKRs are visible to the whole organization. Alignment emerges from transparency.
• Cascading carefully. Team OKRs support company OKRs, but they aren't strict subdivisions. Teams have local autonomy in how their OKRs serve the larger ones.
• Separated from compensation. OKRs are goals; performance reviews are separate. Tying compensation to OKR achievement kills the stretch goal.

Why OKRs Often Fail

OKRs have one of the worst implementation track records of any management practice. The dysfunctions:

• OKRs as performance reviews. Tying them to compensation forces sandbagging. Teams set easy OKRs to ensure they hit them.
• Output, not outcome. Key results that count features shipped instead of business or customer signals shifted. The team works hard and nothing improves.
• Too many OKRs. Eight OKRs per team produces eight half-attempted initiatives. The framework is most powerful when limited to two or three objectives per team.
• Cascading as decomposition. Treating team OKRs as a subset of company OKRs robs teams of judgment. The cascade should be alignment, not pre-allocation.
• Quarterly theatre. Set, forget for ten weeks, scramble in week eleven, score in week twelve. The cycle is performance; the work happens elsewhere.
• Output disguised as outcome. "Ship feature X by Q3" is a project plan, not a key result. KRs should describe the outcome the feature is meant to produce.

The Hidden Skill

Most of the difficulty in OKRs lies in writing good key results. A useful test:

• Could the team achieve the KR by doing something stupid? If yes, the KR is gameable. Reformulate.
• Does the KR describe an outcome or an output? "Launch the redesign" is output. "Reduce checkout drop-off by 15%" is outcome.
• Is the KR observable without ambiguity? "Improve customer satisfaction" is vague; "lift CSAT from 4.1 to 4.4" is observable.

Teams that learn to write good KRs find OKRs transformative. Teams that don't write OKRs as proxy for project plans and wonder why nothing improves.

When OKRs Work

• The organization has genuine alignment problems and needs a transparent framework to surface them.
• Leadership commits to keeping OKRs separate from performance reviews.
• The team has the autonomy to choose the work that serves their OKRs.
• Outcomes are measurable within a quarterly horizon (in some domains, this is itself a stretch).

When OKRs Fail Predictably

• Compensation is tied to achievement.
• The team has no real autonomy over how they meet their goals.
• The work being done is fundamentally maintenance or compliance, not outcome-driven.
• Leadership wants OKRs to be both stretch goals and committed deliveries — which they cannot simultaneously be.

Coaching Tips

Test KRs for gaming.

"Could a team hit this KR by doing something nobody would want?" If yes, rewrite.

Decouple from compensation.

Single most leveraged change. Leaders who insist on linking OKRs to comp will kill the stretch goal.

Limit to three Objectives.

More objectives means no priorities. The discipline of choosing what to leave out is the design.

Review OKRs every two weeks.

Quarterly check-ins are insufficient. A short mid-quarter review prevents week-eleven panic.

Distinguish committed vs. aspirational.

Some KRs are commitments; others are stretches. Mark which is which — they should be coached differently.

Watch for "ship X" KRs.

Output-shaped KRs are the most common failure mode. Reword every one as an outcome: what does shipping X improve?

Summary

OKRs are simple in concept and brutally hard in practice. The framework works when used as a goal-setting and alignment tool that lives separately from performance management. It fails when used as a performance review in disguise, when KRs slide into output-counting, or when teams produce too many OKRs to genuinely focus on any. The teams that succeed with OKRs do so by treating them as a tool for honest ambition — not as a way to formalize the work they were going to do anyway.

Back to Agile Metrics