OKRs (Objectives and Key Results)

Definition: A goal-setting framework pairing a qualitative Objective (what you want to achieve) with a small set of quantitative Key Results (how you’ll know you achieved it).

How It Works

The Objective is ambitious and inspirational, and it’s often deliberately not 100% achievable
Key Results are specific, measurable, and time-bound, usually 2-4 per objective
Initiatives sit below Key Results: the actual projects and tasks a team runs to try to move each Key Result
Scored on a 0-1.0 scale at the end of a cycle. A score around 0.7 is often considered healthy; hitting 1.0 every time can mean the goals weren’t ambitious enough
Set at multiple levels (company, team, individual) and usually cascade, so team OKRs visibly support company OKRs
Reviewed and re-set on a fixed cadence, commonly quarterly, with a check-in partway through the cycle
Kept deliberately public within the organization in many companies, so anyone can see what any team is working toward and why
Separated from compensation and performance review in the healthiest implementations, since mixing the two encourages sandbagging
Distinguished from “committed” goals (must-hit, usually operational) versus “aspirational” goals (stretch, expected to land around 0.7), a distinction Google itself draws explicitly
Meant to be few in number: most practitioners recommend capping company-level Objectives at 3-5 per quarter, not a dozen
Written top-down and bottom-up together in most mature implementations: leadership sets direction, teams propose how they’ll actually contribute to it
Grading happens through self-assessment in many companies, with each Key Result owner scoring their own progress and explaining the gap, rather than a manager assigning the score
Retrospectives at the end of each cycle ask not just what score was hit, but why, so the next cycle’s targets are set with better information

Under the Hood

The tree only works if Key Results are outcomes, not initiatives themselves. “Ship guided tour” belongs at the initiative layer; the Key Result above it has to be the number that tour is supposed to move.

Worked example: scoring a Key Result

Given, end-of-quarter results for the Objective above:

KR1 target: raise Day-1 activation from 45% to 65% (a 20-point goal)
Actual result achieved: 58%

Step, KR score as the fraction of the target range actually covered:

KR1 score = (achieved - baseline) / (target - baseline)
KR1 score = (58 - 45) / (65 - 45)
KR1 score = 13 / 20 = 0.65

Step, assume KR2 scored 0.80 and KR3 scored 0.55. The Objective score is the average of its Key Results:

Objective score = (0.65 + 0.80 + 0.55) / 3 = 2.00 / 3 = 0.67

Answer: 0.67 lands in the “healthy” range most OKR practitioners target (roughly 0.6-0.7), meaning the goal was ambitious but real progress was made, not sandbagged and not wildly missed.

Worked example: spotting a sandbagged target

Given a second team sets KR: “increase weekly retention from 60% to 62%,” a 2-point goal, and hits 61.8%.

KR score = (61.8 - 60) / (62 - 60) = 1.8 / 2 = 0.9

Answer: a 0.9 score with only a 2-point target range is a signal worth questioning. It might mean the team executed exceptionally, or it might mean the target was set too close to the expected baseline trend to be a real stretch. Comparing target size against typical quarter-over-quarter movement for that metric is how experienced OKR reviewers catch this pattern.

Scoring scale, in practice:

Score	Interpretation
1.0	Fully hit, worth checking if the target was ambitious enough
0.7	Healthy target zone, real stretch with real progress
0.4	Meaningful progress, but the approach likely needs to change
0.0-0.3	Little to no progress, worth a deeper root-cause review

Why It Matters

Connects day-to-day work to larger company goals explicitly, instead of teams independently deciding what “success” means for themselves
Makes trade-offs visible: if a project doesn’t ladder up to any Key Result, it’s easier to question why it’s on the roadmap at all
Creates a shared, quarterly rhythm for setting and reviewing priorities across otherwise-independent teams
Surfaces misalignment early, at the mid-cycle check-in, instead of only at the end of the quarter when it’s too late to redirect effort
Gives teams permission to say no to work that doesn’t ladder up to a Key Result, instead of every ask automatically becoming a commitment
Creates a searchable record, over multiple quarters, of what the company actually prioritized and how well those bets paid off
Makes it easier to justify saying no to a stakeholder request that doesn’t map to any current Key Result, without the conversation becoming personal
Gives cross-functional teams a shared vocabulary for what “done” and “successful” actually mean for a given quarter

Common Pitfalls

Writing Key Results that are really just a list of tasks (“ship feature X”) instead of measurable outcomes (“increase activation rate to 65%”)
Treating OKRs as a performance review scorecard, which pushes people to set safe, easily achievable targets instead of ambitious ones
Setting too many objectives at once, which spreads focus so thin that none of them get the attention they need
Sandbagging targets deliberately so the end-of-quarter score looks good, defeating the entire point of the framework
Setting OKRs once a quarter and never checking in again until the deadline, so misalignment isn’t caught until it’s too late to fix
Copying company-level OKRs verbatim down to every team, instead of each team defining how it specifically contributes
Letting Initiatives quietly replace Key Results in team conversations, so “did we ship it” replaces “did it move the number”
Setting a Key Result the team has no real influence over (like overall company revenue for a single infrastructure team), which demotivates rather than focuses
Never revisiting a Key Result mid-quarter even when the underlying assumption behind it has clearly changed
Rolling every Objective down to every team unchanged, instead of letting each team define its own honest contribution to the shared goal
Grading Key Results based on effort expended rather than the actual number reached, which quietly turns outcomes back into a task checklist

Comparison

	OKRs	KPIs	SMART Goals
Structure	Objective plus a few measurable Key Results	A single tracked metric with a target	Specific, Measurable, Achievable, Relevant, Time-bound statement
Ambition	Deliberately stretch, not fully achievable	Usually set to be hit, not stretched	Achievable by design
Cadence	Typically quarterly	Ongoing, continuously monitored	Varies, often annual or project-based
Best for	Aligning teams around strategic priorities	Monitoring the health of an ongoing process	Individual or project-level goal-setting
Tied to compensation	Should not be, in most implementations	Frequently, especially sales	Sometimes, in performance reviews
Failure mode	Sandbagged targets, task lists disguised as outcomes	Chasing the number instead of the underlying value	Goals so safe they stop being motivating
Number tracked	2-4 Key Results per objective	Usually one, tracked continuously	Varies, one goal per statement
Scope	Strategic, often company-wide	Operational, function-specific	Usually individual or team-level

OKRs and KPIs aren’t competitors, most mature companies run both. KPIs monitor whether the business is running normally; OKRs describe what the company is deliberately trying to change this quarter, often by moving a KPI outside its normal range.

Example

Andy Grove developed the OKR framework at Intel in the 1970s, describing it in his book High Output Management. Investor John Doerr, who learned the system at Intel while working there, introduced it to Google in 1999 when the company had fewer than 40 employees, presenting it directly to founders Larry Page and Sergey Brin.

Google has publicly credited company-wide OKRs, reviewed quarterly at all-hands meetings, as part of its scaling discipline through years of hypergrowth. Doerr later documented the practice in detail in his book Measure What Matters, which includes Google’s own internal OKR grading examples and interviews with Google leadership about how the framework was adapted as the company scaled from dozens to well over 100,000 employees.

North Star Metric — often becomes a Key Result at the company-level Objective
A/B Testing — a common initiative-level tool for actually moving a Key Result
Prioritization Frameworks — used to decide which initiatives get funded under each Key Result
Product Roadmap — the execution plan that should trace back to specific Key Results

Dig deeper

Spot an error in this note?