If you want to see how deep our faith in planning goes, think back to the last big change you led.
You probably had a version of the same artefact: a neat roadmap, phases, dates, dependencies. You stood in front of a room, walked people through the milestones, and for a moment you could feel the future snap into order. Boxes, arrows, colours. It felt like control.
Now replay what actually happened.
Did reality move neatly from Phase One to Phase Two to Phase Three? Or did it lurch, loop back, stall, speed up in odd places, and get ambushed by things no one saw coming?
Most large change work lives in that second world. The problem is that we keep designing it for the first.
The Comfort of Pretending It Is Predictable
We are very fond of the idea that the future can be tamed by detail.
If we just break the change into enough steps, write enough workstreams, put enough dates into enough boxes, we will be safe. We will know where we are. We will not get in trouble for being surprised.
Underneath is a very human bias. Psychologists call one version of it the planning fallacy: our tendency to be overly optimistic about how long things will take, how much they will cost, and how smoothly they will go—even when we have been wrong many times before.
We build the plan, feel better, and quietly forget that the plan is not reality. It is a story we are telling ourselves about how reality might go if it behaves.
If you put your last three major change plans next to how those changes actually unfolded, how much of your planning was insight, and how much was wishful thinking?
Complicated Versus Complex (and Why It Matters)
Part of the problem is that we do not distinguish between two very different kinds of difficulty: complicated and complex.
A complicated problem is like building a plane. It is hard, but knowable. If you have enough expertise and follow the right steps, you can predict the outcome reasonably well.
A complex problem is more like raising a teenager. There are patterns, but no guarantees. Your actions change the system as you go. You can influence, but you cannot script.
Dave Snowden's Cynefin framework makes this distinction explicit. In the complicated domain, the logic is:
sense → analyse → plan → execute
In the complex domain, the logic is different:
probe → sense → respond
You do not start with the master plan. You start with small, deliberate probes into the system, see how it reacts, and adjust accordingly.
Most big organisational changes—culture shifts, operating model changes, digital transformation, strategy resets—live firmly in the complex domain. But we keep treating them like complicated engineering projects.
So we write a Gantt chart for raising a teenager, and then act surprised when they do not follow it.
Safe to Fail, Not Fail at Scale
If change is complex, you do not actually want one big, beautiful solution. You want lots of small, ugly experiments.
Snowden calls these safe-to-fail probes:
- Small enough that, if they do not work, the harm is contained
- Different enough from each other that you are not betting everything on one idea
- Designed to teach you something about the system, not just to tick a delivery box
That is very different from the way "fail fast" is often used in corporate life.
"Fail fast" gets interpreted as "push things out quickly, then blame the team when it does not work". There is nothing safe about the failure and nothing learned from it except "stick your neck out less next time".
Safe-to-fail experiments are humbler. They say:
"We do not know for sure how this change will land here, so we will try a few different approaches in a few different places and watch closely."
Look at the biggest change you are driving right now. What, if anything, would count as a genuinely safe-to-fail experiment in that space—something you could try in the next month that would teach you a lot and not break anything important if it flopped?
If the honest answer is "nothing, we are all in", that tells you something uncomfortable about how you are currently holding complexity.
Technical Work Versus Adaptive Work
Ron Heifetz makes another useful distinction: technical versus adaptive challenges.
Technical challenges can be solved with existing expertise and processes. You might need a new system or policy, but people's underlying values, habits and identities stay roughly the same.
Adaptive challenges require people themselves to change—how they think about their role, how they share power, what they are willing to let go of.
Most transformation work is sold as technical ("this is just an implementation problem") but is actually adaptive. You can write a technically perfect plan for a new structure. You cannot project-plan your way through the emotional reality of people losing status, changing identity, or sharing authority they never had to share before.
In that sense, the detailed roadmap can become part of the avoidance. It keeps everyone busy with tasks while the adaptive work—the conversations about loss, identity, power—quietly goes undone.
Probing, rather than pretending, drags that layer into view. You cannot ignore people's responses because you are explicitly using those responses as data.
What Probing Looks Like in Real Life
If you strip away the labels, probing is not exotic. It is simply honest curiosity with guardrails.
A team that has stopped pretending its roadmap is reality might sound more like this:
"We have a hypothesis that moving to cross-functional squads will speed decision-making and make work more satisfying. We do not know if that is true here. So we are going to set up two squads for three months, agree some measures—decision time, rework, stress—and see what happens. If it helps, we will expand it. If it hurts, we will stop and look at why."
That is very different from:
"We are moving to squads. Here is the nine-month implementation plan. Green by Q4."
On paper, the second version looks more decisive. In reality, the first is more likely to get you somewhere worth being, because it is designed to be changed by what you learn.
I have sat in rooms where everyone knew the roadmap was fiction by Month Four, but no one wanted to be the first to say it out loud. So we coloured a few boxes amber, adjusted some dates, and carried on. We did not have a complex change. We had a very expensive pretence.
Why Detailed Plans Are Still So Seductive
If we know all this, why do we keep falling for the big plan?
Partly because plans are a socially acceptable way to manage our own anxiety. A wall of milestones is easier to show a board or a Minister than a slide that says, "We do not fully know yet. Here is how we are going to learn."
Partly because plans give us people to blame. If the roadmap was perfect and things still went wrong, it must be because "execution failed" somewhere down the line.
Probing does not let you off that easily. When you probe, you are admitting that you are part of a living system that will surprise you, and that your job is to stay in relationship with that surprise instead of pretending it is not there.
That takes more humility than many leadership cultures reward.
Which feels more uncomfortable for you personally: presenting a neat roadmap you do not fully believe in, or walking into the room with a smaller set of honest probes and the assumptions you are testing?
Your answer to that question is quietly running a lot of your change strategy.
Probing as a Leadership Habit
None of this means abandoning planning. It means shrinking the part of the future you pretend to know and enlarging the part you are willing to explore.
The stance is simple to describe:
- Be explicit about direction and intent
- Be honest about your assumptions
- Design small bets to test those assumptions
- Be willing to let what you learn change your mind
It is less dramatic than unveiling a grand roadmap. It is also less likely to leave you stuck defending Month Eighteen of a plan you stopped believing in at Month Three.
The place to build this habit is your real work.
Not a case study. An actual change you are leading—a restructure, a product shift, a policy change. Map the parts you are treating as complicated but that behave like complex systems. Surface the assumptions you are quietly betting on. Then design two or three safe-to-fail probes you could run in the next few weeks to learn faster with less collateral damage.
The shift sounds small and feels big:
From "How do I plan this so it works?" to "How do we learn our way into a version that works here, with these people, in this context?"
Plans still matter. They just stop being fiction you cling to and become hypotheses you are willing to test.
When you stop treating complexity like an engineering problem and start treating it like an exploration, change stops being an exercise in holding your breath and hoping.
It becomes what it always was underneath: a long series of probes into an unknown future, and a willingness to be changed by what you find.
