The Evidence-Led OKR Guide

32 minute read

2026 Edition

© 2026 NKD Agility. This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License. You are free to share this material for any purpose, even commercially, provided that attribution is given and it is shared unchanged. Adapted versions may not be shared without permission.

Purpose of the Evidence-Led OKR Guide

The purpose of this guide is to enable organisations to use Objectives and Key Results (OKRs) as a discipline for managing by contribution. It treats OKRs as a short, repeating cycle in which each Objective is a hypothesis and its Key Results are the evidence that tests it. Each Objective’s hypothesis has a continuous monitor and a timeframe for its expected outcome. OKRs are not a goal format, a reporting format or a performance instrument.

It applies The Problem-Led Principles to setting and testing goals.

In this guide’s experience, when strategy execution fails, a poor plan is seldom the whole cause. It also fails because plans cannot keep up with change, because goals are set without the people who must deliver them, and because organisations start more initiatives than they have capacity to finish. Organisations adopt OKRs to fix this and bring the same failures with them: task-list Key Results, too many Objectives, top-down mandates, check-in theatre (a pattern of check-ins that change no decision when the evidence says one should), grades tied to pay, and OKR work piled on top of the existing work.

The common complaint that “OKRs feel on top of the work” is a symptom, not a team failure. Its causes are missing structural conditions (see “Structural Conditions”), no capacity explicitly released for OKR work, and leaders who do not use OKRs themselves.

Leaders commit to three things before anything else: running their own Objectives visibly, releasing capacity before an Objective counts as committed, and keeping OKR results out of pay and ratings.

The Cost of Staying Where You Are

• For leaders: manager-hours spent on OKR meetings that change no decisions; strategic pivots noticed a cycle late; forecasts sandbagged (set below known capability) when results feed pay; strategy that teams can recite but do not act on.
• For practitioners (Team Members and the OKR Champion, OKR Lead and OKR Coach in “Areas of Responsibility”): OKRs that duplicate the backlog and feel on top of the work; check-in theatre; cynicism that makes the next change effort harder.

To size the manager-hours cost, count the manager-hours spent in OKR events over a cycle and the decisions taken and constraints (blockers) removed in them. The hours that produced neither are a lower bound on the cost.

For example, with invented numbers (the events are defined in “Terms”): eight managers each attend two 15-minute check-ins a week over a 13-week cycle (8 x 0.5 x 13 = 52 manager-hours). Each also spends 9.5 hours in the other events at their starting timeboxes (see “Price the Manager’s Time”): 4 hours for a half-day Opening, 1.5 hours for the cross-team read (Opening step 7), 2 hours for the Review and 2 hours for the Retrospective (8 x 9.5 = 76 manager-hours). If those 128 hours produced 32 decisions, the ratio is 0.25 decisions per manager-hour, or one decision every four hours.

What Changes When It Works

Three conditions apply within a cycle. They are steps this guide prescribes:

• fewer Objectives and initiatives run at once;
• every committed Objective has capacity explicitly released for it;
• no OKR result feeds pay or individual ratings.

Two evidence checks, separate from those steps, show whether the practice works:

• decisions per manager-hour (see “Terms”) rise;
• a stalled Key Result is noticed within one check-in, not at the Review.

If the conditions are in place and either evidence check fails to improve within a cycle, the practice is not yet working. The same two checks are the exit evidence for recovery.

What OKRs Are

An Objective is a hypothesis. It states what the organisation intends to achieve and why, and it is held as a claim to be tested, not a certainty. The hypothesis has a continuous monitor, watched from the first day of the cycle, and a timeframe for its expected outcome. It is tested continuously, and the decision to stop, adjust or continue is made at the Review at the end of the timeframe, or earlier through an early close when the evidence is clear.

Key Results are the evidence that tests the hypothesis. Each Key Result is a movement in a trusted measure, from a baseline to an intended level, by a date.

The cycle turns evidence into decisions. A short, regular cycle of Opening, check-in, Review and Retrospective decides where effort goes next.

When OKRs are turned into quotas, task lists, grades or pay, their evidence becomes harder to trust and the practice moves toward ritualised compliance: the events continue, but decisions stop changing.

OKRs Beside Strategy, Roadmaps and Portfolio

• Strategy sets the direction OKRs test. It stays above them: strategy is a hypothesis, and OKRs test, refine and evolve it. OKRs are not a substitute for it.
• Roadmaps and portfolio describe the work and initiatives the organisation expects to undertake. OKRs state the outcomes that work is expected to move, so that the roadmap can be adapted on evidence.
• Health measures say whether the existing system is still sound while change happens (see “OKRs Are Not Health Measures”).

Terms

• Cycle: the period an OKR set runs for, typically a quarter. A quarter is typical, not mandatory; its length is set by how long the outcome takes to show.
• Monitor: the Key Results with their leading indicators and counter-indicators, watched from the first day of the cycle and read at every check-in.
• Timeframe: the period in which an Objective’s expected outcome is expected to show. It ends at the Review, where the decision to stop, adjust or continue is made.
• Opening: the event that sets the cycle’s OKRs, including the cross-team read.
• Check-in: a short look at the evidence, held inside meetings that already exist.
• Review: the event that reads the cycle’s results as evidence.
• Retrospective: the event that inspects the OKR practice itself.
• Baseline: the level of the measure when the Key Result is set (the X in “from X to Y by a date”).
• Intended level: the Y in “from X to Y by a date”. It is a level to read the evidence against, never a pass/fail quota for judging people.
• Outcome Key Result: a Key Result that moves a measure of results for customers or the organisation, not a measure of work done.
• Output-type Key Result: a Key Result that delivers a milestone or deliverable. It is allowed only within the bounds in “Writing OKRs”.
• Committed Key Result: a promise about the work; the team expects to reach the intended level.
• Aspirational Key Result: a stretch, read for how far it moved.
• Leading indicator: a measure that refreshes at least as often as check-ins and is expected to move before the Key Result does.
• Counter-indicator: a measure that shows harm to quality or health caused by pushing a Key Result. Every outcome Key Result has one.
• Gaming: setting or moving intended levels, or changing Objectives, to make the result look better rather than to respond to evidence.
• Throughput: work items finished per unit of time, as the Kanban Guide defines it. It is a record of the past.
• Right-sized work item: an item small enough that the team expects to finish it within its usual cycle time.
• Cycle Time: the time a work item takes from starting to finishing. It is a flow measure, unrelated to the OKR cycle.
• Capacity: the share of a team’s future throughput, forecast from its past throughput, that is explicitly released for OKR work in a cycle. It is counted in right-sized work items, not points or hours, and held in place by work-in-progress (WIP) limits. Capacity is forecast as a range; its lower bound is the low end of that range.
• Decisions per manager-hour: decisions taken and constraints (blockers) removed in OKR events, divided by the manager-hours all OKR events cost: Opening, cross-team read, check-ins, Review and Retrospective. A decision counts only if it changed where work or capacity went, so trivial decisions cannot inflate the ratio.
• Ritualised compliance: the name this guide uses for the failure state, in which OKR events and artefacts continue but no longer change decisions. Check-in theatre is its form at check-ins. Its other signs are the “Sign it is absent” entries in “Structural Conditions”.

Who This Guide Is For

Leaders and practitioners (Team Members and the OKR Champion, OKR Lead and OKR Coach). Their decision rights are in “Areas of Responsibility”. When either group tries to do the other’s job, the practice moves toward ritualised compliance.

1. You are about to adopt OKRs. Go to “Readiness” in “Adopting OKRs”.
2. You are running OKRs that have gone wrong. Go straight to “Recovery When OKRs Have Gone Wrong”.
3. You are using OKRs inside a wider change effort. See “OKRs Inside Wider Change”.

OKRs Are Not Health Measures

Health measures monitor what you already do. OKRs focus the changes you are making. Confusing the two produces either an OKR set that is really a dashboard, or a dashboard that nobody watches.

This guide recommends the four Key Value Areas of Evidence-Based Management (EBM), set out in the Evidence-Based Management Guide, as the health measures: Current Value, Unrealized Value (EBM’s spelling), Time-to-Market and Ability to Innovate. Where an organisation already has trusted key performance indicators (KPIs), they are acceptable in the same role.

• A Key Result usually targets a change in one Key Value Area measure. That measure gives the Key Result its baseline.
• The other Key Value Areas usually supply the counter-indicators. Pair each outcome Key Result with a measure, usually from another area, that refreshes at check-in cadence, so that pushing Time-to-Market at the cost of Current Value shows up while there is still time to act.

Flow is a health concern too: see “OKRs and Flow”.

Principles Behind OKRs

This guide organises OKR practice around four principles: Clarity of Purpose, Alignment, Measurement and Accountability. They are NKD Agility’s synthesis. They are informed by Peter Drucker, Andy Grove and John Doerr, but Drucker, Grove and Doerr did not write this guide, and the lineage notes credit each with only what their own texts support.

Clarity of Purpose

An Objective states what the organisation intends to achieve and why. The limit of 1 to 3 Objectives (see “How Many OKRs”) forces a strategic choice. Leadership sets the Objectives. An Objective that commits the organisation in a way it cannot undo needs stronger evidence than one that can be undone.

Lineage. Drucker framed a manager’s goals as “defined by the contribution he has to make” (The Practice of Management, 1954, ch. 11), and returned to the theme in The Effective Executive (1967), ch. 3, “What Can I Contribute?”.

Alignment

Alignment comes from visible, self-set contribution, not from decomposing goals from the top.

• Each team and manager writes its own Objectives as its contribution to the level above, then agrees them with that level.
• Roughly half of OKRs come from the teams themselves, in Doerr’s account of practice.
• Cascading, splitting a higher Objective into lower ones, is optional. Consider it only once teams write their own OKRs (Phase 3 in “Adopting OKRs”). Start with one Objective. OKRs never decompose into task lists.
• Practices proven in one team may spread to other teams by invitation. A team takes one up without anyone deciding to widen it, and records that it has. A practice imposed on other teams stays with the decider.
• Every team’s OKRs sit in one shared list that everyone can read, kept by the OKR Lead (see “Areas of Responsibility”). Each entry shows the Objective, its Key Results with baseline and intended level, whether each is committed or aspirational, and the capacity released for it.

Lineage and evidence.

• Drucker held that each manager should “develop and set the objectives of his unit himself” (1954).
• He contrasted management by objectives with “management by drives”.
• He also had higher management keep the power to approve or reject those objectives, so agreeing them with the level above follows him.
• Doerr reports that roughly half of OKRs are set from the bottom up (Measure What Matters, 2018).
• He writes that “public, transparent OKRs spark and strengthen collaboration”. Google’s re:Work guidance also treats OKRs as public.
• This guide does not credit cascading to Grove.
• Research on participation in goal setting is mixed. Latham, Erez and Locke (1988) found assigned goals given with a clear rationale about as effective as participatively set ones; goals assigned tersely did worse.
• That self-set contribution builds ownership is this guide’s position, not a research finding.

Measurement

A Key Result is a movement in a trusted measure from a baseline to an intended level by a date, and the people reading it must trust the measure.

Lineage. Grove asked “How will I pace myself to see if I am getting there?”, and his next question begins “What are my milestones, or key [results]” (the question continues). He also recommended “pairing indicators, so that together both effect and counter-effect are measured” (High Output Management, 1983), which is why every outcome Key Result here has a counter-indicator. This guide departs from Grove’s milestones: it bounds output-type Key Results and requires an outcome Key Result for every Objective. “Measure what matters” is the title and premise of Doerr’s book.

Accountability

People own their contribution and steer themselves by the evidence, which goes first to the people who own it. Results are evidence for decisions, never a judgement of people.

Lineage. Drucker’s “self-control” required that “information should go to the manager himself, and not to his superior” (1954). That the evidence goes to its owners first is this guide’s adaptation.

Structural Conditions

OKRs depend on conditions that leaders control. Where a condition is absent, OKRs become ritualised compliance however well practitioners run the cycle.

Check these at Readiness and at every Retrospective. Where a condition is absent, fix it or start smaller. Do not ask teams to compensate for it.

Areas of Responsibility

The roles in this guide are areas of responsibility, not job titles or hierarchical positions. One person may hold several.

How check-ins fit inside an existing meeting is decided by that meeting’s owner, who also runs the check-in.

Whoever acts as OKR Champion or OKR Coach has no line authority over the people whose OKRs they facilitate or coach. This guide’s position is that people report more honestly to someone who cannot rate them. In a small organisation where a Team Leader would have to act as OKR Champion, borrow a Champion from another team.

Events in the OKR Cycle

The cycle is typically a quarter. It has four events. At the end of a cycle, the Review comes before the Retrospective.

Opening

The Opening makes strategic hypotheses explicit and agrees in advance the evidence that will test them and the timeframe for the expected outcome. It follows these steps:

1. Contextualise: set the strategic context and the purpose the Objectives serve.
2. Reflect: read the last Review’s findings, the current state including baselines, and the capacity forecast.
3. Envision: explore the outcomes the organisation needs.
4. Focus: choose 1 to 3 Objectives that fit within the lower bound of the capacity forecast.
5. Quantify: write 2 to 4 Key Results per Objective, each with a baseline, an intended level, a date and at least one leading indicator, and pair every outcome Key Result with a counter-indicator.
6. Declare: mark each Key Result as committed or aspirational.
7. Cross-team read: once every team has reached step 6, the OKR Lead convenes the teams to read each other’s draft OKRs in the shared list. The output is a recorded list of dependencies, each checked against the capacity of the team it falls on. The read surfaces dependencies; it is not a cascade, and it changes no team’s Objectives without that team’s agreement. Downgrading Key Results to aspirational because of the read is not gaming.
8. Release and commit: leaders confirm the capacity released for each committed Objective (see “OKRs and Flow”); the team agrees the set and adds it to the shared list.

A sample workshop is in Appendix B.

Check-ins

Check-ins happen inside meetings that already exist, such as one-to-ones and team meetings. Each check-in:

• reads the monitor: the leading indicators and counter-indicators for each Key Result;
• reads the Work Item Age (how long an item has been in progress) of OKR work items, so that stalled work shows before the Key Result does;
• has a stated time cost;
• has a required output: a decision taken, a constraint removed, or a recorded “evidence read, no change warranted”.

A quiet check-in is not a failure. Ritualised compliance is a pattern: check-ins that repeatedly change nothing while the evidence says something should change. The OKR Champion raises that pattern at the Retrospective.

When the leading indicator and the counter-indicator disagree, the counter-indicator wins until the conflict is explained. The meeting owner records who will explain it, by the next check-in.

Review

The Review is the end of the timeframe, where the decision to stop, adjust or continue each Objective is made on the evidence the monitor has gathered. It reads each Key Result. The team states its own reading first; the Team Leader then gives the verdict with its evidence. Each Key Result is met or not met. A not-met verdict states the movement from the baseline and the gap to the intended level. Every verdict, met or not, records what was learned. In Phase 1 of adoption, the leader one level up gives the verdict on leadership Key Results (see “Phase 1: Leadership OKRs”).

The verdict keeps accountability and gains precision: a movement and a gap say more than a grade of “0.6”. It replaces the commonly taught default, a grade from 0.0 to 1.0 (Google re:Work; also Atlassian’s Team Playbook).

At the Review:

• for a committed Key Result, a gap triggers explanation and learning, never a judgement of people;
• for an aspirational Key Result, the movement is read as evidence; getting most of the way is not failure;
• each leading indicator’s stated link to its Key Result is rechecked;
• each output-type Key Result’s claimed link to its outcome is checked, at this or the next Review;
• decisions per manager-hour are read alongside the verdicts, so that the ratio is judged by what the decisions achieved;
• findings are written down as input to the next Opening.

The Review fails its purpose if it cannot give each Key Result its verdict, or if the next cycle’s OKRs ignore what it found.

Retrospective

The Retrospective inspects the practice that produced the outcomes. It asks:

• Did check-ins change decisions when the evidence called for it, or did check-in theatre form?
• Were stalls caught at a check-in, or only at the Review?
• Is any sign of an absent structural condition present?
• Did OKR work flow through released capacity, or pile on top of the work?
• Have decisions per manager-hour risen, held or fallen?
• Did mid-cycle capacity shortfalls recur for the same team across cycles?

The team agrees its improvement actions. The OKR Coach recommends what to coach next.

When Objectives May Change

Objectives hold within a cycle. They are revisited at cycle boundaries. Before any revision, record how the current Key Results ended.

Two exceptions are legitimate, and both are recorded:

• Early close. A major disruption, or evidence that is already clear, allows an explicit early close of the cycle. A leader invokes it visibly, and the outcome of the current Key Results is recorded first. The next Opening starts from that record.
• Mid-cycle capacity shortfall. When capacity runs short mid-cycle, leaders may defer an Objective or downgrade its Key Results to aspirational (see “OKRs and Flow”). This is not gaming.

Any other mid-cycle change to Objectives or intended levels warrants scrutiny as possible gaming.

Writing OKRs

Objectives

• Name the outcome the organisation needs, and why it matters. An Objective is not a task, a project or a feature.
• A real, owned problem is a common and strong source of an Objective, but not the only one.
• Connect it to purpose. Anyone on the team should be able to say which purpose the Objective serves.
• Teams write their own (see “Alignment”).

Key Results

Write each Key Result in the form:

Verb + measure from [baseline] to [intended level] by [date]

• The date is the end of the Objective’s timeframe, set from how long the outcome takes to show. The monitor runs from the first day.
• Use measures the organisation already trusts. The recommended source is the Key Value Areas; existing trusted KPIs are acceptable.
• Give every Key Result at least one leading indicator. State its predictive link to the Key Result as a hypothesis, and recheck it at the Review.
• Pair every outcome Key Result with a counter-indicator. A bounded output Key Result, checked as met or not met, needs none.

Outcome and Output Key Results

• Each Objective has at least one outcome Key Result.
• Output-type Key Results never outnumber outcome ones.
• An output-type Key Result, such as a milestone or deliverable, is allowed only when all three hold:
  • the cycle is too short for the outcome to move;
  • its causal link to the Objective is stated;
  • it can be checked as met or not met by a date.
• The claimed link is checked against its outcome Key Result, at this or the next Review.
• A list of tasks is never a Key Result. Tasks are the work, and the work lives in the backlog.

Google’s re:Work guidance makes the same core point: “Key results should describe outcomes, not activities”.

Committed and Aspirational Key Results

Declare each Key Result as committed or aspirational at the Opening, not afterwards. Both kinds are judged at the Review by a verdict, not a grade.

How Many OKRs

Use 1 to 3 Objectives, each with 2 to 4 Key Results. Google’s re:Work suggests three to five Objectives. This guide asks for fewer, because every additional Objective competes for the same capacity.

A Worked Contrast

The numbers below are invented for illustration.

• Task list (not a Key Result): “Launch the new onboarding flow; run three customer workshops; update the help pages.”
• Outcome Key Result: “Increase the share of new customers active in their first week from 42% to 55% by 30 June.” Leading indicator: weekly first-session completion rate. Counter-indicator: support tickets per new customer.
• Bounded output Key Result, alongside it: “New onboarding flow live for all new customers by 15 May, met or not met”, with its stated link: the new flow is expected to raise first-week activity.
• Capacity: over the last three cycles the team finished between 34 and 46 right-sized items; leaders plan on the lower bound, 34 items, and release 8 of those 34 to this Objective, and the work enters the team’s board under its existing WIP limit.

OKRs and Flow

OKR work is work. If it does not enter the system that carries the rest of the work, it piles on top of it.

• OKR work goes into the existing backlog and flow, not alongside it, and counts against WIP limits.
• Forecast capacity as a range from the team’s past throughput in right-sized work items, and release capacity against the lower bound. One cycle of data gives a weak forecast; treat it as one.
• An Objective is not committed until capacity is explicitly released for it. Without released capacity, leaders defer it to a later cycle or downgrade its Key Results to aspirational, and the decision is recorded.
• When capacity runs short mid-cycle, capacity takes priority over the Objective’s commitment. Leaders defer the Objective or downgrade its Key Results to aspirational. This is a recorded, legitimate exception (see “When Objectives May Change”), and the shortfall is evidence about capacity for the next Opening.

Read flow health from the measures in the Kanban Guide: throughput, WIP, Work Item Age and Cycle Time. If WIP or cycle time worsens after adoption, that suggests OKR work is not flowing through released capacity.

Where No Flow System Exists

Before Phase 1 of adoption (see “Adopting OKRs”) commits any Objective, put in place the minimum:

• make all work in progress visible on one board;
• set a WIP limit on that board;
• cap concurrent Objectives at the limit in “How Many OKRs”;
• collect one cycle of throughput and Work Item Age data.

Until that cycle of data exists, there is nothing to forecast capacity from, so every Key Result is aspirational. The Kanban Guide describes a fuller approach to flow, including WIP control.

Price the Manager’s Time

OKRs add overhead if they add meetings. Price the time and require a return on it.

• Fold check-ins into existing meetings (see “Check-ins”).
• The OKR Lead records decisions per manager-hour across all OKR events (see “Terms”), starting with a baseline at Readiness. That ratio is the test, not hours alone.

If decisions per manager-hour do not rise after adoption while meeting hours do, OKRs are costing more than they return, and the practice must change.

Starting timeboxes. These are hypotheses to test against decisions per manager-hour, not rules. They are per team, except the cross-team read, which is shared. Shorten any event whose time produces no decisions, and lengthen one only when the evidence shows it needs more.

Lineage. Grove’s managerial leverage, the idea that a manager’s output is the output of the organisation they influence (High Output Management, 1983, ch. 3), is the basis for treating OKR event time as leverage to be priced. The ratio itself is this guide’s extension, not Grove’s.

Keep OKRs Out of Pay

Results never feed pay or individual ratings. This guide’s position is that pay linkage encourages sandbagging, meaning Key Results set below known capability, and suppresses honest reporting. Once a Key Result decides someone’s bonus, its evidence becomes harder to trust.

Lineage and evidence.

• Doerr writes that “OKRs and bonuses are best kept separate” (2018).
• Grove allowed management by objectives (MBO) output to be “just one input” to a performance review, never “a legal document” on which to base it (1983). This guide is stricter.
• Google’s re:Work guidance states OKRs are “not synonymous with employee evaluations”.
• Ordóñez, Schweitzer, Galinsky and Bazerman (2009) argue that goal setting has harmful side effects. Locke and Latham’s reply (2009) argues that these come from misuse, not from a flaw in goal setting.
• Jensen (2003) makes a related argument about budgets tied to pay.
• None of these sources tests OKRs tied to pay. The position is consistent with them, not proven by them.

OKRs and EBM Goals

For organisations using the Evidence-Based Management Guide (2020), its goal levels map onto OKRs as follows.

EBM’s experiment loop, of hypothesis, experiment, inspection and adapting goals, matches the OKR cycle. Its statement that goals can change matches this guide’s rule that Objectives change at cycle boundaries. The EBM Guide is Scrum.org’s; this guide cites it and does not reproduce it. This guide does not map the goals of other frameworks, such as Scrum.

Adopting OKRs

Adoption moves in phases, and phases move on evidence at a cycle boundary, never by the calendar. At each boundary the OKR Coach presents the gate evidence and leaders decide.

Readiness

• Check the structural conditions. Where a condition is absent, fix it or start smaller.
• Where no flow system exists, apply “Where No Flow System Exists”.
• The OKR Lead records the baseline for decisions per manager-hour in the meetings that will host check-ins.

Phase 1: Leadership OKRs

Leaders set 1 to 3 Objectives and run them for a full cycle, visibly. At the Review, the leader one level up gives the verdict on each leadership Key Result; at the top, the leadership group gives it together.

Gate: a Review produced at least one decision that changed where work or capacity went, and leaders attended their check-ins.

Phase 2: Contribution

Teams say how they contribute to the leadership Objectives, without separate team OKRs yet.

Gate: teams name the Key Results they influence, and stalls are caught at a check-in, not at the Review.

Phase 3: Team OKRs

Teams write their own contributing OKRs, within released capacity.

Gate to continue: no sign of an absent structural condition is present, and decisions per manager-hour have not fallen.

If a gate is not met, stay in the phase for another cycle, or step back, and use the Retrospective to find out why.

Recovery When OKRs Have Gone Wrong

Start here if you recognise task-list Key Results, check-in theatre, grades tied to pay, or “OKRs feel on top of the work”. Recover in this order:

1. Replace grades with verdicts: met or not met, with the movement and the gap stated for a not-met Key Result (see “Review”).
2. Separate OKRs from pay and ratings (see “Keep OKRs Out of Pay”).
3. Cut to the few Objectives that matter (see “How Many OKRs”).
4. Rewrite task-list Key Results (see “Outcome and Output Key Results”).
5. Move check-ins into existing meetings (see “Check-ins”).
6. Restart at the phase whose conditions hold. For many organisations that is Phase 1.

Exit evidence: recovery is complete when, with the conditions in “What Changes When It Works” in place, both of its evidence checks improve within a cycle.

Evidence and Its Limits

The positions in this guide are NKD Agility’s doctrine, informed by the sources cited and by practice. They are hypotheses about how OKRs produce value, and they can be wrong. Within one to two cycles, the guide is wrong, or must narrow, if you observe that:

• decisions per manager-hour do not rise after adoption, while meeting hours do;
• stalled Key Results are still discovered at the Review rather than at a check-in;
• cycle time or WIP worsens after adoption, even with released capacity;
• teams showing the signs of absent structural conditions produce decisions and learning as well as teams without those signs;
• OKRs tied to pay or grades show no more sandbagging than OKRs kept separate;
• imposed OKRs show the same ownership as self-set ones, measured by how often teams revise their own Key Results on evidence at cycle boundaries;
• reviews that give a verdict with a movement and a gap produce no more next-cycle decisions than reviews that give a 0.0 to 1.0 grade.

If teams with the structural conditions and released capacity show the same symptoms as teams without them, the cause of OKR failure lies elsewhere than this guide claims.

OKRs Inside Wider Change

When the thing you are trying to change is the organisation itself, the same discipline applies:

• The Objective names the change problem the organisation is trying to solve, and its Key Results are the evidence that the problem is shrinking.
• Capacity for change work is released like any other capacity, from whatever budget funds change work, and the change work enters the same flow.

The Problem-Led Change Guide goes further in applying OKRs to focus organisational change.

Final Words

The first test is small: run one leadership Objective for one cycle, release capacity for it, and read decisions per manager-hour at its Review.

References

• Atlassian. (n.d.). OKR guide & template, Atlassian Team Playbook (retrieved 4 October 2026).
• Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (2025.5). CC BY-SA 4.0.
• Doerr, J. (2018). Measure What Matters. Portfolio/Penguin, New York.
• Drucker, P. F. (1954). The Practice of Management. Harper & Brothers, New York. Chapter 11, “Management by Objectives and Self-Control”.
• Drucker, P. F. (1967). The Effective Executive. Harper & Row, New York. Chapter 3, “What Can I Contribute?”.
• Google re:Work. “Set goals with OKRs” (retrieved 3 October 2026).
• Grove, A. S. (1983). High Output Management. Random House, New York. Chapter 3, “Managerial Leverage”.
• Hinshelwood, M. Engineering as a Leadership System, for decision testability, including whether a decision can be undone.
• NKD Agility. The Problem-Led Principles, the values and principles this guide applies.
• Jensen, M. C. (2003). “Paying People to Lie: The Truth about the Budgeting Process”. European Financial Management, 9(3), 379-406. doi:10.1111/1468-036X.00226
• Latham, G. P., Erez, M., and Locke, E. A. (1988). “Resolving Scientific Disputes by the Joint Design of Crucial Experiments by the Antagonists”. Journal of Applied Psychology, 73(4), 753-772. doi:10.1037/0021-9010.73.4.753
• Lipmanowicz, H., and McCandless, K. (2014). The Surprising Power of Liberating Structures. Liberating Structures Press. Liberating Structures website (licensed CC BY-SA 4.0).
• Locke, E. A., and Latham, G. P. (2009). “Has Goal Setting Gone Wild, or Have Its Attackers Abandoned Good Scholarship?” Academy of Management Perspectives, 23(1), 17-23. doi:10.5465/amp.2009.37008000
• Ordóñez, L. D., Schweitzer, M. E., Galinsky, A. D., and Bazerman, M. H. (2009). “Goals Gone Wild: The Systematic Side Effects of Overprescribing Goal Setting”. Academy of Management Perspectives, 23(1), 6-16. doi:10.5465/amp.2009.37007999
• Owen, H. (1993). Open Space Technology: A User’s Guide. Abbott Publishing. See also openspaceworld.org.
• Scrum.org. (2020, September). The Evidence-Based Management Guide: Measuring Value to Enable Improvement and Agility. CC BY-SA 4.0.

Appendix A: Open Space and OKRs

Open Space Technology (Owen, 1993) is a facilitation approach for self-organisation around an urgent theme where many people have a stake and no one holds the whole answer. Use it before an Opening to surface themes that may become Objectives, and for large-scale Retrospectives. Its output is input to the Opening; it does not set OKRs by itself. Its first principle is “Whoever comes is the right people”, and its Law of Two Feet asks anyone who is neither learning nor contributing to go where they can. See openspaceworld.org.

Appendix B: Sample Opening Workshop

The structures are from Liberating Structures (Lipmanowicz and McCandless, 2014). Times are suggestions.

1. Contextualise: Nine Whys. Surface the purpose the Objectives serve. 20 to 30 minutes.
2. Reflect: What, So What, Now What? Read the last Review’s findings, baselines and the capacity forecast range. 30 to 40 minutes.
3. Envision: Appreciative Interviews, then 25/10 Crowdsourcing. Explore the outcomes the organisation needs. About 45 minutes.
4. Focus: 1-2-4-All, then Min Specs. Choose 1 to 3 Objectives within the lower bound of the forecast. 30 to 40 minutes.
5. Quantify: Helping Heuristics or User Experience Fishbowl. Write 2 to 4 Key Results per Objective against the writing rules. 30 to 45 minutes.
6. Declare: Wicked Questions. Mark each Key Result committed or aspirational. About 20 minutes.
7. Cross-team read: no Liberating Structure is prescribed; a gallery walk of the shared list works. Record dependencies and check each against capacity. 60 to 90 minutes, all teams together.
8. Release and commit: Conversation Café. Leaders confirm released capacity; the team agrees the set. About 30 minutes.

Was this useful?

Useful Not for me

Checking…

Enjoyed this? One click, no account.

Contents

Contents

Enjoyed this? One click, no account. Heart this item Checking…

Vote useful Vote not useful

Sign in to make this yours

One free account across every NKD Agility site gets you:

• Bookmarks — save things to read later.
• History — find that page you forgot to bookmark.

Your activity is yours: it powers your account pages, and we only ever analyse totals per item — never what you individually did.

Sign in Not now

Share

engineering-leadership.hinshelwood.com

The Evidence-Led OKR Guide

NKD Agility's guide to running OKRs as tested hypotheses, with Key Results as evidence, results kept out of pay, and OKR work flowing through released capacity.

Copy Link

---

LinkedIn WhatsApp Twitter Facebook Email

Save Save this item for laterSign in to save Checking… Subscribe

More actions

• • Save Sign in to save
• • Subscribe

• ---

• • 

    engineering-leadership.hinshelwood.com

    The Evidence-Led OKR Guide

    NKD Agility's guide to running OKRs as tested hypotheses, with Key Results as evidence, results kept out of pay, and OKR work flowing through released capacity.

    Copy Link

    ---

    LinkedIn WhatsApp Twitter Facebook Email