Three Horizons and the Ambidextrous Organization: Where New Bets Should Live

If the last post landed, you now believe something uncomfortable: your company kills promising new ideas not because it’s stupid but because it’s well-run — the resource allocation process, the metrics, the values about what a “good” margin looks like are all doing their jobs, and their job is to starve anything that doesn’t resemble the core. Which raises the obvious structural question: if the core organization will rationally kill the new thing, where do you put the new thing?

Two frameworks dominate every executive conversation on this question, and have for twenty-plus years: McKinsey’s Three Horizons and O’Reilly and Tushman’s ambidextrous organization. They’re usually presented as interchangeable slideware — a triptych of curves, a box off to the side of the org chart. They’re not interchangeable. One is a tool for allocating attention across a portfolio; the other is a tested claim about structure, with an actual success-rate distribution behind it. Both are genuinely useful. Both have a dominant corrupted reading that produces the opposite of what their authors intended. Taking each seriously — including where it breaks — is the fastest way I know to have a real conversation about where a bet should live.

What Three Horizons actually says

The framework comes from Mehrdad Baghai, Steve Coley, and David White’s The Alchemy of Growth (1999), built on McKinsey research into companies that sustained growth over long periods. The finding behind it is simple and still underrated: the companies that kept growing weren’t the ones that periodically lurched from one business to the next. They were the ones managing three kinds of business simultaneously — and managing them differently.

Horizon 1 is the core: the businesses that generate today’s cash and profit. The management job is defending and extending them — efficiency, incremental improvement, margin discipline. Horizon 2 is emerging businesses: ventures that have found real customers and real revenue and are scaling toward materiality, consuming investment along the way. Horizon 3 is options: seeds, experiments, research bets, minority stakes — most of which will die, a few of which become the H2 businesses of the future.

The load-bearing part of the book — the part the slide never shows — is that each horizon needs different metrics, different people, and different funding logic. Judge an H3 seed on this quarter’s ROI and you’ll kill it, correctly, by H1 rules. Staff an H2 scale-up with operators whose whole career is H1 cost discipline and they’ll optimize it into a niche. Fund H3 through the annual budget cycle and it’ll be the first line cut in a bad quarter. The framework, read as its authors wrote it, is a defense mechanism against exactly the rational killing machine from part one: it gives leadership a vocabulary for saying “this bet is not allowed to be judged by core-business rules, on purpose, and here’s which rules apply instead.”

That reading — concurrent portfolios, differentiated management — holds up fine today. It’s the other reading that rotted.

How the horizons got corrupted into a timeline

Somewhere between 1999 and every strategy offsite I’ve attended, the horizons stopped being portfolio categories and became a schedule. H1 is now, H2 is two-to-three years out, H3 is five-to-ten. Drawn that way, the framework quietly transforms into a delivery roadmap: the transformative stuff lives comfortably in the distant future, which means nobody has to fund it seriously now, and — the truly corrosive part — anything transformative is assumed to be slow. I’ve watched teams park an idea in “H3” as a polite way of killing it. The horizon label became a drawer.

Steve Blank called time on this in a 2019 Harvard Business Review piece with a title that does the work: “McKinsey’s Three Horizons Model Defeated Its Own Purpose.” His argument: the time-based reading assumed disruptive innovation required long development cycles — new technology, new science, years of gestation. That assumption died. Most modern disruption is existing technology recombined at speed: commodity cloud, off-the-shelf hardware, app-store distribution, new business models on old rails. Blank’s examples are attackers who shipped what incumbents had filed under “horizon three” on H1 timescales — startups assembling available components and reaching customers in months, not decades. A competitor doesn’t respect your horizon map. If your planning assumes transformative-equals-distant, you will be leisurely incubating precisely the thing someone else ships this year — a warning I’ve made before in the innovation-lab post, and it bears repeating because executives reach for this framework constantly.

So here’s my scorecard on Three Horizons: it survives as a portfolio-attention tool and dies as a timeline. Keep the discipline of asking, every planning cycle, “how much of our money, our best people, and our leadership attention is on each horizon, and are we judging each by the right rules?” Most companies that run that audit honestly find 95%+ of everything on H1, which is the real diagnostic value. But strike the years off the axis. A horizon describes how unfamiliar a bet is to your current business — its distance from your processes and profit model — not how far away its payoff is in time. Unfamiliar and fast is now the normal case.

Notice, though, what Three Horizons doesn’t tell you: it says manage the horizons differently but is nearly silent on the organizational mechanics of doing so inside one company. For that you need the second framework.

Ambidexterity: the structure question, with actual evidence

Charles O’Reilly and Michael Tushman’s 2004 HBR article “The Ambidextrous Organization” is the rare framework paper with a scoreboard attached. They followed 35 attempts at breakthrough innovation across different structural arrangements, and the success-rate distribution is brutal: roughly a quarter for projects embedded in the existing functional organization, approximately zero for unsupported skunkworks-style teams cut loose from the hierarchy, and over 90% for the ambidextrous design — a structurally separate unit, with its own processes, metrics, and culture, integrated with the parent at the executive level. I’ve walked through that study in detail in the lab post, including how it kills the two most popular lab designs simultaneously, so I won’t re-derive it here. What I want to spend this post’s depth on is the part everyone skips: why the executive integration is the active ingredient, and what it looks like when someone actually builds it.

The intellectual root is James March’s 1991 paper on organizational learning, which named the tension as exploration versus exploitation. Exploitation — refining what you already know how to do — has returns that are near, fast, and predictable. Exploration has returns that are distant, uncertain, and often negative. March’s punchline is that any adaptive system will, left alone, drift toward exploitation, because its feedback loops reward it faster — and that this drift is self-destructive in the long run, because today’s exploitation was yesterday’s exploration. This is part one’s killing machine stated as learning theory: the bias against new bets isn’t a cultural flaw you can workshop away; it’s the default dynamics of any organization that learns from its own results. Which is why the answer has to be structural. You cannot ask one team, one metric set, or one middle manager to hold both logics; the exploit logic wins on every tie-break. You have to host both logics in separate structures and resolve the conflict between them somewhere that can afford to.

And that somewhere is the hinge of the whole framework: a senior leader who owns both. Not a liaison, not a steering committee, not a dotted line — an executive whose compensation and identity are tied to the health of the core and the success of the explore unit, senior enough to force resource transfers the core would never volunteer and to shield the new unit when a bad quarter makes it a tempting cut. O’Reilly and Tushman are explicit that ambidexterity is ultimately a leadership capability wearing a structural costume: the separate unit is necessary, but it’s the integrating executive who makes separation survivable. Every failed lab in the graveyard I’ve walked before was missing exactly this wire. Separation is easy — companies love announcing new units. Paying a real executive to genuinely own both sides of March’s tension is the part that almost never happens.

IBM’s EBO program: the canonical worked example

The best documented case of ambidexterity built deliberately, at scale, is IBM’s Emerging Business Opportunities program. The origin story is instructive: in 1999, Lou Gerstner read an internal report on why IBM — with one of the world’s great research labs — kept inventing technologies that others commercialized, and reportedly demanded to know why IBM consistently missed emerging waves. The internal post-mortem found the same structural culprits part one predicted: promising businesses starved because they were managed by the same processes, judged by the same metrics, and funded from the same budgets as mature ones. Gerstner’s response, built out with strategy head Bruce Harreld and studied closely by O’Reilly and Tushman themselves, was the EBO system.

The mechanics are worth listing because each one maps to a failure mode. Each EBO got a dedicated, senior leader — and pointedly not a junior high-potential but proven executives, sometimes people who had run multi-billion-dollar units, assigned full-time to a business with almost no revenue, which sent an unmistakable signal about what the company valued. Each got protected funding held at the corporate level, outside business-unit budgets, so a division having a bad quarter couldn’t raid it. Each was reviewed monthly by top corporate leadership — Harreld’s team personally — against milestones about learning and market validation, not near-term revenue: the graduation criteria were things like “proved the customer problem” and “found a repeatable sales motion,” not hitting a number. And graduation was explicit: an EBO that matured got handed to a business unit with a transition plan, and one that failed its milestones got shut down without careers ending.

It worked. Across the early 2000s the program incubated a couple dozen ventures — Life Sciences, Linux, pervasive computing, blade servers, digital media among them — and the businesses it graduated added billions of dollars in new annual revenue, with EBO-originated businesses contributing more to IBM’s growth in that period than acquisitions did. For a few years, IBM was the standing counterexample to “big companies can’t do new things.”

Then it decayed, and the decay is as instructive as the success. The people who built and personally ran the system — Gerstner, then Harreld — moved on. The monthly senior reviews, the program’s actual engine, became less senior and less frequent. Ownership of the process devolved toward the business units, which is to say back inside the exploit machinery the program existed to escape. The EBO label persisted after the executive attention that gave it meaning had gone. The lesson isn’t that ambidexterity doesn’t last; it’s that ambidexterity is a practice sustained by specific senior people, not an org-chart feature you install once. The hinge of the framework is a leader who owns both — and hinges need maintenance.

So where should this bet live?

Frameworks earn their keep at the moment of decision, so here’s the working checklist I use when someone asks whether a new bet belongs inside a business unit or in a separate structure. It’s essentially Christensen’s RPV test from part one turned into questions.

Process fit: can the core’s existing processes — how it develops, sells, supports, and plans — execute this without mangling it? A faster database sold to the same buyers through the same sales motion fits; keep it inside. A subscription product inside a perpetual-license company does not, and the mismatch shows up everywhere from comp plans to revenue recognition.

Values fit: will this bet’s economics survive the core’s prioritization filters? If the core clears 60% gross margins and the new thing starts at 20, every quarterly review is an execution — not from malice, but because the resource allocation process is comparing it against better-looking alternatives, exactly as designed. Margin structure, deal size, and sales cycle are the values that kill quietly.

Metric contamination: what happens when this shows up on a shared dashboard? A venture that should be measured on validated learning, reviewed on EBO-style milestones, will be measured on revenue per head the moment it lives in a spreadsheet next to businesses that are. If you can’t give the bet its own scoreboard, you haven’t given it its own structure.

The shared-sales-force trap: the most seductive integration argument is “we’ll leverage our existing channel.” Beware. A commissioned sales force rationally sells whatever maximizes commission per hour, which is the mature product with the proven pitch, and your new bet becomes slide 47 of a deck nobody reaches. Sharing a sales force with the core is very often the decision that decides everything else.

If a bet fails two or more of these, it needs the ambidextrous treatment: separate team, separate metrics, executive sponsor who owns both. Amazon’s practice is the cleanest public illustration. Kindle wasn’t developed inside the thriving physical-books organization; Bezos pulled Steve Kessel out of running that business to build the thing that would cannibalize it, with a mandate he’s described in terms of proceeding as if the goal were to put the physical-books business out of business — an explicit instruction to kill your own core before someone else does. AWS likewise grew as its own organization under Andy Jassy, with its own economics, culture, and leadership, rather than as an initiative inside retail — a business whose margins and rhythms would have made infrastructure investment look insane on any shared dashboard. Note that both cases had the full wiring: real separation and integration at the very top, since Bezos personally owned both sides of each tension. Separation with an S-team-level sponsor is ambidexterity; separation with a hopeful VP is a skunkworks, and the 2004 study told you the success rate of those.

Separation is necessary. It is nowhere near sufficient.

Here’s where I have to disappoint anyone hoping the org chart is the answer. Three Horizons tells you to hold a portfolio and judge each part by its own rules. Ambidexterity tells you where the unfamiliar bets should sit and what wiring keeps them alive. Neither tells you what happens inside the separate unit — and a protected, well-sponsored unit that doesn’t know how to turn hunches into evidence is just a more expensive way to fail slowly. IBM’s EBOs worked because of what happened in those monthly reviews, not because of the box on the chart.

So the structure is the beginning, not the end. The separated unit has to be run as a school, not a showroom — a place where people practice the craft of de-risking ideas and the learning has somewhere to go. It has to be staffed by people who can actually do intrapreneurship, which is a rarer and more trainable skill than the job postings suggest. And it has to be funded the way IBM funded EBOs — on evidence and milestones rather than annual budgets, because a separate unit funded by the ordinary planning cycle is just the core’s killing machine with a delay timer. Those are the next three posts. The box is drawn; now we have to fill it.

Further reading

• Mehrdad Baghai, Steve Coley & David White, The Alchemy of Growth (1999) — the original Three Horizons text; notice how much of it is about differentiated management and how little about timelines.
• Steve Blank, “McKinsey’s Three Horizons Model Defeated Its Own Purpose,” Harvard Business Review (2019) — the definitive takedown of the time-based reading.
• Charles O’Reilly & Michael Tushman, “The Ambidextrous Organization,” Harvard Business Review (2004) — the 35-project study; their later book Lead and Disrupt covers the IBM EBO case in depth.
• James March, “Exploration and Exploitation in Organizational Learning,” Organization Science (1991) — the theoretical root of the whole explore/exploit vocabulary; harder going, worth it.