Your plan isn’t a commitment, even if you’ve made, received, or even extracted one about it. It is a hypothesis with an expected outcome and a date you sincerely hope reality will deliver on.
Chapter 6 moved the lever off the people and onto the conditions they work inside: a behaviour that every deadline punishes will not hold, however hard you push the person. One of the biggest conditions a leader can set is ‘the plan’ itself, so this chapter examines the plan.
🎧 Prefer to listen? This chapter is narrated in my own voice, via ElevenLabs on Spotify, about 25 minutes. Listen on Spotify →
The two poles
Pole A: plan as commitment. Strategy as document. Vision as destination. Decide early; execute against the commitment. Variance reads as failure.
Pole B: plan as hypothesis. Strategy as verb. Set direction; find adjacent possibles. Treat each plan as a hypothesis with an expected outcome. Check what actually happened. Act on the difference. Cross the river by feeling the stones.
Plans are useful. Boards and investors ask for them; contractual commitments need them. My sense is that this is shifting—some boards and investors now prize the responsiveness of a team that can re-plan over the reassurance of a plan that will not move—but the ask still arrives. A team without any plan is a team performing improvisation as a personality trait. The question is what the plan is for, and what the leader does when reality and plan disagree.
Where Pole A is right
When the planning horizon closes before conditions can shift around it, the cost of changing the plan is high, and accountability requires commitment. Some examples: manufacturing the next batch of pharmaceuticals on a stable specification, building the bridge whose engineering has been certified, closing the quarter’s books under a fixed regulatory window, and running the integration cutover whose vendor contracts can’t be moved.
In those domains the plan-as-commitment posture is sound. The variance from plan really is diagnostic and the team’s job is to close the gap. The learning mostly happened during the design phase, and execution comes close to being just execution. Still, close isn’t identical: even the mature line keeps a gap between the procedure and the floor for the unexpected.
Most senior leaders I work with came up through some version of that domain. They learned plan-as-commitment in their twenties and thirties from leaders running it well. What if none of it was wasted? The discipline you built in those years is the discipline that lets your team ship anything at all. The honest thing now isn’t to disown it, but to notice the situations where it has stopped fitting, and to make Pole B available without abandoning Pole A.
Where Pole B is right
When none of the conditions above hold. Most software-permeated work, strategy, and market positioning under technological change. Most product decisions. Most situations where the rate of change in the conditions outside the firm has begun to exceed the rate at which the firm can update its plan from inside.
Mary Poppendieck named the broader pathology “the tyranny of ‘the plan’” and traced the origin of its doctrinal instrument—the PERT chart—to the Polaris submarine programme in the late 1950s. The doctrinal history is worth a quick tangent, because it inverts the version most leaders were taught.
PERT charts weren’t invented because they worked as planning instruments. Poppendieck’s reading of Harvey Sapolsky‘s 1972 history of the Polaris programme is brutally disillusioning. As she tells it, the programme’s own technical officers worked around PERT because they judged it unreliable, and the contractors saw it as worthless; it survived only because it kept the money flowing. William Raborn needed something he could show Congress to keep the programme funded across multiple election cycles. PERT was that something. Poppendieck’s gloss: Raborn used PERT as a façade to keep Congress funding the programme, presenting it as a fail-proof management system that no longer depended on people but on the system itself.
This pattern outlived Polaris. A board asking for a one-to-two-year plan is asking a fair question—can this team deliver?—with the instrument it has been handed. What the board needs is performance and a way to hold uncertainty; what it asks for is the plan, because the plan is the artefact that looks like control. That was Raborn’s discovery, and it still works. Weighting for risk is a CFO’s bread and butter; nobody in that boardroom reads the schedule as a promised return. The damage happens when the plan is received as a commitment: everyone downstream must now act as if the risk were smaller than it is.
What actually made Polaris work was reliable workflow and people who kept control of their own decisions. Levering Smith, the technical director, held the requirements himself, his personal signature on every key interface drawing for the first eight years. (I don’t think this would carry forward to most complex knowledge work these days.) Three contractors competed on each major subsystem—set-based design, running rival designs in parallel, is nobody’s idea of efficient—and the best design won. Technical officers acted on what they were learning in real time, not on what the PERT chart said.
Unfortunately, this façade became literal doctrine. A generation of project-management training—PMI’s included—got built on a planning grammar the original programme never used.
The mechanism the doctrine encodes is simple. Decompose the work, sum the estimates, call the total your schedule, and manage to it. (Reinertsen’s flow economics shows the sum is worse than its parts: independent task variances pool, so a schedule built by adding estimates runs systematically more optimistic than the tasks themselves warrant, and the deterministic total hides the variance that actually governs delivery.) When reality diverges—and by goodness it will—the paradigm reads the gap as an execution problem: escalate, replan, trade scope. Those moves are often locally right. The other reading, that the plan was a hypothesis and the divergence is information, isn’t available in the design, because the org is split into people who plan and people who execute, and in knowledge work that split was never real. Nobody involved in actually doing the work would be surprised by this.
The design—planners who think, executors who comply—is Theory X dressed up as project management. Variance from plan is the signal; conformance is the definition of success; and the harder people try to execute a wrong plan, the less the organisation learns about why it is wrong, because under conformance pressure it isn’t safe to say so.
Mintzberg’s institutional critique
Henry Mintzberg’s The Rise and Fall of Strategic Planning is helpful. Mintzberg spent twenty-five years studying how strategy actually gets made inside large organisations and arrived at a single empirical claim: most strategic planning is post-hoc rationalisation of incremental decisions. The plan documents what the organisation has already begun to do; it doesn’t cause it. The pretence that it did is what damages the organisation’s ability to learn from the decisions it actually made.
Mintzberg’s diagnostic vocabulary is worth knowing. He names three fallacies planners fall into: that the future forecasts cleanly enough to plan against (predetermination), that the strategist can stand outside the work to design it (detachment), that decomposition and procedure can stand in for synthesis (formalisation). They collapse into one line of his I’m growing to love: because analysis isn’t synthesis, planning isn’t strategy.
Mintzberg’s prescription was crafting strategy, the title and argument of his 1987 Harvard Business Review article: strategy-making as a craft, “as different from planning as craft is from mechanization.” His image is the potter at her wheel, shaping clay she knows intimately—”managers are craftsmen and strategy is their clay”—rather than the architect drawing a building from a plan. Strategy emerges from action, and action keeps testing it. Strategies are partly deliberate and partly emergent in every real organisation.
The hindsight problem
Pole A’s confidence in variance-as-failure rests on something the planning literature rarely makes explicit. After the fact, the plan looks reasonable. The plan that “should have worked” is a retrospective construction; hindsight has stripped the live uncertainty out of the historical record. Variance reads cleanly as failure only because the plan reads cleanly as the right plan.
Sidney Dekker, citing Fischhoff’s 1975 work on hindsight, puts the cognitive effect plainly: once you know an outcome, you raise your estimate of how likely it always was, and as a reviewer who knows how the event ended you overstate your own ability to have predicted and prevented it, all without noticing the bias at work. In folk terms: hindsight is 20/20.
The variance from plan that Pole A reads as failure is partly a real signal about execution and partly a hindsight artefact. The Pole B leader can’t eliminate the hindsight bias; nobody can. What you can do is design plans whose variance carries information about the conditions that produced the variance, rather than plans whose variance only carries information about the team’s commitment.
Safe-fail rather than fail-safe
Alicia Juarrero’s Dynamics in Action gives the architectural principle. In complex systems, you can’t design failure out. The system has too many interactions; the conditions are too underspecified; the future is too dependent on local adjustments you can’t anticipate. Juarrero’s own claim is that trying to design fail-safe social systems—legal, educational, penal, or otherwise—that never go wrong is hopeless. The only viable alternative, she argues, is to assemble safe-fail family and social organisations: structures flexible and resilient enough to limit the damage when things go wrong.
The architecture of safe-fail is the architecture Pole B requires. Smaller batches. Faster feedback. Reversible decisions where reversibility is achievable. Multiple parallel small bets instead of one large commitment. Plans whose failure modes were anticipated in the planning, with recovery designed into the architecture rather than punished after the fact. (Chapter 14 takes safe-fail into incident response.)
A plan that ignores this isn’t a more rigorous plan; it is a less honest one.
The validated-learning move
Pole B doesn’t manage to the plan. It manages to the smallest test that resolves the largest risk. Build, measure, learn. The hypothesis at the front. The test in the middle. The learning at the back. This keeps queues short by refusing to over-plan, echoing chapter 4: Larman’s core adaptiveness metric is the share of items in Sprint Planning and product backlog refinement that didn’t exist before the last Sprint Review. A long roadmap is a queue by another name. The further out it reaches, the longer each item waits before it meets reality, and the more of it reality has already invalidated by the time you arrive. Ryo Lu, head of design at Cursor, put the working posture plainly in a 2025 interview: his team doesn’t really keep a roadmap, “because the world is changing faster and faster, there’s new models dropping every day.”
Notice what Cursor dropped and what it kept. The long-horizon roadmap went; the short-horizon plan got denser—specs, acceptance gates, hypotheses about what the next model makes possible—because in agent-driven work the plan is the context the work needs before it can start. The commitment artefact disappeared and the hypothesis stayed, rewritten as fast as the ground moves. If you are mid-flight on an AI re-platforming, this is your situation exactly: model capabilities shift quarterly and yesterday’s build-versus-wait call quietly inverts. A six-quarter AI roadmap is the purest case this chapter names, already invalidated by the time you arrive. That work is Pole B by construction.
The commitment artefact disappeared and the hypothesis stayed, rewritten as fast as the ground moves.
Tracking learning per unit of investment is what makes Pole B legible to a Pole A board. We committed to learn X by date Y at cost Z. Here is what we learned. Here is the next hypothesis the learning produced. The plan-as-hypothesis disposition gets a vocabulary the board can hold without abandoning accountability. The board still gets a number. The metric is now learning rate, not feature count.
How often should the bets fail? Reinertsen’s answer, from information theory, is that a test generates the most information when it fails about half the time; the optimum falls as the cost of failure rises. Research on optimal learning in humans and neural networks converges on roughly 15% error for harder, costlier trials. The band gives a board an honesty check rather than a target: cheap probes should be failing near half the time, big bets nearer one in six or seven. A plan portfolio that never misses in a volatile market is telling you one of two things: the hypotheses were foregone conclusions, or the record is being tidied after the fact. Neither is planning.
The doctrinal voice
Marine Corps doctrine—the Corps’s capstone manual, MCDP-1 Warfighting—names the same posture in language that lands harder than the management version: “We must not strive for certainty before we act, for in so doing we will surrender the initiative and pass up opportunities.” The leader’s job in complex situations is to act on a keen appreciation for the essential factors that make each situation unique, not to execute the plan to specification. As Patton’s maxim has it: a good plan violently executed now is better than a perfect plan executed next week. The plan isn’t the work. The work is the work.
A representative case
Picture a product team with a six-quarter roadmap. The roadmap is published broadly, the artefact of a planning process the executive team has run for eight quarters, and the senior leader’s annual review depends on it being delivered.
By quarter two the roadmap is wrong. The market has moved; the competitive ground has shifted; the whole team knows. They are visibly working around the roadmap, shipping what customers are asking for and postponing what the roadmap demands. The roadmap on the wall becomes a source of stress. Engineers explain quietly that they are working on the right things even though the roadmap says otherwise. The Pole A response is to ask why the roadmap is slipping.
The Pole B move, when it comes, is usually forced from outside: an independent director who says stop measuring roadmap variance; measure learning rate. The team retroactively names the hypotheses each roadmap item had embedded. Many have been disconfirmed since quarter two; the quiet workaround was the right response to the disconfirmation; the roadmap had been stopping the team from naming what they had already learned. The roadmap gives way to a quarterly bet structure. Same team, different relationship with the plan, learning rate visibly higher.
The leader running the original roadmap isn’t stupid. The roadmap was the right artefact for an earlier phase, the planning grammar carried straight over from a context where it worked. The move is to name what that discipline once bought—predictability across a launch, a clean integration, an investor round closed on the strength of the document—and then to name what the situation now requires.
And it gets worse. Remember the utilisation-versus-flow picture from chapter 4. The team defending a wrong roadmap usually defends it by interleaving epics, running several at once to keep everyone busy against the plan. That is the high-utilisation trap laid over a stale plan: the wrong work, pushed slowly, in batches too big for anyone to course-correct. The roadmap doesn’t just point the team the wrong way. It multiplies what the wrong direction costs.
The diagnostic move
Three questions for last Tuesday’s planning meeting. The point isn’t to grade yourself. The point is to notice which pole was running:
Which pole was I claiming? In the meeting, when I described what we were doing, did I describe it as a hypothesis we were testing, or as a commitment we were defending?
Which pole did my response to plan variance show? When the team came in with news that something wasn’t landing the way the plan expected, did I demand the variance be closed, or did I ask what we had learned that the plan hadn’t assumed? If I must make commitments, do I build in enough slack for the unknown, ideally using probabilistic forecasting techniques?
Which pole does this work actually require? If the work is in Cynefin’s Complex domain, the plan was always a hypothesis. The Pole A pretence was costing the organisation the learning. If the work is genuinely Complicated—cause and effect yield to expertise and analysis—with a stable specification, the Pole A response was right.
CTOs and VPEs reading this: the last quarterly roadmap is the artefact to take upstairs, because the commitment-versus-hypothesis split is settled by the accountability language your CEO holds with the board, not by you. Take the roadmap and set beside it the two or three hypotheses it was implicitly testing, rewritten, after the fact, in the format if we do X, we expect to observe Y by date Z. Show which hypotheses were confirmed and which weren’t. The point isn’t to relitigate the quarter; it is to show that the team was learning faster than the roadmap was tracking. A CEO who sees that the variance from plan was in fact validated learning—not execution failure—has the vocabulary to carry that story to the board. That vocabulary shift is what lets your team plan honestly rather than performing commitment. The sentence your CEO can carry to the board: “Our variance from plan was the learning arriving faster than the roadmap could track it.”
Take it up before your next planning cycle locks; the artefact loses its bite once a fresh roadmap replaces it. The signal that it landed: next quarter’s plan ships with its hypotheses attached, and the board’s variance questions shift from “why the slip?” to “what did we learn?”
The exercise
For your next quarterly planning cycle, run a Klein premortem before you lock the plan. Gary Klein’s prescription is straightforward and surprisingly hard to do honestly. Bring the planning team together. Imagine it is months into the future and the plan has failed. That is all anyone knows. Each person writes down, in the next few minutes, every reason they think it failed; the discussion that follows can run an hour. Klein’s claim for the exercise is modest and exact: it breaks the team’s emotional attachment to the plan’s success and surfaces the likely sources of breakdown: the silent assumptions the plan was resting on. His sharpest evidence for why it’s needed: of twenty Army helicopter crews rehearsing a troop drop through a one-minute window between artillery barrages, none asked in rehearsal what to do if they arrived early or late, and one made the window.
Whatever the premortem surfaces then needs a home. A ROAM board is a simple way to give it one: each risk gets sorted as Resolved, Owned, Accepted, or Mitigated, so a named risk either has an owner and a plan or a deliberate decision to live with it. Run it per epic or hold one board across the quarter.
A companion exercise: the hypothesis rewrite. Take your current quarterly plan and rewrite each milestone in the form “if we do X, we expect to observe Y by date Z; the hypothesis is falsified if we observe instead [specific outcome].” Notice which milestones are hard to rewrite. Those are the ones running as Pole A. The Pole B move isn’t to rewrite all of them—some genuinely are commitments—but to know which is which, and to set the team’s relationship to each accordingly.
Going upstream
In-text: the key references named in the body. Henry Mintzberg, The Rise and Fall of Strategic Planning (the canonical primary; Ch 5 is the heart of the critique). Mary Poppendieck, The Tyranny of “The Plan”, InfoQ (60 min): the canonical talk or my transcript; worth the hour for the Polaris story alone. Gary Klein, Sources of Power, on the premortem; the named exercise is set out in Klein’s “Performing a Project Premortem,” HBR 2007.
Also touched: references gestured at by surname in the body. Sidney Dekker, on hindsight bias, citing Baruch Fischhoff, “Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty” (Journal of Experimental Psychology: Human Perception and Performance, 1975). Alicia Juarrero, Dynamics in Action (Ch 15 for fail-safe vs safe-fail). Patton, on the good plan violently executed now. Dave Snowden & Friends, Cynefin: Weaving Sense-Making into the Fabric of Our World, for Pole B’s strategy-as-verb, adjacent-possibles framing (McCrone & Snape on strategy as a verb; Blignaut on crossing the river by feeling the stones).
Go deeper: further reading that extends the threads above, beyond what the body anchors. On the hindsight artefact, Dekker quotes Anthony Hidden’s 1989 Clapham Junction report: “There is almost no human action or decision that cannot be made to look flawed and less sensible in the misleading light of hindsight.” On safe-fail at the system level, Richard Cook, How Complex Systems Fail (point 5: complex systems run in degraded mode; point 14: change introduces new failure modes). On the operational unit of management, Eric Ries, The Lean Startup: validated learning, vanity versus actionable metrics, innovation accounting. On the optimum failure rate, Don Reinertsen’s Principle of Optimum Failure Rate, in The Principles of Product Development Flow (fifty percent for cheap tests, falling as the cost of failure rises); for the 15% end, Robert Wilson and colleagues, “The Eighty Five Percent Rule for Optimal Learning” (Nature Communications, 2019). On the doctrinal voice, USMC, MCDP-1 Warfighting (Ch 4; official PDF), which reached this posture through Boyd’s fighter-pilot air-combat analysis: “We must not attempt to impose precise order on the events of combat since this leads to a formularistic approach to war.” “Maneuver warfare exists not so much in the specific methods used—we don’t believe in a formularistic approach to war—but in the mind of the Marine.” Further reading: Mary and Tom Poppendieck, Lean Software Development and Leading Lean Software Development (Frame 13: schedule as plan vs schedule as hypothesis, via Steven Spear’s Chasing the Rabbit); Mike Rother, Toyota Kata, on PDCA as hypothesis-testing.
A plan held as a hypothesis has to be tested somewhere, and the improvement plan you just signed off tests everywhere at once. Goldratt compressed the failure into one line operations management has spent decades trying to unsay. A system of local optimums is not an optimum system at all; it is a very inefficient system. That is the plan you built, and it breaks wherever functions share a constraint, which covers most systems a leader ever meets. Chapter 8 works through the rule. Improving a non-constraint changes nothing.
Leave A Comment