OKR and SMART: goals that survive the quarter

Both frameworks descend from Peter Drucker's management by objectives, and both are older than the blog posts that describe them.

OKR was built at Intel by Andy Grove in the 1970s, where it was known internally as iMBOs, Intel management by objectives. Grove's version, set out in High Output Management, reduces to two questions: where do I want to go, and how will I know whether I am getting there? The answer to the first is the Objective. The answers to the second are the Key Results. John Doerr learned the method at Intel, and in 1999, by then a partner at the venture firm Kleiner Perkins, presented it to a Google of roughly forty people. Google kept it, and the practice spread to LinkedIn, Twitter, Spotify, Airbnb and a long tail of companies copying Google. Doerr's 2018 book Measure What Matters is why most people outside those companies have heard of it.

SMART is older and narrower. George T. Doran published There's a S.M.A.R.T. way to write management's goals and objectives in the November 1981 issue of Management Review. His original letters were not the ones in circulation today: Specific, Measurable, Assignable, Realistic, Time-related. Doran was explicit that not every objective would carry all five, and that the value lay in having a checklist at all. The acronym has been reinterpreted many times since, most commonly as Specific, Measurable, Achievable, Relevant, Time-bound, with later variants adding letters for Evaluated and Reviewed. There is no authoritative modern version, which is worth knowing before anyone argues about what the A stands for.

An OKR is one sentence and a short list of numbers under it. Doerr's template is the clearest statement of the structure: I will (Objective) as measured by (Key Results).

• The Objective is qualitative, memorable and directional. It says where you are going and, ideally, why anyone should care. It has no number in it.
• The Key Results are quantitative and few. Each one is a measurement with a starting value, a target value and a date. Two to four per objective is the usual guidance, and IBM's version of the advice is one objective with two to four key results.

The load-bearing constraint is that key results measure outcomes, not activity. The test takes ten seconds: imagine completing every key result and none of them moving the objective. If that is easy to imagine, you have written a task list. Three to five objectives per team per quarter is the ceiling most practitioners settle on; beyond that the set stops being a statement of priority, which is the only thing it was for. To decide which candidates make the cut, the scoring methods in MoSCoW and RICE are built for that argument.

The part of Google's practice that travels worst is the grading. In Google's re:Work guidance, OKRs are scored on a 0.0 to 1.0 scale at the end of the cycle, and the sweet spot for an objective is around 0.6 to 0.7. Consistently scoring 1.0 is treated as a signal that the targets were set too low, not as a triumph. Consistently scoring under 0.4 means something needs re-examining, either the ambition or the execution.

That only makes sense with the distinction Google draws between two kinds of OKR, and skipping it is where most adoptions go wrong.

• Committed OKRs are expected to land at 1.0. Schedules and resources are adjusted to make sure they do. Missing one is an incident that gets discussed, because someone downstream was counting on it.
• Aspirational OKRs describe how the world should look and carry no known path to get there. The expected average is well short of 1.0, and a stable pattern of full attainment means they were not aspirational.

A goal is one or the other, and the label belongs on it in writing. An aspirational OKR quietly held to as a commitment produces sandbagging within one cycle: people learn to write targets they can already hit. A committed OKR treated as a stretch produces broken promises. The 70 per cent rule belongs to the aspirational category, not to OKRs in general.

SMART is not a goal-setting system. It is a quality checklist you run over a sentence someone has already written, which is why it takes two minutes and why it works at any altitude, from a personal objective to a single key result.

• Specific. Names the thing that changes, for whom. "Improve onboarding" fails. "A new engineer ships to production in their first week" passes.
• Measurable. There is a number and a place the number comes from. If nobody can say which report or query produces it, the goal is not measurable yet, however numeric it looks.
• Achievable. Possible with the people, budget and time actually available. Note that this criterion actively pushes against stretch, which is the reason SMART is a poor tool for an aspirational objective and a good one for a committed key result.
• Relevant. It ladders up to something larger that someone can name. In Doran's original the letter was Assignable, meaning a named owner rather than a team in general, and that reading is worth keeping alongside the modern one. Both failures are common and they are different failures.
• Time-bound. A date, not a season. "By 30 September" behaves differently from "in Q3" because only one of them is falsifiable on a specific morning.

The criteria are best used destructively. Read a goal, find the first letter it fails, fix that, read it again. Most goals fail on Measurable, and the fix is usually to name the source of the number, not to add a percentage sign.

They are routinely presented as alternatives to choose between. They answer different questions, and most of the confusion comes from applying one at the altitude that belongs to the other.

The last row is worth stating plainly: an OKR set is not a to-do list and is not supposed to cover everything a team does. Keeping the lights on does not need an objective. If your OKRs describe your whole workload, they have stopped distinguishing anything, and the ordinary work is better handled by the systems in Getting Things Done or a running board of the kind in Agile, Scrum and Kanban.

Weak, and entirely typical:

• Objective: Improve customer support.
• KR1: Hire two more support agents.
• KR2: Roll out the new helpdesk tool.
• KR3: Improve customer satisfaction.

Three defects. The objective is a direction with no edge, so nothing about it can be true or false in December. KR1 and KR2 are tasks: both can be completed in full while support gets measurably worse, which is the ten-second test failing. KR3 has no number, no baseline and no named source, so at the end of the quarter it becomes an argument about impressions.

The same intent, written as an outcome:

• Objective: Customers get their problem solved the first time they contact us.
• KR1: First-contact resolution rate from 61 per cent to 75 per cent, from the weekly helpdesk report.
• KR2: Median first response time from 9 hours to under 2 hours in business hours.
• KR3: Reopened-ticket rate stays below 8 per cent.

The hiring and the tool rollout have not disappeared, they have moved to where they belong: they are the plan for hitting KR1 and KR2, and they now have to justify themselves against that. KR3 is doing a different job from the other two. It is a guardrail, the metric that catches you gaming the first one by closing tickets that were not actually resolved. Any key result that can be hit by degrading something else should be paired with the measure of that something else.

Weak: Get better at onboarding new engineers this year.

It fails four of the five letters. Not specific (better in what respect), not measurable (no number, no source), not assignable or clearly relevant to anything above it, and only nominally time-bound, since a year-end date exerts no pressure in March.

Strong: By 30 September, every engineer who joined in Q3 has merged a change to production within five working days of their start date, tracked from the first commit timestamp in the repository, and I own the onboarding checklist that gets them there.

It is longer, and that is the point. Specific names the change and the population, Measurable names the source (commit timestamps, not a survey), Achievable is bounded by an existing checklist, Relevant and Assignable are covered by the ownership clause, and Time-bound is a date rather than a quarter. It is also now usable as a key result under an objective about the team growing without slowing down.

The failure modes are consistent enough across organisations to be worth listing as a pre-flight check.

• Key results that are task lists. The most common defect by a wide margin. Symptom: every key result starts with a verb like launch, hire, migrate or deliver. Fix: ask what those tasks are supposed to cause, and measure that instead.
• OKRs wired to compensation. Google's own guidance keeps OKRs separate from performance evaluation, and Doerr argues the same case at length. The reason is Goodhart's law, in the phrasing popularised by Marilyn Strathern: when a measure becomes a target, it ceases to be a good measure. Attach a bonus to a stretch goal and you have not created ambition, you have created an incentive to negotiate the target down before the quarter starts.
• Too many objectives. Fifteen objectives is a workload description. The framework's entire contribution is forcing a choice, and a set that includes everything has quietly opted out of it.
• Set and forgotten. Written in week one, opened in week thirteen. Without a mid-cycle check the goals cannot influence any decision, which was the point. A short monthly review against the numbers is enough, and it doubles as an early warning: drift is visible in week four and entrenched by week twelve.
• Measuring what is easy instead of what matters. Metrics already sitting in a dashboard are seductive because they need no work. Ask whether someone outside the team, seeing only those numbers, would call the objective achieved. A time audit is often the cheapest way to find where the real cost sits before committing to the wrong measure for three months.

Goal frameworks decide what a quarter is for. They say nothing about how any of it gets done, and a well-written OKR set will not survive a week with no room in it. The habit-level counterpart is Pomodoro and Atomic Habits, which argues that systems outperform goals at the daily scale; the prioritisation counterpart is the Eisenhower Matrix and the Pareto principle. OKR sets the destination for the quarter, SMART checks that each measurement of it is honest, and the daily systems decide whether any of it happens.