What is Path dependency? There’s a comforting myth about life: that the longer we’ve done something, the better, and more certain it must be. The process exists because it’s proven. The system endures because it works. The road ahead is simply an extension of the road behind.
That’s path dependency, and it’s one of the quietest, most dangerous forces in decision-making.
Path dependency describes how old choices limit current ones. It’s the tendency of systems, organisations, and even individuals to stick with established routes, not because they’re the best, but because they’ve become the default. Once a certain path is taken, a technology adopted, a policy set, a habit formed, it becomes increasingly difficult to change course, even when evidence suggests we should.
It’s the organisational equivalent of staying in a job you hate because you’ve already spent years in it.
The logic trap
Economists first used the term to explain why some technologies dominate long after better ones appear. The classic example is the QWERTY keyboard: designed in the 19th century to slow typists down and prevent typewriter jams.
More efficient layouts have been invented since, but QWERTY endures because it became standard. Retraining everyone was simply too costly and inconvenient.
In organisations, path dependency often hides behind good intentions. Teams standardise to improve efficiency. Leaders embed processes to ensure consistency. Policies are written to protect against risk. And yet, each layer of certainty becomes a brick in the wall that stops progress.
A council refuses to overhaul a failing programme because “we’ve already invested too much.” A company keeps renewing an outdated contract because “the system’s built around it.” A charity clings to a legacy project because “it’s what funders expect.”
The logic seems sound, don’t waste what you’ve already built. But in truth, those sunk costs are the bars on the cage.
The comfort of the known
Path dependency isn’t just a systems problem; it’s psychological. People like predictability. Familiar paths feel safe, especially when the alternative requires uncertainty or humility.
The danger is that it narrows our field of vision. We stop asking “What’s possible?” and start asking “What fits?”
Innovation gets reduced to marginal gains, to small tweaks rather than transformations. We optimise the existing model instead of questioning whether it’s still the right one.
It’s why many digital transformation projects fail. They automate what already exists rather than redesigning it. Technology becomes a veneer over outdated thinking.
Recognising the signs
Path dependency rarely announces itself. It creeps in through language:
-
“We’ve always done it this way.”
-
“The system won’t let us.”
-
“It’s not perfect, but it works.”
-
“Changing it would open a can of worms.”
If you hear those phrases often, you’re not in a stable organisation: you’re in a static one.
The real danger is that path dependency gives the illusion of progress. Reports get written, targets get met, and activity continues. But underneath, adaptability decays.
Breaking the path
Breaking path dependency doesn’t mean tearing everything up. It means creating the conditions where change isn’t punished and curiosity isn’t treated as rebellion.
There are three practical alternatives: backcasting, option testing, and modular design.
-
Backcasting:
Instead of projecting the present forward, start from the desired future and work backwards. Ask, “If we want to be here in five years, what needs to be true today?” It’s a powerful reversal that shifts focus from continuity to intent.
Councils, charities, and businesses that use this method find that it exposes hidden assumptions and invites creative thinking. It’s not about breaking the path; it’s about seeing beyond it. -
Option testing:
Build low-cost, low-risk experiments that run alongside your existing systems. Think of them as exploratory lanes, places to test new ideas without dismantling the main road. When something works, you fold it in. When it doesn’t, you learn quickly.
Start-ups do this instinctively; larger organisations can too, if they treat experimentation as part of strategy rather than a one-off exercise. -
Modular design:
Structure programmes and processes so they can adapt piece by piece rather than all at once. A modular system is flexible, resilient, and easier to modernise because change happens in sections, not revolutions. It’s the antidote to rigidity. It’s evolution by design.
The humility of progress
The hardest part of escaping path dependency isn’t the mechanics; it’s the mindset. It requires admitting that experience isn’t the same as expertise, and that history is data, not destiny. The best organisations aren’t the ones that get everything right the first time. They’re the ones that know how to let go.
