Strategy Align

OKRs

OKRs are objectives and key results: a few goals per period, each with measurable outcomes that show whether it was met.

The questionWhat are the few things we must achieve this period, and how will we know, without argument, whether we did?

Objectives and key results. Intel's earlier name was iMBO, for Intel management by objectives.

Model · Andy Grove, popularized by John Doerr, 1970s

Objective New customers live faster, this quarter

Key result 1 Median days to first use from 41 to 21

Key result 2 90 percent live without a support escalation

Key result 3 Setup tickets per customer halved

One objective from the worked example, with the key results that show whether it was met.

When to use it

A strategy has been agreed, and teams cannot say which three things matter most this quarter.
Leadership reports progress as activity, such as projects launched or meetings held, and nobody can tell whether outcomes changed.
Several teams depend on each other, and you need a shared, visible list of goals so they can see conflicts before the quarter starts.
A business is changing direction and wants a short-cycle way to set stretch goals and check them often.

When to avoid it

The organization has not decided its strategy. OKRs will turn a vague direction into a long list of measured activity. Make the choices first.
The work is steady-state operations where the job is to hold a level, such as uptime or close cycle time. Use operating KPIs and a dashboard.
Leadership intends to tie key-result scores to bonuses. People will set goals they know they can hit, and the stretch the method depends on disappears.
The team is small and already aligned on two or three priorities. Writing them down as OKRs adds ceremony without changing behavior.

Overview

OKRs set a small number of qualitative objectives for a short period, each paired with a few measurable key results that show whether it was met. They support the choice of what a company and its teams will focus on this quarter, and they make progress visible to everyone working on the same goals.

The method depends on key results being outcomes, not tasks, and on keeping scores out of pay. Most failures come from loading the system with dozens of objectives, writing deliverables as key results, or cascading every goal down the hierarchy. Judge the rollout by whether teams stop work that serves no objective and change initiatives when a key result stalls.

The elements

Objective

A short, qualitative statement of what the team wants to achieve this period. It should be significant enough to change priorities and concrete enough that people can tell what is in and out of scope. Teams usually hold only a few at a time.

Key results

Usually three to five measures for each objective that show, without argument, whether it was met. Each is an outcome with a number and a date. A key result that can be completed by doing a task, such as launching a feature, is a task, and belongs in the initiatives.

Initiatives

The projects and activities the team expects to move the key results. They can change during the period if the numbers do not move. Keeping them separate from key results lets the team drop a project without abandoning the goal.

Cadence and scoring

OKRs are set for a short period, usually a quarter, checked during it, and graded at the end. Doerr distinguishes committed OKRs, expected to be met in full, from aspirational ones, where partial progress is the expected result and full scores every time suggest the goals were too easy.

What it is not

A task list. If every key result is an activity the team controls, the OKR measures effort, not progress.
A performance-review system. Grove and Doerr both kept OKRs apart from compensation, so people would set ambitious goals and report honestly.
A cascade where every objective is copied down the hierarchy. Top-down cascading of every goal produces many layers of near-identical OKRs and slows planning. Most practitioners align teams to a few company objectives and let teams write their own.

The steps

Start from the strategy

Pick the few company objectives for the period from the agreed strategy. If an objective cannot be traced to a strategic choice, question why it is there.
Write outcomes, not tasks

For each objective, draft key results that measure a change in the world, each with a baseline, a target, and a date. Test each one by asking whether the team could complete it without the outcome improving.
Let teams write their own

Share the company objectives and have teams propose OKRs that contribute to them. Review them together to find conflicts, duplicates, and dependencies between teams.
Check in during the period

Review progress every week or two. When a key result is not moving, change the initiatives rather than the target, and record what was learned.
Grade and reset

At the end of the period, score each key result, separate committed from aspirational goals in the review, and carry what was learned into the next set. Keep the scores out of pay decisions.

In practice

A B2B software company had moved to OKRs a year earlier and by the third quarter carried forty-one company and team objectives. Customer onboarding was the CEO's stated priority, but the onboarding team's key results were "launch new setup wizard," "hire two implementation managers," and "publish help center." All three were finished on time, and new customers still took a median of forty-one days to first use.

The consultant rewrote the onboarding OKR with the team. The objective became getting new customers live faster this quarter. The key results became median days to first use from forty-one to twenty-one, ninety percent of new customers live without a support escalation, and setup tickets per new customer cut by half. The wizard and the hires moved to initiatives. Company objectives were cut from fourteen to four, and teams were asked to write only OKRs that served one of the four. By quarter end, median days to first use was twenty-nine, which the team graded as partial progress, and the next quarter's initiatives changed because the data showed most delays came from customers' own security reviews.

What you leave with

A short set of company objectives tied to the strategy, each with measurable key results.
Team OKRs that each support a named company objective, with dependencies marked.
A list of initiatives kept separate from the key results they are meant to move.
A check-in rhythm and an end-of-period grading with notes on what was learned.

Failure points

Too many objectives

Every function adds its priorities, and the company carries dozens of objectives. The method's main benefit, focus, is gone, and the list becomes a planning register.

Key results that are tasks

Teams write deliverables because they are easy to control and easy to grade. Everything is completed, and the outcome the objective named does not change.

OKRs in the bonus plan

Scores feed into compensation or performance ratings. Teams sandbag targets, argue about grading, and stop reporting problems early.

Mechanical cascading

Each level copies its manager's objectives and splits the numbers. Planning takes weeks, teams lose ownership, and adjustments in the quarter need sign-off at every layer.

OKRs replacing strategy

A leadership team without clear strategic choices uses the OKR process to produce them. The result is a long set of measured goals with no logic connecting them.

The failures above are usually Synthesis & Story: the work was done, but it never became one clear message a client could act on.

Origin

Andy Grove introduced the system at Intel in the 1970s, adapting Peter Drucker's management by objectives, which Drucker had described in The Practice of Management in 1954. According to John Doerr, Intel called it iMBO. Grove paired each objective with a small set of key results, set them more often than the annual cycle MBO usually used, and kept them separate from compensation. He described the approach in High Output Management in 1983.

Doerr learned it as an Intel employee in the 1970s and, as a venture capitalist at Kleiner Perkins, introduced it to Google's founders in 1999. The name OKRs is usually credited to him. His 2018 book Measure What Matters collected practitioner accounts and made the method widely known outside technology firms. The method is not trademarked or licensed, although many consultants and software vendors sell their own versions of it.