Law #2 — All Additions Increase Entropy

1. From Outcome to System Behaviour

The laws of systemic delivery do not describe activity. They describe outcomes.

Law 1 established the foundation: if it is not used, it does not exist. Reality does not respond to effort or delivery, only to adoption. In practical terms, this directly ties to time to market: delivering faster only matters if what reaches the market gets used. Speed without adoption accelerates irrelevance.

Law 2 extends this logic. If reality depends on usage, then everything that enters the system either supports that outcome or works against it.

There is no neutral change.

Most organisations optimise their ability to build, not their ability to deliver something that matters. As a result, they struggle to remain understandable.

2. The Illusion of Productive Growth

The cost of creating software has collapsed. Frameworks, cloud infrastructure, and AI-assisted tooling make it easier than ever to ship new components. Faced with a problem, the natural reflex involves adding something: a service, a feature, a rule, or a process.

Each addition solves something locally. Very few solve anything globally.

The system looks productive because it measures movement, not impact.

This dynamic follows a simple principle: nothing enters a system without altering it. Every new component introduces interactions. Every interaction carries cost.

This resembles side effects in functional programming. Each addition breaks the purity of the original intent. What once followed a clear and predictable path now depends on hidden interactions and accumulated state. Over time, the system no longer reflects its initial design, but the sum of everything that has been layered onto it.

3. Entropy as a Systemic Force

This is not theoretical. It shows up in real systems.

Over time, these costs accumulate into entropy.

In physics, entropy points to the irreversibility of phenomena. Once energy disperses, the system does not spontaneously return to its previous state. The larger the system, the more likely changes become irreversible. The same dynamic appears here.

Entropy reflects the progressive loss of clarity and predictability within a system. As entropy rises, understanding requires more effort. Engineers spend more time navigating the system than shaping it. Changes trigger side effects that no one fully anticipates.

As the system grows, reversibility disappears. Removing a component becomes harder than adding it. Dependencies lock decisions in place. What started as a simple addition becomes a permanent constraint.

Another dynamic makes this worse: metastability. Systems can appear stable while carrying hidden fragility. They operate under normal conditions, yet a small perturbation like a minor change, a slight load increase, a dependency failure, any can trigger disproportionate effects.

In metastable states, accumulated complexity masks risk. The system holds together until it does not. When it shifts, recovery becomes difficult because reversibility has already been lost.

You see this pattern in production systems that appear stable for months, then collapse under a minor load spike. In platforms that operate "well enough" until one dependency changes and everything stalls. In organisations where delivery feels under control until a single priority shift exposes how fragile coordination has become.

Nothing failed suddenly. The system had been unstable for a long time. It simply had not been pushed hard enough.

A well-known example illustrates this dynamic. The collapse of Nokia’s mobile division did not happen overnight. At its peak, Nokia dominated the global handset market. Yet internally, layers of complexity, fragmented platforms, and organisational misalignment slowed decision-making and product evolution. When the smartphone shift accelerated, the system could not adapt fast enough. Within a few years, Nokia lost market leadership, leading to the sale of its mobile division to Microsoft in 2014 for approximately $7.2 billion, followed by massive layoffs affecting tens of thousands of employees.

A technical analogue shows the same pattern under load. In 2012, Knight Capital deployed faulty trading code that interacted with legacy flags and dormant paths left in the system. Within 45 minutes, the firm lost around $440 million, wiping out its capital base and forcing a fire-sale. Nothing “new” alone caused the failure. Accumulated complexity and hidden interactions did.

Another example comes from infrastructure. In 2017, an AWS S3 outage in the US-East-1 region was triggered by an operator error during a maintenance task, which removed more capacity than intended. The underlying issue was not a single command, but the coupling and scale of the system. The disruption affected thousands of services and companies for hours, highlighting how tightly interconnected systems amplify small mistakes.

The failure looked sudden from the outside. Inside, entropy and metastability had been building for years.

This does not happen because teams make poor decisions. It happens because the system rewards addition and ignores accumulation.

4. How Organisations Actually Add Complexity

In practice, complexity does not arrive as a grand mistake. It arrives as a sequence of well‑intentioned decisions.

A slow onboarding? Build an internal platform. Then add a second layer when adoption stalls. Then add documentation, then a portal, then a governance step to “ensure consistency”. The original problem disappears under the solution.

Recurring incidents? Add checks. Then approvals. Then a release committee. Each step reduces perceived risk locally while increasing delay everywhere else.

Misalignment between teams? Add ceremonies. Weekly syncs become bi‑weekly reviews, then steering committees, then cross‑team alignment forums. Coordination grows because the system requires it.

None of these decisions look wrong in isolation. Together, they create a system that engineers route around.

Platform teams start building for themselves instead of for users. Products accumulate layers nobody asked for. Engineers keep private scripts and side paths because the “official” route costs too much time.

People do not fight bad systems. They bypass them.

This is where time to market starts degrading silently. What once took days now takes weeks, not because of technical difficulty, but because every step requires navigation through accumulated layers.

At that point, the organisation does not lack capability. It lacks usability.

The system has not broken. It has become inconvenient enough that people quietly ignore it.

5. The Cost of Non-Neutrality

Most organisations do not lose speed suddenly. They lose it incrementally, one justified decision at a time.

Industry data aligns with this pattern. The DORA reports show that elite performers achieve lead times measured in hours or days, with low change failure rates, while low performers operate with lead times of weeks or months and higher failure rates (Google DORA Reports, 2019–2023). The gap does not come from effort. It comes from system design, lower dependency density, tighter feedback loops, and less process overhead.

Product analytics reinforces the economic angle. A large share of shipped features generates little to no usage, yet still increases maintenance cost and cognitive load (Pendo Feature Adoption Reports). Systems grow while effective output does not.

The absence of neutrality defines the cost structure of the system. Adding something never only adds value. It also introduces an ongoing tax.

That tax appears everywhere.

Engineers spend time understanding systems they did not build and do not need. Teams duplicate functionality because discovering existing capabilities costs more than rebuilding them. Onboarding slows because the learning surface keeps expanding.

You see it in platforms with multiple ways to achieve the same outcome. In services that overlap but cannot replace each other. In processes added after incidents that never get removed.

The result looks familiar: high activity, low clarity.

Time to market deteriorates as a direct consequence. Work spends more time waiting, navigating, and aligning than moving forward. Lead time stretches not because problems grow harder, but because the path through the system grows longer.

You are not slowing down because work is harder. You are slowing down because your system is longer.

A simple way to see it: if each added step introduces even a small delay, the cumulative effect across a delivery path turns days into weeks. Entropy compounds latency.

Even strong engineering teams underperform under this weight. They move slower not due to capability, but due to accumulated friction.

At scale, this turns into quiet resignation. People stop questioning the system. They adapt to it. Workarounds become normal. Inefficiency becomes culture.

That is the real cost of non-neutrality: gradual normalisation of friction and loss of effective speed.

6. The Missing Discipline: Removal

Controlling entropy requires a shift in mindset. The question changes from “what should we build?” to “what should we remove or simplify before we build?”

This shift rarely happens naturally. Organisations celebrate creation. They rarely reward simplification. Removing a component produces no visible milestone. Consolidating systems generates little recognition.

Yet these actions provide the only sustainable path to maintaining clarity.

High-performing systems treat simplicity as an asset. They challenge additions, consolidate aggressively, and remove without hesitation. They accept that capacity does not come from adding more. It comes from carrying less.

Strong leaders play a decisive role here. They understand that every “yes” carries a cost that rarely disappears. They protect the system by saying no. No to unnecessary features, no to redundant layers, no to solutions that add more than they remove.

Saying no is not resistance to progress. It is protection of clarity, speed, and intent. Without that discipline, entropy always wins.

7. Conclusion — Complexity Always Wins (Unless You Fight It)

This discipline does not eliminate complexity. It prevents uncontrolled growth.

Left unchecked, entropy becomes the dominant force in the system. It shapes behaviour, slows execution, and reduces adaptability.

Understanding this law changes how decisions are made. It introduces friction at the right place: before adding something new.

The objective does not lie in avoiding change. It lies in recognising that every change carries a cost that does not disappear.

Left unchecked, complexity does not slow your system. It replaces it.

Post 1

All additions increase entropy. Nothing is neutral.

Every new feature, service, or process feels like progress.

Each addition:

• increases cognitive load
• creates new interactions
• expands failure surface

We build faster than we simplify.

That is how systems slow down while appearing productive.

#SystemsThinking #EngineeringLeadership #Complexity

Post 2

Most organisations do not collapse under bad decisions.

They collapse under accumulation.

Layer after layer:

• tools
• processes
• services

Each one justified. None removed.

The result?

A system no one fully understands.

Speed does not disappear. It gets buried.

#PlatformEngineering #TechLeadership #Flow

Post 3

If you want to move faster, stop adding.

Start removing.

Capacity does not come from more:

• more services
• more rules
• more structure

It comes from less.

Fewer moving parts.
Clearer systems.
Lower entropy.

Most teams do not even consider it.

#Simplicity #Engineering #Leadership