OKRs Are Not a Strategy: What the Framework Gets Right, What It Misses, and Where Business Architecture Fits

You've seen both documents. The strategy: produced at an offsite, circulated, quoted in the town hall. The OKRs (Objectives and Key Results): in the tracker, cascaded down the org chart, graded every quarter. What you've probably never seen is the line that connects them, because in most organisations it was never drawn.

That missing line is the whole story, and it isn't a failure of effort. The objectives are genuine, the key results are measurable, the reviews happen on schedule; the system is working exactly as designed. The problem is what the design quietly assumes. That someone, somewhere, already made the strategic choices and developed the capabilities that would make the measurements mean something. When that work is missing, OKRs measure movement against a strategy that doesn't operationally exist.

If you came here asking why OKRs fail, here's the short version. Strategy doesn't fail in execution because people don't try hard enough. It fails because the chain from purpose to strategic choice to capability to operations breaks at a specific, identifiable point. OKRs sit at the two ends of that chain: the Objective names an aspiration, the Key Results measure operations. Between them sit the two things that make the measurement mean anything, the strategic choices and the capabilities those choices require. OKRs are the dashboard; those two things are the engine, and a dashboard can't build the engine it reads. Call it the Missing Middle. Every Key Result silently depends on it, and no OKR has a field for it. When OKRs fail, the failure is diagnostic: it tells you exactly which half of the middle is empty, the strategic choice or the capability.

Seen in the wild. One organisation felt that missing field and built one. Its official OKR training gives OKRs three parts, Objective, Key Activities, Results, then undercuts itself across two consecutive slides: "OKRs are not the sum of all tasks," followed by "key activities are the tasks you need to do" and "they answer the How." Both are house doctrine. The contradiction isn't sloppiness. It's the Missing Middle surfacing: the framework senses the middle shouldn't be a task list, and has nothing else to put there.

What OKRs Actually Are

Andy Grove's original insight was precise. Management by Objectives had drifted into a system that measured output (tasks completed, targets hit) rather than outcome (the benefit or impact of the work). OKRs corrected this by separating the Objective (qualitative, aspirational, directional) from the Key Results (quantitative, measurable, specific) and decoupling both from individual compensation.

That correction matters. But it doesn't resolve a more fundamental problem, one that Roger Martin names directly: OKRs are not a strategy. They are a measurement instrument. And measurement only works when the thing being measured is understood.

Placed in the Strategic Choice Cascade (Lafley and Martin, Playing to Win), OKRs occupy two positions. The Objective sits at Winning Aspiration: the qualitative expression of where the organisation is trying to go. The Key Results sit at Management Systems: the barometer that tracks whether the chosen capabilities are producing the intended outcomes. In Sinek's Golden Circle, the Objective anchors at Why. Key Results measure the What: the results operations produce, read as a signal of progress toward the outcome the Objective named. The Golden Circle's How (the method and principles that translate Why into action) maps to Define in the Design4 cycle. That is exactly the level OKRs skip.

What the OKR framework doesn't include (and doesn't claim to include) is the three choices between those two positions.

The Design4 cycle makes the gap precise. Each phase carries a governance question: Discover asks "are we getting the benefits?", Define asks "are we doing the right things?", Develop asks "are we doing them the right way?", and Deliver asks "are we getting them done well?" OKRs operationalise exactly two of these: the Discover question (Objective = what benefit are we pursuing?) connected directly to the Deliver question (Key Results = are we getting it done?). Define and Develop (are we doing the right things, and are we doing them right?) are simply not asked.

There is a tell in how the cascade moves. In a coherent model, descending a level changes the question: purpose gives way to where to play, which gives way to how to win, which gives way to the capability required, which gives way to the operation that runs it. Each level is a translation into a different kind of choice. In the OKR cascade, descending a level changes only the scale: the parent activity is chopped into smaller activities, and the smallest are handed to individuals with their names attached. That is decomposition, not translation, and it is what you are left with when the levels that would change the question, Define and Develop, are absent.

Two things the table compresses. First, the Objective sits at Winning Aspiration, the aspirational tip where purpose shades into the first strategic choice: OKRs begin already inside strategy's doorway, then skip the choices that would give the aspiration a route. Second, the Golden Circle has only three rings, so its single "What" carries two different Design4 levels at once: the capability that has to be built (Develop) and the operations that run on it to produce results (Deliver). Neither of those is the outcome. The outcome is the benefit the work is for, and it sits back at the Why, in Discover, where the Objective names it. Design4 keeps capability and operations apart, because the gap between building a capability and running it is exactly where OKRs lose the thread.

The table also flattens something the cascade doesn't: descent isn't one-way. A capability gap found at Develop can force the strategic choices at Define to be revised, and that upward revision across the five cascade levels is what keeps strategy coherent rather than aspirational. OKRs assume every level above Management Systems is settled, and have no mechanism for the loop.

The Missing Middle

OKRs measure the two ends. The Missing Middle — Define and Develop — is the gap every Key Result silently depends on.

The Missing Middle has two halves, and OKRs skip both. In the Design4 cycle, Define is where the strategic choices are made: which stakeholders to serve, which markets to compete in, which value proposition to defend. Develop is where the capability architecture is built: the people, processes, technology, and information that the chosen "How to Win" requires.

Without Define, the Objective has no theory of winning attached to it. It names a destination without specifying the route, the terrain, or the mode of travel. Different teams interpret it through their own context. What "improve patient outcomes" means to an ICU team is not what it means to a community health program. Without an agreed strategic definition (which patients, which interventions, which theory of how the organisation's actions connect to the outcome), the Objective becomes a Rorschach test. Each team produces Key Results that are coherent within their boundary and incoherent across it.

Without Develop, the Key Results have no capability architecture to measure against. Outcomes require capabilities that have been built. If the capability doesn't exist, the only measurable things are activities: tasks completed, features shipped, reports produced. That's not a Key Results problem. It's the absence of Develop. And somewhere past that empty box is the person the Key Result was meant to describe, still waiting on a capability no one has built.

OKRs do not merely omit the capability question; their own verification ritual forecloses it. Asked whether the resources exist to hit the Objective, the standard guidance is: if not, prioritise. A capability gap becomes a decision to do less, never a decision to build. Develop is not skipped by oversight; it is ruled out of scope by the method itself.

The middle rarely stays visibly empty. Teams feel the gap, so they add a column: "Key Activities," "Initiatives," "the How." Then they fill it with the only thing a two-part framework gives them the vocabulary for: tasks. A list of activities appears exactly where the strategic choice and the capability should be, and because it is busy and concrete, it reads as substance. It isn't. A task list in the middle is not the middle filled; it is the empty middle wearing the costume of work. The diagnostic is simple: if the space between your Objective and your Key Results is a set of things to do, rather than a choice about how to win and the capability that choice requires, the middle is missing and the tasks are hiding it.

Put that three-part model back into Design4 and the move becomes clear. The Objective sits in Discover, naming the benefit and asking whether we are getting it. Results sits in Deliver, the barometer for whether the work is getting done, pressed into service to answer a question it cannot really answer: how do we know we are achieving the objective? Those are the two ends the framework already covers. The added column, Key Activities, lands in Deliver as well, a list of the work to do. So the team that felt a middle was missing filled it with more Deliver. Define (are we doing the right things?) and Develop (are we doing them the right way?) go untouched. They did not bridge the gap between Objective and Result. They doubled the far end and left the middle uncrossed.

The tell of OKR Theatre: flat for most of the quarter, then a vertical surge at the deadline. The Key Results were remapped to routine work at the last minute, not pursued as bets.

This is what the literature calls OKR Theatre: the ceremonies of goal-setting performed with commitment, the dashboards green, and the strategic behaviour unchanged. Management research has catalogued the side effects of goal-setting without the right governance for years: tunnel vision, gaming, the erosion of intrinsic motivation (Ordóñez et al., Goals Gone Wild, 2009). What it has been slower to name is the structural cause. Theatre isn't poor discipline or weak ambition, and it isn't simply goals behaving badly. It's a structural signal. The middle boxes weren't filled in before the measurement started.

Related reading: The Phase Every Management System Skips. OKR Theatre, Measurement Theatre, and Maturity Theatre are one failure in three costumes: none of the three does the Define phase, where the middle boxes get filled in.

Where the OKR Framework Came From

At Intel and Google the engine was already running when OKRs arrived; the dashboard measured what it produced. Exported to other sectors, the dashboard travelled and the engine didn't.

OKRs were designed in the tech sector, and their native environment explains why they appeared to work there.

The analyst Marty Cagan is direct: OKRs are a measurement layer that requires a foundational product operating model to function. The model has two components: empowered teams with genuine autonomy to decide how to solve assigned problems, and a culture of discovery (the discipline of testing whether an idea solves the real problem before committing to build it). At Intel and Google, neither was absent. Product management handled Define continuously. The deep engineering capability that Develop requires was already in place and maturing, extended by iteration rather than stood up from scratch each cycle. The infrastructure came first. OKRs measured it.

Recall the dashboard and the engine. At Intel and Google, the engine, the Missing Middle, was already running when OKRs arrived, and the dashboard measured what it produced. When the framework was exported to healthcare, government, and education, the dashboard travelled and the engine didn't.

These sectors don't have product management as a standard function. Iteration cycles are measured in years, not quarters. The consequences of undershoot are not recoverable through the next sprint. Cagan names the failure mode "feature factory": teams shipping 100% of the roadmap on time, achieving 0% business impact, because the underlying ideas were never tested against the actual problem before building started. In sectors with slower cycles and higher-stakes undershoot, that failure takes longer to surface and costs more when it does.

This is why the literature's evidence base for OKRs is almost entirely drawn from tech, and why case studies from healthcare and government tend to be presented as aspirational rather than evaluative. The framework works where the Missing Middle is already in place; it doesn't where it isn't. Sector is a useful first indicator, not a definitive one. Integrated delivery networks with mature population health infrastructure (Kaiser Permanente is the standard example) do have the capability architecture to make operational OKRs meaningful. The question is never which sector. It's whether the engine is running.

The Complexity Threshold

A shed: two people hold the middle in their heads. A hospital: the middle — the strategic choice and the capability — has to be drawn before anyone can build. The question is which one your change is.

The OKR short-circuit isn't always wrong. It works under one condition: the problem is simple enough that the Missing Middle is implicit, held in someone's head instead of on paper.

Consider a team of two building a garden shed. The objective is clear. The key results are obvious. Both people hold the entire picture in their heads. There's no strategic definition to negotiate, no capability architecture to assess, no coordination problem to solve across organisational boundaries. Two people with construction skills, some tools, and a weekend is the right governance model for that problem.

Now consider a hospital. "Provide excellent patient care" is shared in name only. Excellent patient care means something different to the structural engineer, the clinical planner, the ICU nurse, and the facilities manager. Without someone who translates purpose into a coherent design the whole team can build from, you don't get a hospital. You get a building that doesn't work as one. Nobody hired a bad contractor. Nobody set bad OKRs. The problem is structural: without the architectural work, coordinated execution is impossible and the objective stays aspirational.

The question isn't whether your organisation is using OKRs well. It's whether your change is a shed or a hospital. The distinction isn't between operational and strategic problems. It's between problems where Define and Develop are already done and stable (genuinely rare outside well-established, unchanging operations) and problems where they need to happen explicitly before measurement can mean anything.

Healthcare illustrates this concretely. These are real OKRs from the literature, presented as evidence the framework works in the sector:

Objective: Improve chronic disease management within primary care.

• KR1: Increase hypertension control rate from 55% to 70%
• KR2: Achieve 85% patient adherence to diabetes care guidelines
• KR3: Reduce avoidable hospital admissions for chronic patients by 15%

Objective: Advance the adoption of digital health tools and telemedicine.

• KR1: Increase telemedicine consultations from 20% to 40% within six months
• KR2: Achieve 100% staff proficiency in a new EHR system within three months of launch

Both look specific and measurable. Neither is diagnostic. The first set doesn't address Define: which patient population, which intervention model, what theory of how primary care actions connect to population-level hypertension control. It doesn't address Develop: what capability the organisation needs to actually move the hypertension rate, and whether that capability exists or has to be built. The 70% target is set. There's no capability architecture underneath it.

The second set is the same pattern from a different angle. "100% staff proficiency within three months" assumes the training capability, change management capacity, and workflow redesign required to achieve it are already in place or trivially assembled. If they aren't, the Key Result is a wish dressed as a goal.

The OKR framework addresses this gap with the stretch goal philosophy: targets set at 60-70% expected achievement, undershoot treated as evidence of appropriate ambition rather than failure. That tolerance for learning isn't wrong on its own. But the variance attributed to "stretch" is often the missing Define and Develop showing up as measurement uncertainty. Calling it ambition doesn't make the absent capability architecture appear. It gives the gap a better name.

If you jump from "improve population health" (Objective) to "reduce wait times by 50%" (Key Result), you haven't just skipped the middle. You may have set a metric that actively misdirects the system. Faster emergency throughput and improving population health can move in opposite directions. The measurement is precise. The theory connecting it to the outcome is absent.

The literature doesn't distinguish between these cases. That's the trap.

What OKR Failure Is Actually Telling You

When OKRs fail, the failure mode is diagnostic. It points to which middle box is missing.

The Rorschach Objective (each team interprets the goal differently, producing Key Results that don't add up to a portfolio): this is the Define problem. The strategic choices haven't been made. Where to Play and How to Win haven't been specified, so each team fills the gap with their own assumptions. The portfolio of OKRs doesn't cohere because there's no shared strategy to cohere around.

Activity-based Key Results (teams set Key Results that are lists of tasks rather than measurable outcomes): this is the Develop problem. When capability hasn't been built, outcome measurement is impossible. The only things you can point to are the activities. Key Results drift toward what's measurable rather than what matters, because the capabilities that would produce meaningful outcomes don't exist yet.

Sandbagging (teams set safe targets to ensure 100% completion): this is both a Define problem and a cultural one. When How to Win hasn't been defined, stretch targets feel arbitrary. If nobody has established the strategic logic that connects this Key Result to the Winning Aspiration, there's no principled basis for accepting the risk of an ambitious target. Sinek is right that psychological safety matters here. But safety alone doesn't solve it. A safe culture with no strategic definition still produces sandbagging, because the targets are genuinely arbitrary, and people sense it.

Green dashboards, unchanged behaviour (every metric is on track; nothing is transforming): this is the full Design4 failure. Discover identified the purpose. Deliver is being measured. Define and Develop were skipped. The organisation is measuring its own activity against an aspiration it has no structural path to reach.

Not every OKR failure is a Missing Middle failure, and it's worth ruling out the exceptions. Sometimes the middle is sound and the metric itself is the problem: a Key Result that invites gaming, so Goodhart's law arrives on schedule, or a cascade pushed so deep that the link to the aspiration is real but too dilute to feel. Those are worth checking, and they are easy to tell apart from the structural case. Fix the metric, and behaviour changes. When fixing the metric changes nothing, then the box underneath it was empty.

Related: Strategy to Execution: How to Close the Gap: the four points where the chain from purpose to outcomes breaks, and what closing each gap requires.

The Business Architect's Role

The business architect holds Develop outright, and makes Define rigorous.

That's a claim about position, not authority. Define, the strategic choice itself, belongs to leadership; nobody else can make it. But it can't be made well without an honest account of what the organisation can actually do, and that account is the architect's. The business architect maintains the capability architecture continuously: the model of what the organisation can and cannot do, what capabilities exist, what their current maturity is, and what the gap is between present state and what the chosen "How to Win" requires. When leadership descends the cascade to the capability question, the business architect is the only credible source of answers, and a Define made without those answers is aspiration, not the strategy it claims to be.

This is the design authority role. The hospital architect holds the blueprints. Questions about what can be added, what the delta is between current state and intended state, what a proposed change would cost the structure: none of those can be answered without the person who holds the plans. The business architect who maintains the capability architecture continuously holds the organisational equivalent. The cascade question (what can we actually build, and how far are we from being able to?) is unanswerable without them.

The practical implication for OKRs is specific. Before Key Results can be set, two questions have to be answered: what is the strategic definition of this Objective (Define), and what capabilities does achieving it require (Develop)? Without answers to both, Key Results are chosen by intuition or political convenience rather than strategic logic. The OKR becomes a performance rather than a barometer.

The chronic disease management example makes this concrete. Take one objective and key result from the healthcare set above: improve chronic disease management within primary care, with a Key Result of raising the hypertension control rate from 55% to 70%. Watch the two questions get answered, because the answering is the Missing Middle being filled, and it's the whole of the work.

The Define question first: which patients, which model, and explicitly not which? Here is one such theory, stated the way a real one has to be, as a choice that excludes. The population is the patients already diagnosed and in the system but drifting off target, not the general adult population and not the undiagnosed. The model is pharmacist-led medication titration between physician visits, not another awareness campaign. The theory is that most of the uncontrolled fifteen points sit with people who were diagnosed, prescribed, and then left unadjusted, so closing the gap between a prescription and the right dose moves the number faster than anything upstream of it. That is a strategic choice, and a distinctive one: most programs pour their effort upstream, into new diagnoses and awareness campaigns, while this one concentrates scarce clinical attention on the already-diagnosed who have drifted, where the next point of control is cheapest to win. It excludes things. It can be wrong. And it tells you exactly what to build.

Now the Develop question has a shape, because you can trace it as one chain instead of a shopping list. From the drifting patient to the controlled reading: a way to see which diagnosed patients are above target without waiting for their next visit (a register, refreshed from the record); a way to reach them (the pharmacist, with authority to adjust the dose); a way to close the loop (the new dose flowing back to the record, the next reading captured). Those three are enabling capabilities; the flow through them, from drifting patient to controlled reading, is the value stream, and its weakest link caps the whole thing. If the register can't find the drifting patients, the pharmacist has no one to call, and 70% is a wish no matter how good the pharmacist is.

Somewhere inside those fifteen points is a specific person: prescribed a medication months ago, never adjusted because no one was watching the reading between appointments, walking around at a pressure that will put her in an emergency department the dashboard will never connect to the objective it was set to serve. The Key Result named her outcome. The Missing Middle is everything between the objective and her: the choice about who to serve and how, and the value stream that actually reaches her. It's the engine the number can't build for itself. Neither answer appears in the OKR, which is why the Key Result isn't wrong as a metric, only unsupported as a commitment until someone produces them. Set the target without them, and you've measured her, precisely, on her way to the stroke.

The specific model here is illustrative, and a real program would have to check it against its own reality (whether a pharmacist can titrate at all varies by jurisdiction). What transfers is not the pharmacist. It's the move: derive a theory of winning that excludes, then trace the value stream it implies. That move is the business architect's job, and it isn't to set the OKRs. It's to ensure the conditions exist in which OKRs can mean something.

In an organisation where OKRs are already running and the Define and Develop work hasn't been done, the first move isn't to stop the process. It's to ask the two questions that should have been asked before it started. For each Objective: what is the theory of winning (which stakeholders, which market, which explicit choice about where not to compete), and what capability does that theory require? In most organisations, those questions have never been put directly to the people setting the Key Results. Asking them doesn't slow the OKR cycle. It reveals what the OKR cycle has been assuming.

The Governance Choice

The governance choice available to the business architect in an OKR-driven organisation is the same one available everywhere: name the structural problem, frame two real options, take it to the level of leadership that can act on it.

Option one: set OKRs from the current position. The Objective is named, the Key Results chosen, measurement begins. It's expedient and fast, and it fits shed-level problems.

Option two: do the Define and Develop work first. The strategic choices are made explicit and the capability architecture assessed. Key Results are set from a position of strategic clarity rather than aspiration. That path is required for hospital-level problems.

The question for leadership isn't which option is better in principle. It's which option is consistent with the scale and complexity of the change they're trying to make. A business architect who can put that choice on the table, with the capability intelligence to show what the gap is between current state and what option two requires, isn't arguing for a slower process. They're preventing a faster one that produces nothing.

One practical dimension the framing doesn't name: option two rarely means starting fresh. Most organisations asking this question are already mid-cycle. The Define and Develop work doesn't precede the next OKR round; it runs alongside it on a longer rhythm. Capability architecture builds on 18-to-36-month cycles. OKRs run on 90-day ones. And asking Define questions during an active OKR cycle is frequently experienced as obstruction. The framing that makes it land is structural rather than critical: the gap isn't in the Key Result; it's in the absence of a theory of winning above it. That distinction converts a challenge to the team into a governance question for leadership.

Frequently Asked Questions

Not the Framework's Fault

OKRs are not the problem. Grove's framework is precise and honest about what it is: a goal-setting and measurement system. The problem is what organisations ask it to be: a substitute for the strategic choices and capability architecture they haven't built yet.

The implication is direct: every Key Result needs an explicit theory of how the organisation will win in a specific, chosen market. That theory lives in Define. The capability that operationalises it lives in Develop. Without both, the barometer has no system to measure.

Here's the shift, and it's available to you the moment you want it. Read a failed OKR as an implementation problem and the only moves left are to try harder, cascade tighter, review more often. Read it as a diagnostic signal instead, and the same failure tells you which box is empty: no theory of winning above the Key Result, no capability beneath it, or both. That's not a measurement fix. It's a governance question, and governance questions have a structural answer.

You don't need a new title to make that read. You need to be the person who, when the dashboard is green and nothing is moving, asks the two questions the OKR never contained: what is our theory of winning here, and what capability does it require? Ask them, and you stop administering the measurement and start telling the room what it is actually measuring against, or failing to. You become the person who can still see the patient behind the percentage, before the percentage becomes an admission nobody connected to the objective it was set to serve.

That discipline has a name, and OKRs are one door into it: business architecture, the practice of making the strategic choices and building the capability every measurement system assumes you've already done. When the dashboard is green over unchanged behaviour, the instrument on top barely matters. An OKR tracker, a benefits register, a maturity model: the Missing Middle is the same hole underneath all three.

Continue Learning

Pillar pages

• Strategy to Execution: How to Close the Gap: the four gaps where the chain from strategy to outcomes breaks, and what closes each one
• What Is Business Architecture?: the discipline, the models, and how it connects purpose to delivery
• Business Architecture Framework: The Design4 Approach: the four-phase governance cycle: Discover, Define, Develop, Deliver
• The Business Architect: What the Role Is, What It Isn't, and What It's Becoming: the role that holds Define and Develop

Blogs

• What Is an OKR?: the shape of a real OKR, Objective, Key Results, and the Initiative layer nobody names, with three worked examples diagnosed
• OKRs vs KPIs: why they're not alternatives, one instruments the bet and one instruments what already works, and both directions of confusing them
• When Your OKR Is Really a Task List: how to spot an OKR that's really a delivery mandate, and the two moves that put the strategic choice and the capability back
• The Phase Every Management System Skips: OKR Theatre, Measurement Theatre, and Maturity Theatre as one failure in three costumes, none of which does the Define phase
• Outputs Are Not Outcomes: why a Key Result can report a delivered output while the outcome it was for never moves

Case studies

• When the Data Function Can't Prove Its Value: what happens when Develop is skipped: a government health portfolio where the data function was engaged too late to prevent the problems it existed to solve

Courses

• Closing the Strategy-Execution Gap: the foundational course: purpose, strategy, capability, operations, and where each connection breaks
• Building the Common Language: the Define-phase work: standardised models for naming what you see across the portfolio