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.

Gall's Law reveals itself whenever complexity is attempted through design rather than grown through iteration. The signature pattern is a system — technical, organisational, or strategic — that was specified comprehensively before being built, and that fails in ways its designers cannot diagnose because the failure emerges from interactions they could not anticipate. The opposite signal is equally diagnostic: a system that works reliably despite appearing patchwork or inelegant, because its complexity was accumulated through successive iterations that each worked before the next was added.

The most common symptom of a Gall's Law violation is a gap between the system's designed capability and its actual performance that grows wider as more resources are applied to close it. Patching does not work because the patches interact with each other and with the original design in ways that create new failure modes faster than they resolve old ones. The system becomes a treadmill of remediation — not because the team is incompetent but because the architecture was never validated through incremental operation.

Common misapplication: Using Gall's Law as an excuse for permanently staying simple. The principle does not argue against complexity — it argues against designing complexity from scratch. The goal is a complex system that works, arrived at through evolution from a simple system that worked. Founders who cite Gall's Law to justify never moving beyond their MVP are misapplying the framework. The simple system is the starting point, not the destination. The discipline is in the sequencing — simple first, then iteratively more complex — not in the avoidance of complexity itself.

Second misapplication: Confusing "simple" with "easy" or "incomplete." A simple system is not a half-built complex system with features missing. It is a complete system — fully functional at its scope — that happens to address a narrow problem. The TCP/IP stack was not an incomplete OSI model. It was a complete, working networking protocol that solved a specific problem. The distinction matters because a half-built complex system fails for Gall's Law reasons (untested interactions), while a complete simple system succeeds because every interaction within its scope has been validated.

The founders who build the most enduring companies share a structural discipline: they resist the pressure to build the complete vision and instead ship the simplest version that delivers value, then evolve it through successive iterations informed by real-world feedback. This is not incrementalism or lack of ambition — it is a recognition that the information required to build the complex system correctly does not exist until the simple system has generated it.

What distinguishes these leaders from founders who also "start small" is the intentionality of their simplicity. They are not building the minimum viable product because they lack resources. They are building it because they understand that operational feedback is the only reliable source of design information for complex systems. The simplicity is a strategy, not a constraint.

Gall's Law describes a structural constraint on how functional complexity comes into existence. The diagram below illustrates the two paths to building a complex system: the evolutionary path (start simple, iterate, accumulate validated complexity) and the direct-design path (specify the complete system, build it all at once). The evolutionary path succeeds because each layer of complexity is validated through operation before the next is added. The direct-design path fails because interactions between unvalidated components produce emergent failures that cannot be diagnosed or fixed without returning to a simpler starting point.

Gall's Law operates at the intersection of systems theory, evolutionary dynamics, and epistemology — it describes a fundamental constraint on how working complexity can come into existence. Its connections to other mental models reveal why the principle holds so reliably, why it is so frequently violated, and how it interacts with frameworks that address related aspects of complexity, simplicity, and system behaviour. The connections below map how Gall's Law reinforces models that share its evolutionary logic, creates productive tension with models that push toward comprehensiveness or scale, and leads naturally to insights about how initial conditions and accumulated complexity shape a system's long-term trajectory.

The statement captures the full principle in both its positive and negative forms. The positive form — working complexity evolves from working simplicity — is encouraging. The negative form — designed complexity cannot be patched into functionality — is the warning that most builders ignore at catastrophic cost.

Gall's Law seems straightforward in principle — start simple, iterate — but applying it requires distinguishing between situations where evolutionary development is structurally necessary and situations where comprehensive design is feasible and appropriate. Not every system requires an evolutionary approach, and not every ambitious design is a Gall's Law violation. The diagnostic is whether the system's interactions are predictable enough to be specified in advance or complex enough that they can only be discovered through operation.

The literature on Gall's Law spans systems theory, software engineering, product development, and evolutionary biology. The strongest resources combine theoretical rigour with practical applicability — explaining not only why direct design of complex systems fails but how the evolutionary alternative works in practice. Start with Gall for the foundational principle, read Brooks for the software-specific implications, study Meadows for the systems-theoretic context, and finish with Ries for the most operational translation into startup methodology.

The intellectual progression matters: Gall provides the principle, Brooks demonstrates it in the domain where the consequences are most measurable, Simon provides the theoretical explanation for why it holds, Meadows places it in the broader context of systems dynamics, and Ries translates it into a practical methodology that any builder can apply immediately. Each resource deepens the understanding of why starting simple is not a concession but a structural requirement.

The investor's diagnostic is straightforward: ask the founder what they will build first. If the answer is a comprehensive system that requires every component to work simultaneously, the probability of failure is very high regardless of the team's quality. If the answer is the simplest possible version that tests the core value proposition, the probability of success is materially higher — not because simple products always succeed but because simple products generate the information required to build complex products that do.

The most counterintuitive implication of Gall's Law is that the optimal strategy for building something complex is to not try to build something complex. The founders of the most complex systems in technology — Bezos, Zuckerberg, the architects of Unix, the designers of TCP/IP — did not set out to build complex systems. They set out to build simple systems that worked. The complexity emerged over years of iteration, each layer added in response to operational feedback that the previous layer generated. The complexity was not designed. It was discovered — revealed by the evolutionary process of building, operating, learning, and extending.

My operational conviction: the discipline of starting simple is the single highest-leverage habit a builder can develop. It requires resisting the completion bias that makes comprehensive designs feel more compelling. It requires accepting that the first version will be embarrassingly limited. It requires trusting that the information generated by operating the simple system will be more valuable than the information contained in the most comprehensive design document. And it requires the patience to iterate — adding complexity through successive validated layers rather than attempting to arrive at the destination in a single leap. The builders who develop this discipline create systems that work. The builders who do not create systems that look impressive in architecture diagrams and fail in production.