Objectives and key results are a goal-setting framework: a qualitative objective describing what you want to achieve, and three to five quantitative key results that prove whether you did.
They work well in some organisations and collapse in most. The collapse is usually caused by the same handful of mistakes.
The structural rule
An objective is directional and memorable. A key result is a number that changes.
The test that catches most bad OKRs: a key result must be something you could fail at while completing all the work. “Ship the new onboarding flow” is a task — you either did it or you did not, and doing it proves nothing. “Increase trial activation rate from 34% to 50%” is a result — you can ship the flow and miss it, which is the information the framework exists to produce.
If every key result is guaranteed by completing the planned work, the OKRs are a project plan wearing a different name.
Examples that work
Product
Objective: New users reach value fast enough to stay.
- Increase day-7 activation from 34% to 50%.
- Reduce median time to first completed workflow from 4 days to 1.
- Increase 90-day retention of new cohorts from 61% to 70%.
Revenue
Objective: Growth comes from customers we already have, not only new ones.
- Increase net revenue retention from 103% to 112%.
- Increase the share of new ARR from expansion from 18% to 30%.
- Reduce gross logo churn from 2.1% to 1.5% monthly.
Engineering
Objective: Shipping is fast and safe enough that we are not afraid to deploy.
- Reduce median commit-to-production time from 6 days to 1.
- Reduce change failure rate from 18% to 8%.
- Reduce p95 API latency from 840ms to 400ms.
Marketing
Objective: We are found by the people who are already looking for this.
- Increase organic sessions from target-profile companies from 4,200 to 7,000 monthly.
- Increase pipeline sourced by content from $240k to $500k.
- Reduce blended cost per qualified opportunity from $1,900 to $1,400.
Notice what each has in common: a baseline, a target, and a measure that exists independently of the work done to move it.
The five reasons they fail
1. Too many
A company with four objectives and twenty key results has no priorities. Two or three objectives per team, three to five key results each, is the sustainable limit. The point of the framework is choosing, and a long list is a refusal to choose.
2. Tasks disguised as key results
The most common failure. Teams list what they planned to do anyway, which means the quarter is scored on activity rather than outcome.
3. Tied to compensation
The moment OKRs affect pay or performance ratings, people set targets they know they can hit. Ambitious goals require the freedom to miss them. Keep OKRs separate from the compensation process entirely.
4. Set and forgotten
Written in week one, next opened in week twelve. Without a weekly or fortnightly check-in they have no effect on what anyone does.
5. Imposed from above
Company objectives should cascade; team key results should be proposed by the team. OKRs handed down are received as targets rather than owned as commitments.
Scoring and ambition
The conventional approach scores each key result from 0 to 1, with 0.7 considered good for ambitious goals. This only works if missing is genuinely safe, which brings us back to the compensation point.
A reasonable compromise for smaller companies is to mark some key results as committed — expected to be delivered in full — and others as aspirational, where 70% is success. Being explicit about which is which prevents the ambiguity that makes scoring contentious.
The cadence
Quarterly cycles suit most companies, and the cadence matters more in a distributed team, where goals written down and visible are doing work that proximity does in an office. Annual is too slow for an early-stage business whose priorities change; monthly is too short for anything meaningful to move.
A workable rhythm: draft in the last two weeks of the preceding quarter, confirm in week one, check in weekly in existing team meetings rather than new ones, review at the midpoint and adjust if something has clearly changed, and score and reflect in the final week.
The reflection matters more than the score. What did we learn about what moves this number is the output worth keeping.
When not to use them
Two situations where OKRs add overhead and no value.
Very early stage. A company of five people still searching for product-market fit changes direction faster than a quarterly cycle. Weekly priorities serve better.
Purely operational teams. A function whose job is to maintain a steady service may be better served by health metrics and service levels than by quarterly improvement goals.
Running the first cycle
The first quarter of OKRs is usually bad, and expecting that makes it survivable.
Start with one team rather than the whole company. A single team running a clean cycle produces a working example and a set of lessons; a company-wide rollout produces a lot of poorly written key results and a reputation for bureaucracy.
Keep the first set deliberately small — one objective, three key results. The temptation is to capture everything the team is doing, and resisting it is the whole skill.
Spend real time on the baselines. A key result without a current value is not measurable, and teams routinely discover during drafting that they cannot measure the thing they most want to improve. That discovery is itself valuable and usually produces the first piece of work.
OKRs and everything else the team does
A common objection is that OKRs ignore the maintenance work — support, bug fixes, keeping systems running — that consumes much of a team’s capacity.
They should. OKRs describe the change you intend to make, not the totality of the work. The ongoing operational load belongs in capacity planning and in health metrics, not in a quarterly goal.
The practical implication is to allocate capacity before setting targets. If 60% of a team’s time goes to maintenance in a normal quarter, the OKRs should be achievable in the remaining 40%. Setting goals that assume full capacity guarantees a miss and teaches everyone that the targets are decorative.
Being explicit about this split in the planning conversation is also the moment to notice if maintenance has crept from 30% to 70%, which is information worth having.
Writing a key result that holds up
A short test catches most badly written key results before the quarter starts.
Does it have a baseline and a target? Without a current value there is nothing to improve from.
Could you complete all the planned work and still miss it? If not, it is a task.
Can it be measured without debate? If scoring it will require an argument about definitions in week twelve, settle the definition in week one.
Would hitting it actually matter? Some key results are measurable, achievable and irrelevant, which is the quietest way a quarter gets wasted.
Running each draft through those four questions takes ten minutes per team and removes most of the problems that otherwise surface three months later.
Frequently asked questions
How many OKRs should a team have?
Two to three objectives, three to five key results each. More than that is a list rather than a set of priorities.
Should individuals have OKRs?
Usually not. Team-level OKRs encourage collaboration; individual ones encourage optimising your own number at the team’s expense.
What score is good?
For ambitious key results, around 0.7. Consistently scoring 1.0 suggests targets are too easy; consistently scoring below 0.4 suggests they are disconnected from reality.
Can OKRs change mid-quarter?
Rarely, and sometimes necessarily. If the business genuinely changed direction, adjust and record why. Changing them because they look unlikely to be hit defeats the purpose.
