OKR (Objectives and Key Results)

OKR is a goal-setting framework in which an objective states a qualitative aim and a small number of key results define measurable outcomes that would indicate the objective has been achieved. Originating at Intel under Andy Grove and popularized by John Doerr through its adoption at Google, it is used to align activity across an organization by making intended outcomes explicit and measurable at each level.

The framework's central discipline is the separation between objectives and key results. The objective describes direction in language people can remember and act on. The key results are outcomes, not activities: they describe what would be true if the objective were met, expressed as measurable changes. This distinction is where most implementations fail, since teams naturally write key results describing work they intend to do, such as launching a feature or running a campaign, rather than the results that work is supposed to produce. A list of planned activities dressed as key results provides none of the benefit, because it can be completed in full while the objective goes unmet.

The framework is intended to make prioritization visible and to connect team-level work to organizational direction. When set well, an OKR makes it possible to reject work that does not contribute, which is its principal practical value. When set poorly, typically by defining many objectives covering everything the team was going to do anyway, it becomes a reporting overhead that documents existing plans without changing any decision.

The relationship between OKRs and performance evaluation is the most consequential design choice. Original practice at Google treated OKRs as ambitious targets where achieving around seventy percent constituted success, deliberately decoupled from compensation and appraisal so that teams would set stretching goals. Where OKRs are tied to bonuses or performance ratings, people set targets they know they can hit, and the framework converts into a mechanism for negotiating achievable commitments, which is the opposite of its purpose.

Cadence and volume also determine whether the system functions. Quarterly cycles are common, though they suit some kinds of work poorly, particularly where meaningful outcomes take longer than a quarter to materialize. A small number of objectives with a handful of key results each is manageable; the common pattern of many objectives per team produces a document nobody consults. Regular check-ins matter more than the setting exercise, since OKRs reviewed only at the start and end of a quarter influence nothing in between.

Cascading objectives through an organization is the implementation detail that most often causes the framework to collapse under its own weight. Mechanically deriving every team's objectives from the level above produces long chains where teams at the bottom hold key results they cannot influence, and the resulting documents consume a substantial share of each quarter in negotiation. The more workable arrangement sets a small number of organizational objectives, lets teams propose their own contribution to them, and accepts that some team-level work will be necessary maintenance that ladders up to nothing. That honesty about non-strategic work is what prevents teams from writing artificial objectives to justify activity that simply needs doing.

For OKRs to work, the measures they reference must exist and be trusted, which is frequently the practical blocker: teams cannot set outcome-based key results for metrics their organization cannot measure reliably. Establishing that measurement capability is normal work for data analytics, while the alignment of objectives to business direction and the governance around how they are set and reviewed usually sits within strategic planning and consulting and growth management.