The Goal-Setting System Everyone Adopts and Half Get Wrong
OKRs (Objectives and Key Results) have become the default goal-setting system in tech. They originated at Intel under Andy Grove in the 1970s, were popularised by John Doerr at Google in the late 1990s, and spread from there to most modern tech companies. Their popularity is well-deserved when they are used well. The problem is that most companies use them badly.
We have watched OKRs degrade into project lists, become an annual ritual nobody believes in, and produce metrics that have nothing to do with whether the company is succeeding. We have also seen them transform organisations into focused, outcome-oriented teams that know what they are trying to achieve and why. The difference is in the discipline of writing and using them, not in the framework itself.
This article describes what OKRs really are, the most common ways they fail, how to write good ones, and how to run an OKR cycle that produces real change rather than annual ceremony.
What OKRs Actually Are
An OKR has two parts. The Objective describes what you want to achieve, in words that humans can rally around. The Key Results describe how you will measure whether you achieved it, in numbers.
The Objective
The Objective is qualitative, ambitious, and inspiring. It is what you want to be true at the end of the period. Become the default tool for designers in mid-sized startups . Make our onboarding the easiest in the category . Re-engage dormant power users . Objectives are short, memorable, and emotionally resonant. People should be able to remember the objective without looking it up.
The Key Results
Key Results are quantitative. They define how you will know whether the objective was achieved. Each is a specific, measurable outcome. Reach 50% week-over-week active design team retention . Reduce time to first published project from 22 minutes to under 8 minutes . Bring back at least 30% of users who haven't logged in for over 90 days .
The relationship is hierarchical. The Objective sets the direction. The Key Results measure progress toward it. Both matter. An objective without measurable key results is just a wish. Key results without an objective lose their meaning.
A Typical Set
Most teams have one to three Objectives per quarter, each with two to five Key Results. More than that and the team loses focus. The discipline is to pick the few things that matter most and let the rest wait. OKRs are a tool for focus, not a comprehensive list of everything you are doing.
The Most Common Failure: Output Disguised as Outcome
The single biggest mistake in writing OKRs is making the key results about what the team will ship instead of what will change. This sounds obvious. Most teams still get it wrong.
Compare these two examples:
Output-Based (Wrong)
- Objective: Improve onboarding
- KR1: Ship redesigned welcome flow
- KR2: Build interactive product tour
- KR3: Add help articles for new users
These are projects, not outcomes. They tell you what the team will do, not whether anything will change. The team can ship all three and have no impact on actual onboarding success. The OKR is a project list.
Outcome-Based (Right)
- Objective: Make onboarding so easy that new users feel productive within ten minutes
- KR1: Reduce time to first key action from 22 minutes to under 10 minutes
- KR2: Increase day-7 retention of new users from 32% to 45%
- KR3: Lift trial-to-paid conversion from 8% to 12%
These describe what should change, not what to ship. The team has flexibility on how to achieve them. They can build the welcome flow, but if it doesn't move the metrics, they keep iterating. The OKR holds them accountable to the outcome, not to the outputs.
Other Common Failures
Failure One: Sandbagging
Sandbagging is setting key results so easy that hitting them is almost guaranteed. The team looks good on paper. They hit their OKRs. But the OKRs were never ambitious enough to matter. Sandbagging is rewarded by review systems that punish missing OKRs, which produces a culture of conservative goals and slow improvement.
The fix is cultural. Make it clear that OKRs are ambitious goals, not commitments. Aim for hitting roughly seventy percent of the target on average. Hitting one hundred percent regularly is a sign that goals are too easy. Andy Grove originally framed it this way: if you are hitting all your objectives, you aren't aiming high enough.
Failure Two: Too Many OKRs
Some teams write ten objectives with five key results each. The team has fifty things they are tracking. Nothing is a priority because everything is. Focus is lost. The discipline of OKRs is what gets cut, not what gets included. One to three objectives per team per quarter is the right scale.
Failure Three: OKRs as the Whole Job
OKRs are for the most important outcomes, not for everything the team does. Routine maintenance, customer support, incremental improvements, and ongoing projects often don't belong in OKRs. Trying to capture everything in OKRs makes them too crowded to be useful. A useful rule: OKRs cover the twenty percent of work that drives eighty percent of outcomes. The other eighty percent of work happens because it is the team's job.
Failure Four: Setting and Forgetting
OKRs are written at the start of the quarter and not looked at again until the end. By then it is too late to course correct. The mid-quarter review is where OKRs do their work. If progress is bad, you have time to adjust. If progress is good, you can extend ambition. The cadence of review is what turns OKRs from ceremony into practice.
Failure Five: Cascading Without Translation
Some companies cascade OKRs from the top of the company down through every team, with each team mechanically adopting their parent's key results. The result is that teams have OKRs they didn't set and don't feel ownership of. Healthy cascading aligns teams to company objectives but lets each team write their own key results that contribute. The team's key results should be the ones that matter for their specific work, not borrowed from above.
How to Write Good Key Results
Most of the OKR work is in the key results. Objectives are easier to write because they are aspirational. Key results have to be specific, measurable, and tied to outcomes. Some rules that help.
Use Numbers, Not Adjectives
Improve user satisfaction is not a key result. It has no number. Lift NPS from 32 to 45 is. The number forces specificity and makes progress measurable. Adjectives let people claim success regardless of actual change.
Anchor on a Baseline
Reach 100,000 weekly active users means little without knowing the starting point. If you started at 95,000, the ambition is small. If you started at 60,000, it is significant. Always include the baseline: Grow weekly active users from 62,000 to 100,000 .
Choose Outcome Metrics, Not Activity Metrics
Conduct 50 customer interviews is an activity metric. It tells you how busy the team was, not whether anything improved. Identify three new high-impact opportunities validated by at least 5 customer signals each is an outcome metric. It tells you whether the activity produced what you wanted.
Avoid Vanity Metrics
Some metrics look impressive but don't actually correlate with health. Total signups can grow while paying customers decline. Page views can rise while engagement drops. Pick metrics that, when they move, tell you the business actually got better. Net revenue retention, paying customers, time to value, and similar metrics tend to be more meaningful than raw user counts or activity totals.
Combine Leading and Lagging
Some key results are leading indicators (signals that improvement is coming) and some are lagging (the actual result you wanted). A healthy OKR usually has at least one of each. Lift conversion to paid by 4 points is lagging; Achieve 80% activation in week one is leading. Tracking both lets you see whether the underlying work is producing the eventual outcome.
The OKR Cycle
The OKR cycle is what makes OKRs work. Without a cycle, OKRs are just goals. With a cycle, they become a system for focusing the organisation. The basic cadence:
Setting (Two Weeks Before the Quarter)
Two weeks before the new quarter starts, the team drafts OKRs. The PM, the engineering lead, and the design lead draft together. They look at the strategy, the previous quarter's results, and the inputs from leadership. They write candidate objectives and key results. They share with stakeholders for input.
Finalising (First Week of the Quarter)
OKRs are finalised in the first week. Late finalisation wastes weeks of the quarter. The team commits, communicates broadly, and starts the work.
Mid-Quarter Review (Halfway)
About six weeks in, the team reviews progress. Each key result gets a current status: on track, at risk, or off track. The discussion is honest: what is working, what is not, what needs to change? This is where adjustments happen in time to matter.
End-of-Quarter Review
At the end of the quarter, score each key result on a zero-to-one scale or zero-to-100 percent. The score is honest, not negotiated. The team also reviews what they learned: which key results were too easy, which too hard, what factors they didn't anticipate. The learnings inform the next quarter's OKRs.
The 70% Rule
Andy Grove's original framing suggested that hitting roughly seventy percent of OKRs is the right level of ambition. Hitting one hundred percent regularly means goals are too easy. Hitting under fifty percent regularly means they are too hard or the team is misaligned. Companies that consistently average sixty to seventy percent are usually in the healthy range.
OKRs vs. KPIs
OKRs and KPIs are often confused. They serve different purposes.
KPIs (Key Performance Indicators)
Ongoing measures of business health. Revenue, retention, active users, gross margin, customer support response time. These are continuously tracked, regardless of whether the team is actively trying to improve them. The KPI dashboard is the operational scorecard.
OKRs
The specific things the team is trying to change this quarter. They are about ambition and focus, not ongoing operations. An OKR might be to lift a specific KPI, but it is framed as a target with a deadline, not as a continuous measure.
How They Connect
KPIs tell you what is happening. OKRs tell you what you are trying to change. A team has many KPIs they monitor and a few OKRs they are actively working to move. The relationship is direct: most OKRs are about lifting a specific KPI to a specific target.
Aspect KPIs OKRs
Time horizon Continuous Quarterly
Purpose Operational health Focused improvement
Number Many (10 to 30) Few (1 to 3 objectives)
Tone Tracking Ambition
Lifespan Years, with rare changes Set and reset each cycle
Communicating OKRs
OKRs are useful only if the team and stakeholders know what they are. Several practices make them visible.
Public Sharing
Most companies share OKRs internally. The team's OKRs are visible to other teams. Higher-level OKRs are visible to all. The transparency builds alignment: when one team understands another team's OKRs, they can support each other and avoid conflicts.
Reference in Decisions
When making prioritisation calls, name the OKR being served. This work supports our objective of improving onboarding. This request doesn't fit our quarter's OKRs; we should either adjust the OKRs or de-prioritise the request. The discipline of tying decisions to OKRs trains the team to use them as a focusing tool, not as decoration.
Update Visibly
Share progress at least monthly. A short update on each key result's status, what happened, what is next. The visibility creates accountability and lets stakeholders see the work without asking.
Common Mistakes
Mistake One: Treating OKRs as Performance Reviews
If individual performance reviews are tied to OKR completion, people will sandbag. They will write key results they know they can hit. Ambition dies. The fix is to keep OKRs separate from performance reviews. OKRs are for focusing the team's ambition. Reviews are about individual contribution.
Mistake Two: Letting Them Become Bureaucracy
Some companies build elaborate OKR processes: complex scoring rubrics, tiered cascading systems, multi-week drafting cycles. The bureaucracy outweighs the value. Keep the process simple. The discipline is in the writing and the review, not in the system.
Mistake Three: Writing OKRs That Don't Reflect Reality
Some teams write OKRs because they have to, not because they reflect what the team is actually trying to do. The OKRs sit in a document; the work happens outside them. The two never meet. The fix is to take OKR writing seriously. The OKRs should be where the team is actually putting their attention. If they are not, fix the OKRs or fix the work.
Mistake Four: Punishing Misses
If missing OKRs is punished, teams set easier OKRs. Andy Grove's original system explicitly built in the expectation that you would miss some OKRs because they were ambitious. Teams that punish misses lose the ambition. Reward learning and progress, not just hits.
Mistake Five: No Reflection
At the end of each quarter, the team should reflect: what did we learn? Which OKRs were the right targets? Which were wrong? What changed our thinking? Without reflection, the OKR cycle is just goal-setting and scoring. With it, OKRs become a tool for organisational learning.
A Final Word
OKRs are a deceptively simple framework. The hard part is the discipline of using them honestly: writing outcome-based key results, setting ambitious targets, reviewing progress in time to adjust, learning from misses, and keeping them focused on what matters most. Companies that do this turn OKRs into a real engine of focus. Companies that don't turn them into a quarterly ritual that nobody believes in.
If you are introducing OKRs to a team that hasn't used them, start small. One objective per team. Two or three key results. Run a few quarters and refine. The skill of writing good OKRs takes practice; expecting brilliance in the first cycle leads to disappointment. Over time, the team gets better, and the OKRs start producing the focus and ambition they were designed to create.
Key Takeaways
- OKRs have an Objective (qualitative ambition) and Key Results (quantitative outcomes). Both matter; either alone is incomplete.
- The most common failure is making key results about what you will ship instead of what will change. Outcomes, not outputs.
- One to three objectives per team per quarter. More than that loses focus. OKRs are about the most important outcomes, not everything the team does.
- Set ambitious targets and accept hitting roughly seventy percent on average. Hitting one hundred regularly is a sign goals are too easy.
- Run the cycle: set, finalise, mid-quarter review, end-of-quarter score, and reflect. Without the cycle, OKRs are goals. With it, they are a system.