A podcast companion to this article.
In 1871, Field Marshal Helmuth von Moltke the Elder wrote that no plan of operations extends with any certainty beyond the first encounter with the enemy's main body. He wasn't arguing against planning. He was arguing against a specific kind of confidence: the belief that a sufficiently detailed plan, executed with enough discipline, can substitute for judgment once reality starts talking back. That distinction, between planning as preparation and planning as prophecy, matters more to a hospital system, a software company, or a professional services firm today than it did on a nineteenth-century battlefield, because the condition that made Moltke's battlefield unpredictable, complexity, has become the default operating condition almost everywhere else too.
General Stanley McChrystal ran into the modern version of this problem in 2003, when he took command of the Joint Special Operations Task Force fighting Al Qaeda in Iraq. His organization was, by any conventional measure, the most capable force ever assembled: the best training, the best technology, the best people, organized under a command structure refined over a century of industrial-age warfare. It was losing. Al Qaeda in Iraq had none of those advantages. What it had was speed: a decentralized network of small, semi-autonomous cells that could sense a change in the environment and adapt to it faster than McChrystal's task force could move a decision through its own chain of command. McChrystal, together with Tantum Collins, David Silverman, and Chris Fussell, turned that experience into Team of Teams: New Rules of Engagement for a Complex World, and the book's central argument is worth taking seriously well outside a war zone. The task force wasn't losing because its plans were bad. It was losing because it was organized to execute plans well in a world that had stopped holding still long enough for any plan to stay accurate.
Complicated Is Not Complex
The distinction McChrystal draws is between complicated systems and complex ones, and it's easy to blur the two because both feel hard to manage. A complicated system, a jet engine, a supply chain with a thousand parts, a hospital's billing process, has a great many moving pieces, but the pieces interact in predictable, mostly linear ways. Master the parts and their relationships, and you can plan your way through it with real confidence. A complex system, a market, an insurgency, a large organization under stress, is different in kind, not just in degree. Its parts are interdependent in ways that produce emergent behavior: small changes cascade unpredictably, the same input doesn't reliably produce the same output twice, and the system itself shifts in response to your attempts to plan for it. You cannot out-plan a complex system the way you can out-plan a complicated one, because the thing you're planning against won't hold still long enough to be planned against. This is the shared consciousness problem McChrystal describes at the center of the book: what an organization now needs to know has grown even faster than its capacity to know it. That is precisely the condition under which a perfect plan stops being an asset and starts being a liability. The more precisely it was built for yesterday's conditions, the more confidently it will misdirect you today.
From Chess Master to Gardener
McChrystal's answer wasn't to plan harder or centralize control more tightly, the instinct that fails most often under real complexity. It was to change what the organization was built to do. His task force rebuilt itself around two capabilities the book calls shared consciousness and empowered execution. Shared consciousness meant every team, not just command, had access to the same operational picture and the same lateral relationships across teams that used to talk only through the hierarchy. Empowered execution meant decision rights moved down to whoever was closest to the information, because by the time a decision worked its way up the chain and back down, the situation it was meant to address had already changed. McChrystal describes the resulting shift as a leader moving from chess master, someone who tries to foresee every move and control every piece, to gardener, someone who builds the conditions for the system to grow and adapt on its own. Neither role is passive. A gardener still sets the boundaries, prepares the soil, and removes what's choking the rest of the garden. What a gardener doesn't do is pretend to control exactly how each plant grows, because that control was never actually available, not in a garden and not in a task force chasing a network that reorganized itself every time it took a hit.
Learning Speed Is the New Execution Fidelity
This is where the argument stops being a war story and starts being a management principle. In a complicated environment, competitive advantage comes from execution fidelity: build the best plan, then run it with precision and discipline. In a complex environment, competitive advantage comes from something else entirely: the rate at which the organization can learn what's actually true and adjust before the gap between plan and reality gets expensive. Rita Gunther McGrath, whose own research sits squarely in this territory, has put it about as plainly as it can be put:
“The only plan is to learn as you go.”
That's not a rejection of planning. It's a rejection of the idea that a plan's value lies in how completely it was specified in advance, rather than in how quickly it can absorb what you learn once you start moving. The organizations that struggle most with complexity usually don't have bad plans. They have good plans they keep defending past the point where the evidence has stopped supporting them, because the plan was never built to be updated, only executed.
A Practical Framework: Discovery-Driven Planning Meets Agile
If the discipline that matters is learning speed rather than execution fidelity, leaders need two things working together, not one clever framework doing all the work alone. The first is a way to structure big, uncertain bets so the assumptions underneath them get named and tested before too much capital and credibility are committed. The second is a way to structure the actual weekly work of teams so learning happens at the pace complexity demands, rather than in a single review six months after the money is already spent. The first is Discovery-Driven Planning, developed by Rita Gunther McGrath and Ian C. MacMillan and first published in Harvard Business Review in 1995. The second is Agile, formalized in 2001 by seventeen software practitioners, among them Kent Beck, Ward Cunningham, Martin Fowler, Ken Schwaber, and Jeff Sutherland. Neither was written with the other in mind, and neither is sufficient alone. Discovery-Driven Planning without a fast operating cadence produces a smart plan nobody tests quickly enough for the plan to matter. Agile without a discipline for naming and pressure-testing the underlying bet produces fast execution in a direction nobody has actually validated. Put together, they give a leader both halves of what McChrystal's task force had to rebuild from scratch: a structured way to know what you're betting on, and an operating rhythm fast enough to find out if you're right.
I've applied this same pairing narrowly, to corporate AI adoption specifically, elsewhere: see From "AI Everywhere" to Discovery-Driven Strategy. What follows here is the general-purpose version, three layers that apply to any uncertain bet, not just an AI one.
Layer One: Name the Bet Before You Fund It
McGrath and MacMillan's original insight was that conventional planning quietly assumes what it should be testing. A standard business case starts from a base-case forecast and works forward, which means every assumption embedded in that forecast, market size, adoption rate, cost to serve, gets treated as a fact the moment it's typed into a spreadsheet. Discovery-Driven Planning inverts the sequence. It starts with a reverse income statement: define the outcome the venture must produce to be worth doing, then work backward to what would have to be true operationally and financially to get there. From that, it builds an explicit assumptions checklist, ranking every assumption by how much the entire outcome depends on it being right, so the team knows exactly which beliefs, if wrong, sink the whole bet. Those assumptions then attach to milestones, and this is the detail leaders skip most often: a milestone in Discovery-Driven Planning isn't a progress checkpoint, it's a decision point. At each one, the real question isn't "are we on schedule," it's "has what we've learned so far actually confirmed the assumptions this bet depends on, and if not, do we pivot or stop." Named clearly, in writing, before the money moves, an assumption is something a team can test. Left implicit, it's just a hope the organization discovers was wrong only after it became expensive.
Layer Two: Learn at the Speed the Work Requires
A milestone eighteen months out only produces useful information if the eighteen months of work leading up to it were structured to surface evidence early rather than late. That's the problem Agile was built to solve, even though it emerged from software teams working through a narrower version of it. Its founding document opens with a values statement that reads, almost word for word, as a rejection of the same overconfidence McChrystal ran into: responding to change over following a plan, individuals and interactions over rigid process, working output over comprehensive documentation. The twelve principles underneath those values translate directly into how a Discovery-Driven bet should actually be run day to day: deliver something real early and often rather than saving the first true test for the end, welcome new information even when it disrupts what was already planned, and build in a fixed, recurring habit of stepping back to ask what's actually working and adjust course, rather than waiting for a formal review to grant permission to change anything.
For someone who has never worked inside it, Agile is easier to picture as a handful of concrete habits than as a philosophy. Teams work in sprints, fixed, short cycles, usually two to four weeks long, at the end of which the team has produced something real and usable, not a status update about something real and usable. The backlog is the prioritized list of what the team could build next, ranked by what matters most to learn or deliver right now rather than locked into a sequence someone decided months earlier. A brief daily stand-up, typically ten or fifteen minutes, exists for one purpose: surface anything blocking the work today, while it's still cheap to fix, instead of discovering it at the end of the sprint. The sprint review is where the team shows what it actually built to whoever has a stake in it, a real demonstration rather than a slide deck describing progress. And the retrospective, held after every sprint, is where the team steps back and asks what's working, what isn't, and what to change before the next cycle starts, a habit most organizations otherwise reserve for post-mortems held after something has already gone wrong.
Line these habits up against Discovery-Driven Planning and the fit is direct, not metaphorical. The backlog is where the assumptions checklist turns into actual work: the next sprint should be built to test whichever assumption the team is least certain about and most exposed to, not whichever task happens to be easiest to schedule. The sprint review is where evidence for a milestone gets generated in small doses throughout the cycle, rather than manufactured all at once under deadline pressure, which means that by the time a formal milestone decision arrives, it's confirming or disconfirming something the team already has real data on, not guessing under pressure for the first time. And the retrospective is the team-level version of the pivot-or-persevere question Discovery-Driven Planning asks at every milestone, just run at a cadence of weeks instead of quarters, so a bad assumption gets caught in the sprint that revealed it instead of the milestone that finally forces someone to admit it.
Layer Three: Make the Learning Visible, and the Authority Real
Neither layer works if it's confined to a project lead's private dashboard, and this is where McChrystal's two capabilities earn their place in a framework that otherwise has nothing to do with the military. Shared consciousness means the assumptions checklist, the milestone results, and each cycle's real output are visible to everyone whose work depends on them, not compiled quarterly into a summary for people who weren't close enough to the work to catch the early signal. Empowered execution means the team running each cycle has standing authority to adjust the next one based on what it just learned, inside guardrails leadership has set in advance, rather than waiting for that authority to be re-granted at every checkpoint. Guardrails still matter here exactly as they do anywhere else delegation happens: a budget ceiling, a defined boundary on scope, a clear line for what needs sign-off and what doesn't. What guardrails are not is a plan the team must defend unchanged. They're the space inside which the team is free to be wrong quickly, learn from it, and adjust, which is the entire point of running Discovery-Driven Planning and Agile together instead of running either one alone.
None of this is an argument against planning, and treating it that way is the most common way this idea gets misapplied. McChrystal's task force didn't win by abandoning structure; it won by building a different kind of structure, one designed to update itself as fast as the enemy could change. Discovery-Driven Planning and Agile are how that same design principle gets built into an organization that will never fire a shot: name what you're actually betting on, build in a rhythm fast enough to find out whether you're right, and give the people closest to the evidence enough real authority to act on it.
The Point
The plan was never the point. What was always the point, in a war zone or a boardroom, is whether the organization can learn faster than the complexity around it is changing.
Sources: McChrystal, S., Collins, T., Silverman, D., & Fussell, C. (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio/Penguin. · McChrystal, S. (2014). The Military Case for Sharing Knowledge [TED Talk]. · McGrath, R. G., & MacMillan, I. C. (1995). Discovery-Driven Planning. Harvard Business Review, July–August. · Beck, K., Cunningham, W., Fowler, M., Schwaber, K., Sutherland, J., et al. (2001). Manifesto for Agile Software Development and its Twelve Principles.