What OKRs actually are (and are not)
An OKR consists of two parts. The Objective is a qualitative, inspiring statement of where you want to go. It answers the question: "What are we trying to achieve?" The Key Results are a small set of measurable outcomes — typically 3 to 4 — that answer: "How will we know we got there?"
The most important thing to understand about OKRs is that Key Results are not tasks or outputs. "Launch the redesigned checkout flow" is a task. "Increase checkout completion rate from 62% to 78%" is a Key Result. The difference matters because tasks can be completed without achieving the underlying goal. An outcome-based Key Result keeps the team focused on the thing that actually matters — the change in the world — rather than the activity that is supposed to produce it.
OKRs are also not KPIs. KPIs (Key Performance Indicators) measure the ongoing health of existing processes — they tell you whether things are working as expected. OKRs define where you are trying to go. The distinction is between measurement and aspiration. Most organisations need both, and conflating them is a common source of confusion.
The right level of ambition
Google's approach to OKRs targets a 60–70% achievement rate on Key Results. This is deliberate: if you consistently achieve 100% of your OKRs, your goals were not ambitious enough. The design intent is that OKRs should require meaningful stretch — enough that missing them slightly is acceptable, because the team was aiming at something genuinely difficult.
This is counterintuitive for most organisations, where hitting targets is good and missing them is bad. The OKR framework inverts this slightly: consistently achieving 100% is a warning sign, not a celebration. It means the team has learned to set safe targets rather than ambitious ones.
In practice, this requires a cultural shift. Teams need to feel safe setting ambitious goals without being punished for missing them by a reasonable margin. This is why OKRs should generally not be directly tied to performance reviews or bonuses — doing so immediately produces sandbagging (setting easily achievable targets) and defeats the purpose of the framework entirely.
How to write a good Objective
The Objective is the most neglected part of the OKR. Teams often write Key Results first (because metrics are concrete and easy to think about) and retrofit an Objective that is really just a headline. The result is an uninspiring, functional statement that provides no motivational pull.
A good Objective has three qualities: it is qualitative (not a metric), inspiring (people should feel excited when they hear it), and directional (it points clearly toward a desired future state). Compare:
Weak Objective: "Improve customer retention" — functional, not inspiring, too generic.
Strong Objective: "Make our product so indispensable that leaving feels like a genuine loss" — qualitative, specific, aspirational, memorable.
A useful test: if your Objective sounds like it could belong to any company in your industry, it is not specific enough. The best Objectives are distinctive enough to sound like something your company specifically cares about.
How to write good Key Results
Key Results are where most OKR implementations fall apart. The most common mistakes are: writing outputs instead of outcomes, writing targets without baselines, and writing so many that focus is lost.
Outcomes, not outputs: "Launch the new onboarding flow" is an output — a thing you do. "Reduce median time-to-first-value from 14 days to 5 days" is an outcome — a change in the world. Always ask: "What will be measurably different as a result of this work?"
Baselines matter: "Increase retention to 85%" is meaningless without knowing where retention currently stands. "Increase 90-day retention from 71% to 85%" is measurable and specific. Baseline data is often the blocker — if you do not have it, establishing it should be the first Key Result of the cycle.
Three is the right number: Four Key Results that you track diligently are more valuable than eight Key Results that drift. Most OKR coaches recommend three Key Results per Objective. If you have more than four, you are probably describing multiple Objectives, not one.
Cascading, aligning, and not over-engineering
OKRs work at multiple levels: company OKRs set the direction, team OKRs align to them, and individual OKRs align to team ones. In theory this creates a coherent hierarchy of goals that all point in the same direction. In practice, strict top-down cascading often produces resentment and disconnection — teams are handed goals they had no part in creating.
The better approach is bidirectional: leadership sets company-level Objectives, then invites teams to propose their own OKRs that serve those objectives. Teams understand their own work better than leadership does; giving them ownership of the Key Results produces more accurate, more motivated implementations.
The most important thing to avoid is over-engineering the framework. OKRs are most effective when they are simple enough that everyone can remember them without looking them up. If your OKR process involves more than a day of planning per quarter and more than an hour of review per month, you are probably spending more time managing the framework than the work it is meant to direct.
The quarterly check-in: the part most teams skip
OKRs set in January and reviewed in March are not OKRs — they are aspirations with a deadline. The power of OKRs comes from the regular check-in: a short, focused conversation about whether you are on track, what is blocking progress, and whether any Key Results need to be updated to reflect new information.
Monthly check-ins are the minimum for quarterly OKRs. They should be short (30 minutes is enough for a team OKR review), focused on the numbers, and honest about blockers. The check-in is not a status meeting — it is a decision-making conversation about whether the plan is still the right plan.
Key Results can be updated mid-cycle if circumstances change significantly — a competitor enters the market, a key team member leaves, a product assumption is invalidated. OKRs should be a living document, not a contract. Teams that rigidly defend their original Key Results in the face of changed reality are doing accountability theatre, not goal management.