Part 1 — Systems Thinking: The Mental Model Every Engineer Is Missing

There is a bug in the payment service. You fix it. Three months later it is back — slightly different, same root shape. You fix it again. It comes back. Your team calls it "the recurring payment bug." They accept it the way people accept bad weather. Nobody questions why it keeps returning. Nobody asks what part of the system keeps producing it.

This is not a bug story. This is a systems story.

The bug is a symptom. Somewhere upstream — in the incentive structure of your sprint planning, in the way service contracts are written, in the absence of an integration test environment that mirrors production — a condition exists that regenerates the bug every quarter. You will never fix it by patching the output. You have to find the generator.

That is what systems thinking gives you: the ability to see generators, not just symptoms. To trace the invisible threads that connect a marketing decision to a supply chain failure, a cost-cutting memo to a global boycott, a sprint velocity target to accumulated technical debt that takes down production on Black Friday.

It is not a tool. It is a shift in perception. And once you make it, you cannot unsee it.

Read that again. Ninety-four percent. That means the next time someone in your company proposes firing the engineer who caused the outage, there is a 94% chance the real culprit is the process that made the outage inevitable in the first place. Systems thinking is what lets you make that argument with precision, not just instinct.

What a System Actually Is

Here is a question most engineers cannot answer cleanly: what is the difference between a collection of parts and a system?

A pile of engine components on a garage floor is not a car. The components are all there. Nothing is missing. But there is no car. The car only exists when those components are assembled in a specific way, with specific connections, oriented toward a specific purpose. Disrupt any of those three things and you no longer have a car — you have parts.

A system is a set of interconnected elements that work together to form a unified whole, where a change in one element impacts all others.

The critical word is "interconnected." Not adjacent. Not colocated. Interconnected — meaning a change in one part propagates through the whole. That propagation is what makes a system a system, and it is what makes systems surprising, counterintuitive, and — once you learn to read them — deeply legible.

Consider a dim sum restaurant in Hong Kong. Every morning it takes in three things from the outside world: customers, ingredients, and money. Every evening it outputs three things back: food, drinks, and — if everything went right — happy customers. Inside, it runs three subsystems: the kitchen, the dining room, and the cashier. Outside, it depends on four external actors: ingredient suppliers, payment processing services, a marketing agency, and the government (taxes, food safety regulations, licensing).

Now here is the insight that changes everything. Suppose the restaurant runs a successful marketing campaign. More customers walk through the door. What happens? The kitchen gets slammed. The kitchen calls the supplier for more ingredients. The supplier cannot keep up. Ingredient quality drops or lead times stretch. The kitchen starts substituting dishes. Customer satisfaction dips. Reviews worsen. The marketing campaign that was supposed to grow the business ends up shrinking it — because someone optimized one part without modeling the whole.

That is not a hypothetical. That is how most organizational failures actually unfold.

Every node in that diagram is both a receiver and a sender. The restaurant does not exist in isolation — it is constantly exchanging with everything around it. That exchange IS the system. And the most dangerous decisions are the ones made by people who can only see their own node.

Jay Forrester at MIT formalized this discipline in the 1950s. Peter Senge made it accessible to business practitioners in "The Fifth Discipline" in 1990. Donella Meadows wrote what remains the definitive text — "Thinking in Systems" — in 2008. The ideas are not new. What is new is how urgently they apply to the systems we build in software.

The Three Parts of Every System

Every system — from a Kubernetes cluster to a national economy — is made of exactly three things. Not four. Not two. Three. Once you know what they are, you will see them everywhere.

The three components are not equal in importance. Most people spend all their time on elements because elements are tangible. You can count chefs. You can measure inventory levels. You can see tables.

Interconnections are harder to see. They are flows — of information, materials, money, influence. You cannot point to "the relationship between the marketing agency and the kitchen." But that relationship is what caused the cascade failure in the restaurant story. The interconnection was real. It was just invisible until something broke.

Purpose is the most powerful and the least visible of all three. Here is a subtle trap that Donella Meadows identified: the stated purpose of a system is almost always different from its actual purpose. The actual purpose is revealed by behavior, not by mission statements. A hospital that claims its purpose is "patient health" but whose metrics all measure throughput and billing — that system's actual purpose is throughput and billing. And it will behave accordingly, even when individual people inside it are trying to do the right thing.

This is why so many software teams are baffled when processes designed for quality keep producing shortcuts. The stated purpose is quality. But if every incentive in the system rewards velocity, the actual purpose is velocity. You cannot fix that by writing a better quality policy. You have to change the interconnections that enforce purpose.

Now you have the vocabulary. Elements, interconnections, purpose. Hold those three as you read the next section — because the real question is whether your system is open or closed, and the answer shapes everything.

Closed vs Open: The Two Flavors of Every System

Not all systems face the same external pressure. And understanding which kind of system you are working in is not a theoretical exercise — it is the difference between designing something robust and designing something that shatters the first time reality touches it.

A closed system is self-contained. It has limited interaction with its external environment. Energy, information, and matter stay largely inside the boundary. In software, the closest analog is a hermetically sealed test environment: a controlled Docker Compose setup where all dependencies are mocked, no external network calls are made, and the behavior is predictable because nothing outside the boundary can interfere. Research labs running classified experiments operate this way by design. The isolation is the feature.

An open system is dynamic. It continuously exchanges energy, information, and matter with its environment. It is affected by external actors it does not control. A supply chain is an open system. A SaaS product is an open system. A microservice running in production — exposed to real traffic, dependent on third-party APIs, subject to infrastructure events from your cloud provider — is an open system. The real world pours through the boundary constantly.

Here is the engineering implication: most engineers design for closed systems and deploy to open ones.

You test in isolation. You spec behavior against a controlled dataset. You mock the payment gateway. Then you go to production, and the payment gateway starts returning a rate-limit error you never handled because it never appeared in the mock, and suddenly you are losing revenue on a Saturday night while your on-call engineer searches through logs.

That is not a bug. That is the difference between a closed model and an open reality.

Amazon's flywheel is one of history's most elegant examples of intentional open-system design. Lower prices attract more customers. More customers attract more third-party sellers. More sellers create more product selection. More selection at competitive prices lowers Amazon's own fulfillment costs. Lower costs enable lower prices. Jeff Bezos sketched this loop on a napkin in 2001. What he was drawing — though he may not have used the term — was an open reinforcing system: one that actively uses the external environment (sellers, customers, logistics partners) as fuel for its own growth cycle.

Toyota built the same insight into its production system. In the Toyota Production System, any worker can stop the entire assembly line when they detect a defect. This seems counterintuitive — stopping the line is expensive. But Toyota understood something most manufacturers did not: a defect hidden is a defect multiplied. The system was designed to surface problems, not conceal them. The environment (customer demands, supplier quality, workforce observations) flows continuously into the system and reshapes it. That is an open system by intentional design.

The question you need to answer about every system you build or work in: where is the boundary, and what are you letting through it?

The Decision That Looked Brilliant Until It Wasn't

In the boardroom, it seemed simple.

The Gallon Fashion executive team was under margin pressure. Production costs were eating into profits. The solution appeared obvious: shift manufacturing to an overseas contractor where labor was cheaper. The financial model showed the math clearly. Profits would go up. They did — for a while.

But the team modeled only one layer of the system: their own cost structure. They did not map the contractor's ecosystem. They did not ask what the contractor would do under pressure to maintain margins. They did not consider the local communities surrounding the overseas factory. They did not account for activist networks that monitor labor conditions in exactly this kind of facility. They did not include the government of the host country in their model.

Here is what actually happened. The overseas contractor, facing its own margin squeeze, cut maintenance budgets, reduced safety protocols, and slashed staffing. Working conditions deteriorated. Local communities noticed. They organized a boycott of the factory. The government stepped in to investigate, issued fines, and eventually forced a temporary shutdown — disrupting Gallon Fashion's supply chain. And then the media found the story. The contractor's working conditions were reported internationally. The story did not stop at the contractor. It came back to Gallon Fashion. A global boycott followed. The PR disaster erased years of brand equity — far more value than the cost savings ever generated.

Every single one of those events was predictable. Not in detail. But in structure. If someone had mapped the full system before the decision — including the contractor's incentive structure, the local community as a stakeholder node, the activist network as a monitoring node, and the government as an enforcement node — the cascade was visible before it happened.

The same pattern plays out in software continuously. A team migrates to a new database without mapping every downstream consumer. An API change is deployed without modeling all the clients that have built against the old contract. A machine learning model is retrained without accounting for the feedback loop between its predictions and the behavior they are shaping. In each case, the failure was not in the component that changed — it was in the unmapped connections to the components that were not consulted.

Model It: Your First System in Code

Reading about systems is useful. Running one is different.

The code below simulates the Hong Kong restaurant as a simple open system. The model is intentionally minimal — the goal is not accuracy, it is insight. You are going to watch a marketing decision cascade through the system in real time, and the output will be more instructive than any diagram.

# Shows how a single change (marketing) cascades through the entire restaurant system

def simulate_system(days, inventory, daily_supply, base_demand, marketing_multiplier=1.0):
    """
    Simulates a restaurant system over N days.
    Key insight: marketing affects demand, demand strains inventory,
    inventory limits service. That chain IS the system.
    """
    print(f"{'Day':>4} | {'Demand':>8} | {'Served':>8} | {'Lost':>7} | {'Stock':>7}")
    print("-" * 48)

    for day in range(1, days + 1):
        # External environment sends customers (open system: outside affects inside)
        demand = int(base_demand * marketing_multiplier)

        # System constraint: you cannot serve what you don't have
        served = min(demand, inventory)
        lost = demand - served           # unmet demand = system inefficiency

        # Update the stock (inflow from supplier - outflow from sales)
        inventory = max(0, inventory + daily_supply - served)

        print(f"{day:>4} | {demand:>8} | {served:>8} | {lost:>7} | {inventory:>7}")

print("SCENARIO A — Balanced system (supply matches demand)")
simulate_system(days=5, inventory=50, daily_supply=40, base_demand=40)

print()
print("SCENARIO B — Marketing campaign doubles demand, supply unchanged")
simulate_system(days=5, inventory=50, daily_supply=40, base_demand=40, marketing_multiplier=2.0)

SCENARIO A — Balanced system (supply matches demand)
 Day |   Demand |   Served |    Lost |   Stock
------------------------------------------------
   1 |       40 |       40 |       0 |      50
   2 |       40 |       40 |       0 |      50
   3 |       40 |       40 |       0 |      50
   4 |       40 |       40 |       0 |      50
   5 |       40 |       40 |       0 |      50

SCENARIO B — Marketing campaign doubles demand, supply unchanged
 Day |   Demand |   Served |    Lost |   Stock
------------------------------------------------
   1 |       80 |       50 |      30 |      40
   2 |       80 |       40 |      40 |      40
   3 |       80 |       40 |      40 |      40
   4 |       80 |       40 |      40 |      40
   5 |       80 |       40 |      40 |      40

Look at Scenario B carefully. On Day 1, the restaurant still has buffer inventory (50 units), so it serves 50 customers and loses 30. By Day 2, the buffer is drained. The system has reached its ceiling: it can serve exactly 40 customers per day because that is all the supply allows, regardless of how many are waiting. From Day 2 onward, 40 customers per day go unserved. The marketing campaign that was supposed to drive growth is now destroying trust — and the model shows exactly when and why.

Experiments to try:

Experiment 1 — What if supply scales with demand? Change daily_supply to int(base_demand * marketing_multiplier * 0.9) in Scenario B. This models a supply chain that partially responds to demand signals. What does the system do differently?

Experiment 2 — Add a 2-day supply delay. Store supply in a queue and only release it 2 iterations later. This models the supplier lead time the story assumed away. Watch how the buffer behaves.

Experiment 3 — Add a customer satisfaction feedback loop. If lost > 0, reduce base_demand by 5% the following day (bad reviews reduce future demand). This creates a self-punishing spiral — the shape of most real operational degradation.

Each of these is a real pattern you will encounter in software: the delay, the feedback, the hard constraint. The vocabulary here transfers directly to microservice latency chains, ML training pipelines, and CI/CD queues.

How to Read Any System in 10 Minutes

You are now in a meeting. Someone proposes a change — a new deployment strategy, a cost reduction, a reorganization. You have ten minutes before the room moves to a vote. Here is how to use them.

Apply this to your current team right now. Not hypothetically.

Your team is the system. The elements are the people, the services, the tools, and the processes. The interconnections are the code review flow, the deployment pipeline, the incident escalation path, the meeting structure, the backlog grooming ritual. The purpose — the actual purpose, not the one in the OKR doc — is revealed by what your team consistently prioritizes when there is a conflict between shipping velocity and test coverage.

Step 4 is where most people stop short. They map elements. They draw a few arrows. They never get to Step 4 because Step 4 requires running a mental simulation of a change you have not made yet. That is uncomfortable. It requires committing to a prediction. But it is also where systems thinking delivers its most concrete value — because the prediction, even if imperfect, forces you to articulate the causal chain. And a causal chain you can articulate is a causal chain you can interrupt.

Go back to the restaurant one more time. A marketing campaign doubles demand. Step 4 asks: which element is most stressed? The kitchen. What feedback loop gets triggered? Unserved customers → bad reviews → reduced future demand. Where is the delay? The inventory buffer masks the problem for exactly one day before the constraint becomes visible. That ten-minute analysis — done on a whiteboard before the campaign launches — is the difference between the Gallon Fashion story and a story about intelligent, sustainable growth.

In Part 2, we will give this process real instruments. System maps. Causal loop diagrams. Stock and flow models. And the Borneo DDT disaster — a story about a government that solved the wrong problem so thoroughly it created three new ones.