Skip to main content
José Pedro Nunes
Gall's Law

Gall's Law

Jun 16, 2026

“Great advances do not come out of systems designed to produce great advances.” - John Gall

Every large organization and every large product started small. The ones that kept working are usually the ones that stayed simple at the core. Simple principles, light processes, systems you can hold in your head.

That is Gall’s Law. A complex system that works grows out of a simple system that worked first. A complex system designed complex from the start does not work, and usually cannot be made to.

Where the law comes from

John Gall was an American pediatrician who wrote about systems on the side, mostly about how they fail. His 1975 book, “General Systemantics: An Essay on How Systems Work, and Especially How They Fail,” gave us the line that carries his name:

“A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work.” - John Gall

The lesson for anyone building something is direct. Starting complex, from zero, on a pile of assumptions, is a bet you usually lose. Start small, ship the simple version, learn what it is really for, and grow it from there.

Complexity slows everything it touches

“Bureaucracy is more people doing less things, and taking more time to do them worse.” - Evan Esar

As a company grows, we add process. We add structure. We add a layer, and each layer feels reasonable on the day we add it. Then the company that used to decide in an afternoon takes a quarter, and nobody can point to where the time went.

This is how a smaller competitor with fewer resources outruns a giant. Lighter structure, a shorter path from idea to shipped, less to untangle when the market moves. Complexity is easy to add and hard to remove. Once it is in the org, it is in the systems too, and the whole thing gets slower to change, often just when change matters most.

There is a quieter benefit. The simpler a thing is, the less room it has to go wrong. Murphy’s Law says whatever can fail will. Gall’s Law gives it less to work with.

And the shape of the org leaks into the product. Conway noticed it first: a system ends up mirroring the communication structure of the teams that built it. So the org chart is where simplifying starts. If it is not clear who owns what, the software will not be clear either.

A team that tried to build everything

I once watched a team set out to build everything at once. Someone had written a complete blueprint for the whole product, every feature mapped out before any of it existed. It was a good blueprint. The trouble was the plan that came with it: build all of it, and launch only when every piece was done.

Months went by and nothing shipped. The work was real, but the world did not wait. Competitors kept shipping, the market shifted, and the plan kept chasing it. The cost was time and momentum, and worse, the opportunities that closed while they waited. One feature showed how it happened. It started small, then it had to handle more and more cases, and once it finally worked, they decided it still could not launch, because it was missing a part large enough to be a product of its own. Underneath all of it, they had never agreed what done meant, so “good” had quietly become “everything.” The goalpost moved every week, and it wore everyone down.

So they stepped back. They got clear on who the product was for and what those people actually needed, and built around that instead of around the blueprint. They looked at the real work their target customers did every day, found where they could remove the most hours, and made proof the bar: build something small, confirm it actually helped, then build more.

They had set out to build the complex whole from scratch, the exact thing the law says cannot be made to work. The way out was a simple core that solved one real problem, grown from there.

Keeping it simple as it grows

When you are tempted to design the whole complex thing up front, make the opposite move. Find the smallest version that solves a real problem, ship it, and let what you learn shape the next step.

A few habits hold the line as the thing grows:

When simple is the wrong answer

Simple is not the goal by itself. A system still has to solve a real problem, or it is a tidy way of doing nothing. Keeping things simple for the sake of it is its own trap.

And simplicity does not hold still. Entropy pulls every working simple system toward complexity. The ones that succeed get used more, asked to do more, and extended, and the extending is what makes them fragile. We have all watched a clean tool turn into a bloated one. So Gall’s Law asks for maintenance, not just a good start. The pull toward complexity never lets up, and keeping a system simple is work for as long as it lives.

Wrap-up

“Keep it simple, so you’ll keep doing it.” - Steve Krug

One of my favourite books on usability is Steve Krug’s “Don’t Make Me Think.” His point is that good design does not ask the user to stop and work it out. The same holds for an org, a process, a product. The less it makes anyone think to use it, the more it gets used, and the longer it lasts.

Gall’s observations have held up for fifty years. The advice underneath them is short enough to keep. Start simple.