Gall's Law
Why complexity must evolve from what already works
Facing grand challenges, we are often tempted to design massive, comprehensive solutions. We draw complex organizational charts, plan gigantic IT systems, or design sweeping social reforms. Yet history shows these grand projects frequently fail. John Gall, an American pediatrician and systems theorist, coined a rule explaining why: a complex system that works is invariably found to have evolved from a simple system that worked. If we want to build something large that endures, we must understand the underlying principles of this law.
What Is Gall's Law?
Practical Application in Work and Daily Life
To apply Gall's Law in projects and leadership, adopt an iterative strategy. First, build the simplest possible version that actually solves the core problem in a live environment. Test it and let it interact with reality. Only when this simple foundation is stable and delivering value should you add the next layer of complexity. This approach dramatically reduces risk and exposes flaws early.
Limitations and Nuances
While Gall's Law provides a powerful guideline, there are contexts where pure organic growth is insufficient. Certain physical or infrastructure projects, such as building a bridge or a nuclear reactor, require extensive upfront planning. However, even in these domains, the principle holds at the component level: each subsystem must be proven simple and reliable before integration into the larger structure.
Common Pitfalls and Misconceptions
The most common mistake when a large project fails is assuming the cause was insufficient planning. The typical reaction is adding more specification, analysis, and detailed documentation upfront. Gall's Law demonstrates that this is the wrong remedy: more planning for an untested complex system merely increases failure risk. Another mistake is confusing a simple starting point with a sloppy one; the simple system must work flawlessly in its simplicity.
Reflection exercises
Use these exercises to apply the chapter's ideas. You don't need to write anything down — just pause and reflect on each question.
Identifying Grand Blueprint Thinking
Consider projects in your surroundings or history that tried to encompass everything upfront.
- What highly ambitious project do you know of that collapsed?
- Was the project built on a ground-up redesign or an evolution?
- Was there any simple core component that actually worked initially?
- What would have happened if only the simplest working part had launched first?
Stripping Down to the Core
Think of an idea or initiative you want to bring to life.
- What is the absolute smallest output that delivers genuine value?
- Which three features or parts can you cut without destroying the core?
- What would a prototype look like that takes under a week to build?
- How can you test this simple version with real users in reality?
Analyzing Functional Complexity
Select a successful complex system you use every day.
- What did this system or service look like when it first launched?
- What original simple problem did it solve?
- What layers of complexity were added later based on actual usage?
- What does this reveal about the system's ability to survive and adapt?
Recognizing the Over-Planning Reflex
Reflect on your own pattern of reaction when faced with uncertainty.
- Do you typically respond to uncertainty by making more detailed plans?
- When did extensive planning last cause a project to become overly burdensome?
- What stops you from testing an undefined but simple version immediately?
- How can you practice accepting temporary simplicity?
Stepwise Expansion in Practice
Think of a routine, habit, or process you want to improve.
- What is the smallest micro-step you can take today?
- How do you know this micro-step actually works in your daily life?
- What signal indicates that it is time to add the next layer?
- What will you do if the simplest step fails to work?
Diagnosing a Failing System
Think of a current system or process that feels sluggish and broken.
- Are you trying to fix the system by adding even more complexity?
- Is it possible to scale back the system to a point where it actually worked?
- Which unnecessary layers or dependencies can be removed immediately?
- What does the most stripped-down working version look like today?
Summary
Gall's Law teaches us that shortcuts to complexity do not exist. A complex system that works always evolves from a simple system that already works in its environment. Attempting to build complex systems from scratch leads to chaos, hidden bugs, and failure. By starting small, validating in reality, and iteratively expanding, we build resilient systems in everything from software to organizations.
Read the short version in the archive.