Gall's Law

In 1975, the American paediatrician and systems theorist John Gall published Systemantics: How Systems Really Work and How They Fail. Buried within a book that read like satire but operated as serious systems theory was a single observation that has since become one of the most reliable diagnostic principles in engineering, product development, organisational design, and technology strategy: "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 have to start over with a working simple system." This is Gall's Law — and its implications are far more consequential than its aphoristic form suggests.

The principle is empirical, not aspirational. Gall was not recommending simplicity as a design philosophy. He was reporting a structural observation about how functional complexity actually comes into existence. Every complex system that reliably works — the internet, the global financial system, the human immune system, Amazon's logistics network, a mature software platform — arrived at its current complexity through an evolutionary process that began with a simple version that functioned. The simplicity was not a concession to resource constraints or a minimum viable product strategy. It was the structural precondition for the system's eventual complexity. Without the working simple system as a foundation, the feedback loops that enable iterative refinement — testing, learning, adapting, extending — have nothing to operate on. The complexity must be grown, not assembled.

The corollary is equally important and more frequently violated: complex systems designed from scratch do not work. They cannot be made to work by debugging, patching, or adding resources. The failure is not in the execution but in the architecture of the attempt. When designers sit down to specify a complex system in its entirety before building it, they are attempting to anticipate the interactions among hundreds or thousands of components operating across conditions that cannot be fully enumerated in advance. The number of potential interactions grows combinatorially with the number of components. A system with ten components has forty-five pairwise interactions. A system with a hundred components has nearly five thousand. A system with a thousand has nearly half a million. No design team, regardless of talent or resources, can anticipate how those interactions will behave across the full range of operating conditions. The simple system that works provides the only viable path: start with interactions you can observe, understand the feedback they produce, then extend incrementally — adding complexity only when the existing system has demonstrated it can absorb it.

The principle applies with remarkable consistency across domains. In software engineering, the most resilient architectures — Unix, the TCP/IP protocol stack, Git — began as simple tools solving narrow problems and evolved into platforms supporting extraordinary complexity. The systems that were designed to be comprehensive from the outset — IBM's OS/360, the OSI networking model, countless enterprise resource planning systems — either failed outright or required decades of painful remediation to achieve functionality that evolutionary systems achieved in a fraction of the time. In product development, the pattern is identical: the iPhone launched with no App Store, no copy-paste, no multitasking. Amazon launched selling only books. Google launched with a single search box. Each added complexity only after the simple core proved it worked — and each competitor that tried to launch with the full feature set from day one is now a case study in overdesign.

In organisational design, Gall's Law explains why restructurings fail and why the most effective organisations grow their structures organically rather than imposing them architecturally. A startup with five people does not need a matrix organisation, a performance management system, or a governance framework. It needs a working product and a feedback loop with its customers. As the organisation grows, structure must be added — but structure that is added in response to observed coordination problems is qualitatively different from structure imposed in anticipation of problems that have not yet materialised. The first type works because it addresses real feedback. The second type fails because it addresses imagined feedback, and the gap between imagined and real is always larger than the designers assume.

The deepest implication of Gall's Law is epistemological: it reveals a fundamental limit on what can be known in advance about complex systems. The reason you must start simple is not that simple is easier. It is that the information required to design a working complex system does not exist until the simpler versions have generated it through operation. Each iteration of the system produces data about how components interact, where failures occur, which assumptions were wrong, and what emergent behaviours arise that no designer anticipated. This information is not obtainable through analysis, simulation, or planning — it is only obtainable through operation. Gall's Law is, at its core, a statement about the limits of anticipatory knowledge and the irreplaceable role of empirical feedback in the construction of anything that works at scale.