What it is
OKR stands for Objectives and Key Results — a goal-setting structure with two parts. The Objective is a single qualitative, ambitious statement of what you want to achieve in a quarter or year ("Make our onboarding the fastest in the category"). The Key Results — usually 3–5 per objective — are the measurable outcomes that, if achieved, would prove the objective was met ("Median time-to-first-value under 4 minutes," "Day-1 activation rate above 60%").
The method was developed by Andy Grove at Intel in the 1970s (he called it "iMBOs"), and was carried into Google in 1999 by John Doerr, who had learned it directly from Grove. Doerr later popularized it widely in his book Measure What Matters.
When to use it
OKRs work best when you have multiple teams and need to align them on a small number of outcomes without micromanaging the path. Reach for them when:
- Setting quarterly or annual company goals across more than one team
- Replacing a long list of KPIs that have lost meaning through proliferation
- Driving a step-change in a metric, not just maintenance work
- Aligning a newly merged or restructured org around a shared scoreboard
- Making it visible across the company who is working on what
They're overkill for solo founders, very small teams, or work where the outputs are mostly maintenance and unpredictable inbound.
How to run it
- Draft the company-level Objective first — one sentence, qualitative, inspiring, and uncomfortable to commit to.
- Define 3–5 Key Results per Objective. Each must be a number with a starting value, a target value, and a deadline. "Improve NPS" isn't a KR; "Increase NPS from 32 to 45 by end of Q3" is.
- Cascade thoughtfully. Team OKRs should support the company OKRs, not mechanically restate them. Some teams may have OKRs that only touch one of the company's.
- Get explicit commitment from each owner. If the owner doesn't believe the target is achievable with current resources, fix the OKR before the quarter starts, not after it ends.
- Check in weekly or biweekly — score progress on each KR (often a 0.0–1.0 scale) and flag at-risk items early.
- Score at the end of the period. Discuss what was learned, not who is to blame.
- Reset for the next cycle. Don't roll incomplete OKRs forward unchanged — re-decide whether they still matter.
Common pitfalls
The most common pitfall is scoring 1.0 on every Key Result. If everything hits, the targets weren't ambitious — they were sandbagged. The Intel/Google convention is to aim for roughly 0.7: ambitious enough that 100% is genuinely hard, soft enough that 0.7 is a real win, not a failure. If your team keeps scoring 1.0, raise the targets next quarter.
Second pitfall: confusing Key Results with tasks. "Ship the new onboarding flow" is a task — it's binary, and it doesn't prove the objective worked. "Lift day-1 activation from 38% to 55%" is a Key Result. KRs measure outcomes; tasks live in the project tracker beneath them.
Third: setting too many. Three Objectives with three KRs each is the upper bound for most teams. If you have eight Objectives, you have none.
Fourth: tying OKRs to compensation. Google explicitly doesn't — the moment KRs determine bonuses, people start sandbagging targets, which destroys the entire point.
Variations
A common cousin is the V2MOM (Vision, Values, Methods, Obstacles, Measures), developed at Salesforce by Marc Benioff. V2MOM adds explicit Values and Obstacles, which can be useful in larger, more culturally driven companies. MBOs (Management by Objectives), Peter Drucker's earlier framework, are OKR's direct ancestor — more top-down and tied to individual performance reviews, which is exactly the part Grove tried to fix when he developed iMBOs at Intel.