Gall's Law
Start with one small loop that works for someone, then add parts because the loop shows you it needs them.
Complex systems that work usually grow from simpler versions that already deliver one useful result reliably.
An architecture that has never produced a result
The team wants the system to notice a software failure, gather the evidence, suggest a fix and check that the fix worked. Before it can do that once, the plan grows to include many data sources, several specialist tools, a layer that judges their answers and a memory of earlier incidents. Every future need has a box in the diagram.
Six weeks later, most boxes are partly connected, but the system still cannot carry one real failure from the first alert to a verified fix. It can suggest a change without proving that the original problem disappeared, and one engineer is still manually keeping the parts in agreement.
The system has many parts, but it has never taken one real problem from start to a verified result reliably.
Gall's Law, named for John Gall's observation in Systemantics, says that a complex system that works is usually found to have evolved from a simpler system that worked. A complex system designed whole from scratch is unlikely to become reliable through patching because its important interactions have never been validated together.
Start by closing one loop
The team chooses one narrow outcome:
Detect one production regression, connect it to the relevant change, produce an evidence-backed diagnosis, open a small pull request, verify the fix and record the result.
For now, the system uses only the incident source, the code repository and continuous integration. It handles one service and one class of failure, which is enough to test the full loop in real use.
Real use now reveals facts the original architecture could only guess:
- Which evidence an engineer needs before trusting a diagnosis
- How fresh that evidence must be
- Which states belong to an incident, a proposed fix and a verified outcome
- Where human judgment is necessary
- Which permissions are genuinely required
- What happens when the patch passes tests but the production symptom remains
- Which result is worth remembering for the next incident
After this loop works repeatedly, the team adds logs because a known class of incidents can't be explained without them. Product analytics comes later when technical recovery needs to be connected to customer impact. A specialist agent appears only after repeated work reveals a stable specialty.
The resulting system may eventually resemble the original diagram. In the later version, each new interface was added to solve a limitation observed in a workflow that already worked.
Add the next component when real use shows a limitation that the current workflow can't solve.
Simple means fewer unproven relationships
Feature count can mislead. A small-looking product connected to eight uncertain services may be harder to run than a larger product with one well-understood path.
Complexity lives in interactions:
- Who owns a state transition
- Which component has authority to act
- How two sources disagree
- What a retry duplicates
- Which failure blocks the whole path
- How a result becomes observable
Adding one component does more than add one feature. It creates new relationships with existing parts, new ways to fail and new things someone has to recover.
This changes the design question. Don't ask only, “What is the smallest set of features?” Ask, “What is the smallest set of relationships that can complete a valuable, observable loop?”
Use the roadmap for planned capabilities, and use a completed real workflow as evidence of what the system can already do.
How this works in other fields
Software and product development. Build one narrow user result all the way from what a person does to the data, release and evidence that it worked. Running that complete path reveals assumptions between parts that remain invisible when each technical layer is built separately. Keep parts separate where that helps, but create those boundaries around differences and failures the real work has shown, rather than categories imagined in advance.
Biology and evolution. Complex organisms arise through viable intermediates. Each stage must already survive and reproduce; evolution can't preserve a structure solely because it will become useful after five more coordinated mutations. Organisations can choose goals, redesign interfaces and accept temporary scaffolding in ways natural selection can't plan.
Organisational design. A complete future org chart can specify teams, councils and handoffs before recurring work has revealed where coordination is costly. The result is often empty ownership at the boundaries and people waiting for permission from roles that have little operational context. Starting with one accountable group that completes the whole outcome creates evidence for the first useful boundary. Specialisation can then split around demonstrated differences in skill, cadence or risk while retaining an owner for the end result.
Across these examples, start from a version that already works so each new dependency is tested against a real result instead of an architecture that exists only on paper.
How to grow the system
Use Gall's Law when a proposal has many integrations, agents, teams or operating modes and nobody can yet show one complete result.
- Name one outcome. Choose a result that matters to a real user, not an internal component milestone.
- Close the path. Include the trigger, decision, action, verification and recovery needed to complete that outcome.
- Observe the joins. Record where evidence becomes stale, ownership becomes ambiguous or state changes meaning.
- Stabilise the loop. Make the result repeatable enough that a new capability won't merely disguise existing uncertainty.
- Add one capability that solves a repeated limitation.
- Protect what already works. Use contracts, tests, telemetry and migration paths so growth doesn't quietly break the original outcome.
- Reconsider the shape. A successful prototype can create path dependence. Rewrite a boundary when evidence shows that the first structure no longer fits.
Useful questions include:
- What is the smallest complete loop that gives someone value?
- Which relationships inside it are still assumptions?
- How will we know the loop actually completed?
- Which failure and recovery path must be present from the first version?
- What observation would justify adding the next component?
- Can that component join without changing the meaning of existing state?
Where this can go wrong
Gall's Law can become an excuse for crude prototypes and neglected foundations.
Some constraints belong in the first version because adding them later would be unsafe or ruinously expensive. A payment ledger needs integrity and auditability. A medical device needs safety controls. Personal data needs an intentional security and privacy boundary. A physical product may need stable mechanical interfaces before several teams fabricate parts.
Some simple systems should stay simple. A quick prototype may encode assumptions that become expensive path dependence. Success at small scale doesn't prove that the same architecture can handle different loads, adversaries or legal duties.
The discipline is to begin with a simple complete system that includes the foundations that are unsafe or ruinously expensive to add later. Keep clear boundaries around parts that will be expensive to change, version important data and replace temporary parts when the first structure no longer fits.
The law describes a development path, and every version used in practice still has to be safe.
Related models
An MVP tests whether a proposed product creates enough value for users. It may be a concierge service, mock or manual process. Gall's Law concerns how a functioning system acquires complexity. The first system can be narrow, but the outcome it claims to deliver must actually work end to end.
Conway's Law says that a system tends to mirror the communication structure of the organisation that builds it. Gall's Law asks how a working system came to exist in the first place. A premature team structure can harden speculative boundaries; a working loop gives the organisation evidence about where boundaries belong.
As the system grows, keep verifying that it still completes the original useful workflow.