John Gall was a paediatrician. Not an obvious source of management wisdom. But in 1975 he wrote something about complex systems that should be required reading for every executive who has ever approved a transformation roadmap.
Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work.”
You cannot design your way to complexity. You can only grow into it.
What This Means for Transformation
Every large transformation programme I have seen starts from the same premise: we need to redesign how we work — at scale, comprehensively — to achieve the outcomes we want. The ambition is right. The approach is almost always wrong.
The systems you are trying to replace are working. Imperfectly, inefficiently, in ways that frustrate everyone who looks at them — but working. They are working because they evolved. Over years and iterations, they accumulated the edge-case handling, the informal workarounds, the tacit knowledge that nobody ever wrote down but that keeps things from falling apart. The spreadsheet that should have been replaced five years ago is still running because it has thirty-seven embedded rules that nobody has ever mapped.
The redesign does not know about any of that. It is designed against the stated process, not the actual one. And on day one of the new system, every one of those undocumented rules becomes an incident.
What Gall’s Law Says to Do Instead
Start with the smallest possible working system. Not a pilot that runs parallel to real operations and can be abandoned cleanly. An actual working system, doing real work, with real stakes, at the smallest possible scale.
Let it run. Watch where it breaks. Add complexity only where the simple system demonstrably cannot handle it. Each addition is earned by evidence — a real failure mode that needs a real solution — not designed by assumption in a workshop.
This is why the teams that ship successfully, and sustain what they ship, tend to do it incrementally. The product itself is a complex system. You cannot design it into existence. You can only grow it, one working increment at a time, each one building on the last.
Three Questions to Ask Before Any Transformation
When you are evaluating a programme — digital, organisational, operational — Gall demands honesty about three things:
-
Is there a version of this that we can make work at minimum viable complexity, today? If the answer requires everything to work before anything works, Gall says it won’t. The moving parts will multiply. The dependencies will compound. The integration points will fail in sequences nobody anticipated.
-
Do we understand the actual system we are replacing, not just the stated one? Map the informal rules, the workarounds, the tacit knowledge. If you cannot document what the current system actually does, your replacement cannot account for it.
-
Are we adding complexity in response to evidence, or to plans? Each addition to the system should be earned by a real failure mode that needed a real solution — not by a workshop, a consultant’s framework, or an executive’s intuition about what the final state should look like.
Small bets, done well, that compound over time: this is not a lack of ambition. It is the only strategy that reliably produces complex systems that work.
The transformation programme that promises to fix everything at once is the one most likely to fix nothing.
What is the most complex initiative on your current roadmap? What is the smallest version of it that would produce real evidence?
The Laws They Don’t Teach series:
Leave a Reply