OKR (Objectives and Key Results)

What separates an objective from a key result?

An objective says what a team is trying to achieve and is written in plain language, usually without a number in it. A key result says how anyone would know the objective had been achieved, and is written as a measurement with a starting point and a target. The pairing is deliberate: the objective carries meaning and direction, which a metric alone cannot; the key results carry evidence, which an aspiration alone cannot. A common failure is writing objectives that are already metrics, which produces a list of targets with no stated intent behind them. The opposite failure is writing key results that are inspiring restatements of the objective, which leaves nothing capable of settling, at the end of the period, whether the thing actually happened.

Why must a key result be an outcome rather than a task?

Because a task list can be completed in full while the objective it was meant to serve is untouched. Shipping a feature, running a campaign or holding a set of sessions are activities the team controls, which is exactly why they are appealing to write down and exactly why they measure nothing. If a key result reads as a thing the team will do, ask what it is expected to change, and make that the key result instead. There is a legitimate exception: some work genuinely is a deliverable with a date, particularly foundational work whose value is not measurable inside the period. When that happens it is more honest to record it as a committed piece of work than to dress it up as an outcome by attaching a number to it.

How often should OKRs be set and reviewed?

Setting and reviewing are separate rhythms, and conflating them is the usual mistake. Setting happens per period, most commonly quarterly, occasionally annually for a level of the organisation that moves more slowly. Reviewing happens far more often, because the point of writing a measurement down is to notice when it is not moving. A short weekly or fortnightly check of where each key result stands, where the question is what is blocking it rather than what has been done, is what separates a live set from a document that resurfaces at the end of the period as a surprise. If a review would tell nobody anything they did not already know, the key results are probably not measuring anything real.

Why are OKRs usually kept separate from pay?

Because the moment a number decides somebody's compensation, the person setting that number stops describing the world. Goals get pitched at what can safely be reached, ambition disappears, and the honest reporting the method depends on quietly stops: a key result that is going badly becomes something to explain away rather than something to raise early. That is not a character flaw in the people involved, it is a predictable response to what the organisation has chosen to reward. The structure only produces useful information while it remains safe to write down a target that might not be met, and safety here is demonstrated by what happens to the first person who misses one.

This is a design decision rather than a law of nature, and plenty of organisations do couple the two. Where they do, the effect is usually visible in the goals themselves, which become conservative, heavily caveated and closer to a description of planned work than of intended change. If the coupling is unavoidable, the mitigations are to hold the conversation about goal attainment separately from the conversation about reward, to let a manager exercise judgement rather than compute an outcome from a score, and to say explicitly that a missed ambitious goal is not automatically worse than a met modest one. The alternative most organisations choose is to keep OKRs as a planning and alignment instrument and handle pay through the performance process that already exists for it.

How is an OKR graded, and what is the grade for?

At the end of the period each key result is assessed against where it actually landed, usually as a simple score derived from the starting point and the target. The grade is not the output of the exercise. The conversation it prompts is: what moved, what did not, what was learned about the assumption the goal was built on, and what that means for the next period. Grades treated as the output become a scoreboard, and a scoreboard invites the behaviour that makes the numbers look right rather than the behaviour that makes the work go well. The score is a prompt for a discussion, not a verdict to be filed.

Conventions about what a good score looks like vary considerably between organisations. Some deliberately set goals they expect to fall short of, on the grounds that a target always met was set too low. Others expect goals to be met and treat a miss as a planning failure. Neither convention is universal, and no figure is offered here, because a number lifted from another organisation's practice arrives without the culture that made it meaningful and usually lands either as an instruction to sandbag or as a licence to underdeliver. What matters is that the convention is stated explicitly before the period starts, so everyone grades against the same expectation, and that it is applied consistently rather than interpreted differently by each manager. The periodic evaluation of an individual is a separate thing, covered under performance appraisal.

Which failure modes turn up most often?

Too many, first and most commonly. A team with a long list of objectives has not prioritised, it has written down everything it intends to do and called it a goal set; the discipline of the method lives in what gets left out. Second, sandbagged goals, where targets are set at a level already expected without intervention, producing a set that is met in full and changes nothing. Third, the restated project plan, where the key results are the milestones of work already scheduled, so the exercise documents the roadmap instead of asking what the roadmap is for and whether it is the right one.

Fourth, and quietly the most damaging, the set that is written and never opened again. Drafting goals takes real effort, the effort feels like progress, and the document then sits untouched until the end of the period when somebody reconstructs what happened from memory. Fifth, cascading too literally, where every level mechanically restates the level above and teams end up owning goals they cannot influence. Alignment is better achieved by teams writing their own goals with visibility of the level above, followed by a conversation about whether they add up, than by decomposition down a hierarchy. The common thread in all five is that the artefact gets maintained while the thinking it was meant to force never happens.

What is the difference between an OKR and a KPI?

A KPI measures the ongoing health of something that runs continuously, and it exists whether or not anyone is trying to change it. A key result measures a change a team has decided to pursue within a defined period. The same underlying metric can appear as both at different times: a measure a team is deliberately trying to move this quarter is a key result, and the same measure watched afterwards to make sure it does not slip back is a KPI. Confusing the two produces goal sets full of business-as-usual indicators, where nothing on the list represents a decision to change anything at all.

The practical test is whether the number would still be tracked if nobody was working on it. If it would, it is a health measure and belongs on a dashboard. If it exists only because a team chose a direction this period, it belongs in the goal set. Keeping both, separately, is the arrangement that works: a small set of goals describing what the team is trying to change, and a wider set of indicators describing whether the things already working continue to. Organisations that merge the two typically end up with a long list nobody prioritises, because a set containing everything the organisation watches cannot also communicate what it has decided matters most right now.