Systemantics: What IT Projects Can Learn from How Complex Systems Fail

Gall’s core principles

Gall sets out a number of principles about the behaviour of complex systems. They may sound pointed at first, but they describe experiences many IT leaders know from their own projects.

Gall’s Law

The best-known principle reads:

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.

The recommendation is clear: start with a simple, working system and extend it step by step. This explains why so-called big-bang projects, which try to replace a large system in one go, fail particularly often.

Further principles

• Systems generally work less well than planned. Assuming a smooth launch means planning against reality.
• New systems create new problems. Every solution brings its own effort: operations, maintenance, security and further development.
• Systems tend to grow. Scope and rules often expand beyond the original purpose.
• Systems take on a life of their own. Preserving the system can become more important than the purpose it was created for.
• People work around systems. Cumbersome processes lead to workarounds, and metrics lead to behaviour that meets the metric but not the actual goal.
• The system only sees what is reported. Whatever metrics, dashboards and reports do not capture remains invisible. This distorts the view of the actual situation.

Well-known IT failures through the lens of Systemantics

Each failure has its own technical or organisational causes. Mapping them to Gall’s principles reveals recurring patterns. The question “What happened?” becomes “Why does this keep happening?”.

Case	Cause	Related principle
Ariane 5, flight 501 (1996)	Ariane 4 software was reused under different flight conditions. Converting a 64-bit floating-point value into a 16-bit integer caused an overflow, the failure of the inertial reference system and the destruction of the rocket.	Complex systems behave unexpectedly under new conditions.
Denver airport baggage system (1990s)	A highly complex automated baggage system was designed from scratch without a working predecessor. The airport opening was delayed by around 16 months, with additional costs of about 560 million US dollars.	Gall’s Law: complex systems designed from scratch do not work.
Therac-25 (1980s)	Proven hardware safety interlocks were replaced by software control. A rarely occurring timing bug led to radiation overdoses with fatalities. Early error reports from users were initially dismissed.	The system only sees what is reported and shields those involved from reality.
FBI Virtual Case File (2005)	Unclear, constantly changing requirements and an attempt to replace the entire case management in one large system. The project was cancelled after spending around 170 million US dollars without a usable result.	Systems grow beyond their purpose and work against it.

What this means for IT projects today

At first glance, Gall’s observations seem pessimistic. However, modern approaches to software development, organisation and leadership can be understood as direct responses to the patterns he describes.

Start small and expand step by step

Gall’s Law argues against large projects that try to solve everything at once. Agile development therefore relies on a minimum viable product that delivers value early and grows iteratively. Team Topologies applies the same idea to internal platforms: the thinnest viable platform starts deliberately lean and grows with actual demand.

Move decisions to where the information is

When systems shield people from reality, decentralised decisions help. Intent-Based Leadership hands responsibility to the people who know the situation first-hand, instead of deciding on the basis of filtered reports.

Work with human behaviour, not against it

Gall observes that systems work best when they take human behaviour into account. Servant Leadership starts exactly here: it removes obstacles and reduces friction instead of forcing performance through pressure and control. Read more in our article Beyond Command and Control.

Conclusion: resilience over perfection

The most important lesson from Systemantics is humility in the face of complexity. A large socio-technical system cannot be fully planned and controlled in advance.

The successful organisations are therefore not those with the most comprehensive plan but those that learn and adapt quickly. Incremental development, a decoupled team structure and leadership that hands over responsibility together form the basis for robust and innovative IT.