Foundations of Systems Thinking

Summary

This chapter introduces the vocabulary of systems: what a system is, its boundary, environment, and inputs and outputs. It contrasts linear thinking with systems thinking, reductionism with holism, and correlation with causation, and introduces root-cause analysis as a way to look past symptoms. After completing this chapter, students will be able to describe any system in terms of its boundary, structure, and behavior, and distinguish a root cause from a symptom.

Concepts Covered

This chapter covers the following 22 concepts from the learning graph:

Concept	Concept Impact Score
System	367106
Subsystem	182466
System Boundary	120
Environment (System)	60
Input	23
Output	23
Throughput	22
Open System	54
Closed System	5
Systems Thinking	60900
Linear Thinking	11
Reductionism	10
Holism	9
Complexity	68
Complicated Vs Complex	15
Interconnection	121497
Interdependence	63
Cause And Effect	87600
Correlation Vs Causation	7
Root Cause	116
Root Cause Analysis	5
Symptom	62

Prerequisites

This chapter assumes only the prerequisites listed in the course descriptions.

---

Introduction

Every workplace has its own version of the same complaint: a fix that should have solved a problem instead created three new ones, or a team that improved its own numbers while making the whole organization worse off. Systems thinking is the discipline of stepping back far enough to see why that keeps happening. Before you can use it, though, you need a shared vocabulary — a way of talking about systems that works whether you're describing a bicycle, a hospital, a beehive, or a software company. This chapter builds that vocabulary from the ground up.

Meet Sage

Whoo there, fellow systems thinker! I'm Sage — an owl with slate-blue feathers, a cream chest, and a pair of small round glasses I never take off, because they help me see the big picture. I'll be popping up throughout this book, and here's exactly what I'm here to do:

1. Welcome: I open each chapter with a short welcome, like this one, so you know what's coming and why it's worth your time.
2. Think: When we hit a genuine "aha" moment — a new way of seeing something — I'll pause and think out loud with you.
3. Tip: When there's a shortcut that saves you real effort, I'll whisper it to you as a tip.
4. Warn: When I can see a mistake coming because I've watched it trip up other explorers before, I'll warn you and show you the way around it.
5. Encourage: When something is genuinely hard, I'll say so plainly and remind you that struggling with it is normal, not a sign you're behind.
6. Celebrate: And when you've truly mastered something, I'll celebrate it with you — by name, not just "good job."

If I'm not doing one of those six things, I'm not in the chapter — I only show up when I have something worth saying. Let's zoom out and see the whole system!

What Is a System?

A system is a set of parts that are organized and connected so that they work together to produce a behavior or outcome that no single part could produce alone. That definition has three pieces worth pulling apart. First, a system has parts — components that can, at least in principle, be told apart from one another. Second, those parts are organized and connected, meaning the arrangement matters, not just the pieces themselves. Third, the system produces something the parts could not produce in isolation — this is what makes a system worth studying as a whole rather than as a pile of components.

Consider a bicycle. Its parts — frame, wheels, pedals, chain, gears, brakes — are ordinary metal and rubber on their own. Scatter them across a garage floor and they do nothing. Connect them the right way, and pushing on the pedals turns the rear wheel, converting a rider's leg strength into forward motion at speeds far beyond running. The bicycle's ability to transport a person is a property of the whole arrangement, not of any single part. Take away the chain and the bicycle is no longer a transportation system at all, even though every other part is still present — a reminder that a system's identity depends on the connections between parts, not merely on which parts exist.

Systems appear at every scale you can imagine. A single cell is a system of organelles. A human body is a system of organ systems. A city is a system of neighborhoods, roads, and utilities. A company is a system of people, processes, and information flows. Even a conversation is a system, with two speakers whose words and reactions continuously shape each other. Learning to recognize the system underneath a situation — rather than seeing only its separate, disconnected pieces — is the single most important habit this book will build.

The Shift in How You See

Notice what just happened: a bicycle stopped being "a pile of parts" and became "a system for turning leg strength into motion." That shift — seeing the connections instead of just the pieces — is systems thinking in miniature.

Where a System Ends: Boundary, Environment, Inputs, and Outputs

Once you start looking for systems, an important question follows immediately: where does the system stop and everything else begin? The system boundary is the dividing line that separates what belongs to the system from what does not. A boundary is not always a physical wall — it is a decision, made by whoever is studying the system, about which parts and interactions count as "inside." Everything outside that boundary that still affects the system, or is affected by it, is called the system's environment (system).

Boundaries are genuinely a matter of choice, and the choice changes what you can and cannot explain. Consider a home's heating system. If you draw the boundary around just the thermostat and furnace, then the outside temperature is part of the environment — a factor the system responds to but does not control. If you draw the boundary around the entire house, including its walls and windows, insulation quality moves inside the system, and only the weather outside remains in the environment. Neither boundary is "more correct" than the other; each is useful for a different question. The first boundary helps you understand how the thermostat responds to cold; the second helps you understand how much fuel the house burns over a winter.

A system interacts with its environment through inputs and outputs. An input is anything that crosses the boundary going into the system — energy, material, information, or a signal. An output is anything that crosses the boundary going out. Between them lies the throughput: the process by which the system converts its inputs into its outputs. Picture a car wash. Water, soap, and electricity enter as inputs. A clean car — and, less usefully, a puddle of dirty runoff — exit as outputs. The throughput is everything that happens in between: the spinning brushes, the timed spray cycles, the drying fans. Naming these three parts separately matters because it lets you diagnose problems precisely — a car wash producing dirty cars might have a bad input (watered-down soap) or a broken throughput (a jammed brush), and those two problems call for completely different fixes.

Systems also differ in how freely they exchange things with their environment. An open system continuously exchanges matter, energy, or information across its boundary — a human body is an open system, constantly taking in food and oxygen and releasing waste heat and carbon dioxide. A closed system, by contrast, exchanges energy with its environment but not matter — a sealed thermos approximates a closed system, holding its contents in place while heat still slowly leaks through its walls. Almost every system worth studying in this book, from a company to an ecosystem, is open; true closed systems are mostly useful as a simplified idealization for physics and thought experiments, not as a description of how real organizations behave.

Finding a Boundary Fast

Stuck deciding where a system's boundary should go? Ask one question: "What am I trying to explain or change?" Draw the boundary around everything you'd need to control to answer that — nothing more, nothing less.

The following MicroSim lets you practice drawing a boundary around a system and watch how the labels "input," "output," and "environment" shift depending on where you place it.

Diagram: System Boundary Explorer

Run the System Boundary Explorer MicroSim fullscreen

System Boundary Explorer

Type: microsim sim-id: system-boundary-explorer
Library: p5.js
Status: Specified

Purpose: Let learners drag a boundary line around a simple depicted system (a household heating system: thermostat, furnace, house walls, outside weather) and see how the boundary choice changes which elements are labeled "inside the system," "input," "output," or "environment."

Bloom Taxonomy Level: Understand Bloom Taxonomy Verb: Illustrate

Learning Objective: Given a depicted scenario, the learner will illustrate how moving a system boundary changes what counts as an input, output, or part of the environment (Bloom: Understanding).

Canvas: 700x450 default, responsive — recalculate all positions and the boundary circle's radius as a fraction of canvas.width on a windowResized() handler so the layout rescales correctly on any device width.

Visual elements: - A household scene drawn in flat vector style: a thermostat icon, a furnace icon, a house outline, and an outdoor thermometer icon positioned outside the house outline. - A draggable, resizable dashed circle (the boundary) that the learner can drag by its center and resize by dragging a handle on its edge, using p5.js mouse-drag event handling. - Arrows automatically drawn crossing the boundary circle wherever an element's connection line intersects it, labeled "Input" (arrow pointing in) or "Output" (arrow pointing out). - A small text panel below the canvas that updates live to read: "Inside the system: [list]" and "In the environment: [list]," recomputed whenever the boundary moves.

Controls: - Two preset buttons, built with createButton(): "Boundary = Thermostat + Furnace Only" and "Boundary = Whole House," which animate the dashed circle to each preset position. - A "Reset" button that returns the circle to its default starting position and size.

Interactivity requirement: every icon (thermostat, furnace, house outline, outdoor thermometer) is clickable; clicking it opens a small infobox beside the canvas with that element's one-sentence definition, sourced from this chapter's prose (e.g., clicking the outdoor thermometer shows: "This is part of the environment whenever the boundary excludes it — the system responds to it but doesn't control it.").

Color scheme: warm amber for elements currently inside the boundary, cool slate-blue for elements currently in the environment, matching the book's existing color palette for consistency with other diagrams.

Implementation: p5.js sketch with createCanvas sized from the container width, dragEvent handlers on the boundary circle, and simple point-in-circle math to determine inside/outside status for each icon on every frame.

Systems Within Systems: Subsystems

Look closely at almost any system and you'll find smaller systems nested inside it. A subsystem is a system that is itself a component of a larger system, with its own internal parts, boundary, inputs, and outputs, even while it also serves a role inside the bigger whole. A car's engine, for example, is a complete system in its own right — it has inputs (fuel, air, spark), a throughput (combustion), and an output (rotational force) — yet it is also just one subsystem inside the larger system of the whole car, alongside the transmission, braking system, and electrical system.

Recognizing subsystems is useful because it lets you zoom your attention in and out without losing track of the whole. A mechanic diagnosing a car that won't start can treat the electrical system as a subsystem worth testing on its own — checking the battery, alternator, and starter motor as a self-contained unit — without needing to think about the transmission at all. But that same mechanic also needs to remember that the electrical subsystem's output (a spark at the right moment) is an input to the engine subsystem. Subsystems are connected to each other exactly the way a system is connected to its own parts, just one level up.

Zooming Between Levels

Here's the mental shift: nothing forces you to pick one "correct" level to look at. The same car is a system when you're asking "why won't it start?" and a subsystem when you're asking "why is this city's traffic so slow today?" Systems thinkers move between levels on purpose.

Diagram: Subsystem Nesting Explorer

Run the Subsystem Nesting Explorer MicroSim fullscreen

Subsystem Nesting Explorer

Type: microsim sim-id: subsystem-nesting-explorer
Library: p5.js
Template: https://github.com/dmccreary/automating-instructional-design/tree/main/docs/sims/rule-hierarchy-cascade
Status: Specified

Purpose: Show a car as a system made of nested subsystems (engine, transmission, braking system, electrical system), each of which can be expanded to reveal its own inputs, throughput, and outputs, reinforcing that a subsystem is a full system in its own right.

Bloom Taxonomy Level: Analyze Bloom Taxonomy Verb: Differentiate

Learning Objective: Given a depicted car, the learner will differentiate the whole-car system from its nested subsystems and identify each subsystem's own inputs and outputs (Bloom: Analyzing).

Canvas: 700x480 default, responsive — layout recalculates box positions as percentages of canvas.width/canvas.height inside windowResized().

Visual elements: - An outer rounded rectangle labeled "Car (System)" drawn in a light background color. - Four inner rounded rectangles nested inside it, one each for "Engine," "Transmission," "Braking System," and "Electrical System," each drawn as a distinct subsystem box with its own border. - Small arrows between adjacent subsystem boxes showing at least one real connection (e.g., an arrow from Engine to Transmission labeled "rotational force").

Controls: - Clicking any subsystem box expands it in place (animated width/height increase using lerp() over several frames) to reveal three small labeled sub-boxes inside it: "Input," "Throughput," "Output," each pre-filled with that subsystem's real values (e.g., Engine: Input = "fuel, air, spark," Throughput = "combustion," Output = "rotational force"). - A "Collapse All" button, built with createButton(), that animates all subsystems back to their collapsed state.

Interactivity requirement: every subsystem box and every Input/Throughput/Output sub-box is clickable, and clicking shows a one-sentence infobox definition beside the canvas (reusing this chapter's definitions of subsystem, input, throughput, and output).

Color scheme: each subsystem box uses a distinct pastel color from the book's existing palette so the four subsystems are visually distinguishable at a glance; the outer "Car" system uses a neutral gray border.

Implementation: p5.js sketch using nested rectangle drawing, an array of subsystem objects (each with position, size, expanded/collapsed state, and input/throughput/output text), and mousePressed() hit-testing against each box's current rectangle.

Linear Thinking vs. Systems Thinking

Most of us are trained, without ever being told directly, to think in straight lines: A causes B, so if you want more B, do more A. Linear thinking is exactly this — reasoning that assumes a single cause leads to a single, proportional effect, with no feedback flowing back from the effect to the cause. It works well for simple, isolated situations. Systems thinking, this book's central subject, is a broader way of reasoning that looks for the web of interconnected causes, feedback, and delayed effects surrounding a situation, rather than isolating one cause and one effect.

Imagine a retail store whose weekly sales suddenly drop. A linear thinker's instinct is to find the one cause and apply the matching fix: sales are down, so run a discount to bring customers back. A systems thinker asks a wider set of questions before acting: Did a competitor open nearby? Did the drop coincide with a staffing cut that led to longer checkout lines and frustrated customers who now shop elsewhere? Will a discount campaign, if it works, train customers to wait for sales before buying, quietly eroding profit margins for months afterward? The systems thinker isn't necessarily against running the discount — but they ask what else the discount will set in motion before committing to it.

Systems thinking overlaps with, but is not the same as, two related habits of mind. Reductionism is the practice of understanding something by breaking it into its smallest parts and studying each part in isolation — it is how a biologist studies a cell by examining its individual organelles, or how an engineer debugs software by isolating one function at a time. Holism is the opposite instinct: understanding something by looking at the whole and how its parts relate, on the premise that some properties only exist at the level of the whole and disappear when you isolate the parts — a flock of birds wheeling through the sky as one shape is a holistic property that no single bird possesses alone. Systems thinking does not reject reductionism outright; it uses reductionist analysis to understand individual parts, then insists on also asking how those parts interact, which reductionism alone tends to miss.

The following table summarizes the contrast between the two mindsets you've just read about:

Dimension	Linear Thinking	Systems Thinking
Cause and effect	One cause, one proportional effect	Multiple interacting causes, possibly with feedback
Time horizon	Immediate result	Immediate and delayed results
Focus	The part that seems to be failing	The relationships and structure around the part
Typical question	"What's the one fix?"	"What else will this fix set in motion?"
Best suited to	Simple, isolated problems	Interconnected, evolving problems

Most Schooling Trains the Left Column

Here's something worth sitting with: most math classes, most quick news stories, and most "five-minute fix" advice all live in that left column. Systems thinking isn't correcting a mistake you made — it's adding a skill most people were simply never taught.

Complexity: Complicated vs. Complex

Complexity describes a system with many interacting parts whose combined behavior is difficult to predict from the behavior of any individual part. It's tempting to treat "complex" as just a fancier word for "has a lot of pieces" or "is hard," but systems thinkers draw a sharper line between two situations that feel similarly intimidating but behave very differently.

The distinction of complicated vs. complex separates them precisely. A complicated system, like a mechanical wristwatch, may have hundreds of tiny gears and springs, but each part interacts with its neighbors in a fixed, predictable way. Take the watch apart, understand every gear, and you can put it back together with full confidence in how it will behave — complicated systems are hard to build but ultimately knowable, and an expert watchmaker can master one completely. A complex system, like a rainforest, behaves differently: its parts — trees, insects, fungi, weather, animal populations — interact in ways that shift over time, respond to each other, and produce outcomes that no single expert can fully predict even with complete knowledge of every part. Complex systems can surprise even the people who study them for a lifetime, because new behavior can emerge purely from how the parts are interacting right now, not from any flaw in anyone's understanding.

If This Feels Uncomfortable, That's Normal

If the idea that some systems simply can't be fully predicted — no matter how smart you are — feels unsettling, you're reacting exactly the way most people do the first time. Most schooling rewards finding the one right answer; complexity asks you to get comfortable making good decisions without one. That's a real skill, and it builds with practice.

Interconnection and Interdependence

Interconnection is the state of being linked or connected, directly or indirectly, to other parts of a system. Interdependence goes a step further: it describes a relationship in which two or more parts rely on each other, so that a change in one part necessarily produces a change in the others. Every interdependent relationship involves interconnection, but not every interconnection rises to the level of interdependence — two coworkers who occasionally share an elevator are interconnected; two coworkers whose projects each depend on the other's data are interdependent.

A global supply chain makes both ideas concrete. A car manufacturer, a semiconductor factory on another continent, a shipping company, and a local dealership are all interconnected — a shipment moving from one to the next links them together. They are also interdependent: when a single semiconductor factory shuts down, car manufacturers thousands of miles away are forced to slow or halt production, because their ability to build cars depends directly on a part they cannot make themselves. This is why supply-chain disruptions can ripple across an entire industry from a single point of failure — the interdependence transmits the disruption far beyond where it started.

Ripples, Not Isolated Events

Once you notice interdependence, isolated events start looking different. A factory shutdown on the other side of the world stops being "someone else's problem" and starts looking like a ripple heading straight for you — if you're connected to the pond it fell into.

The MicroSim below lets you click a node in a small supply network and watch which other nodes are directly and indirectly affected.

Diagram: Interconnection Network Explorer

Run the Interconnection Network Explorer MicroSim fullscreen

Interconnection Network Explorer

Type: graph-model sim-id: interconnection-network-explorer
Library: vis-network
Status: Specified

Purpose: Depict a small six-node supply-chain network (Semiconductor Factory, Parts Supplier, Car Manufacturer, Shipping Company, Dealership, Customer) so learners can click any node and see it highlighted along with every node it is directly and indirectly connected to, distinguishing mere interconnection from true interdependence.

Bloom Taxonomy Level: Analyze Bloom Taxonomy Verb: Trace

Learning Objective: Given a supply-chain network diagram, the learner will trace which nodes are affected, directly and indirectly, by a disruption at a chosen node (Bloom: Analyzing).

Canvas: full-width responsive vis-network container, 500px tall, with network.on("resize") and a window resize listener calling network.redraw() and network.fit() so the graph re-centers on any viewport width.

Visual elements: - Six nodes labeled Semiconductor Factory, Parts Supplier, Car Manufacturer, Shipping Company, Dealership, and Customer, laid out left to right in that supply-flow order using vis-network's hierarchical layout option. - Directed edges showing the flow of goods: Semiconductor Factory → Parts Supplier → Car Manufacturer → Shipping Company → Dealership → Customer. - One additional edge, styled with a dashed line and a distinct warning color, from Semiconductor Factory directly to Dealership, labeled "also ships specialty parts directly," to show that real networks are rarely a single clean chain.

Controls: - Clicking any node fires a click event handler that highlights that node in a bright accent color and highlights every node reachable from it (using a breadth-first traversal of the vis-network DataSet edges) in a lighter shade of the same color, while dimming unrelated nodes to low opacity. - A "Reset Highlighting" button, implemented as an HTML button outside the network div, that calls a function to restore all nodes and edges to their default colors. - A text panel beneath the network that updates on each click to read: "If [Node] stops working, it directly affects: [list]. Because of interdependence, the disruption can also reach: [extended list]."

Interactivity requirement: every node is clickable per the behavior above, satisfying the minimum interactivity bar with visible, teaching feedback (the highlight plus the explanatory text panel).

Color scheme: vis-network default node color for unaffected nodes, the book's accent orange for the clicked node, and a lighter orange for downstream-affected nodes, keeping consistent contrast in both light and dark MkDocs Material themes.

Implementation: vis-network DataSet/DataView objects for nodes and edges, a network.on("click", ...) handler performing a breadth-first search over the edge list from the clicked node, and network.setOptions() calls to restyle node colors on each interaction.

Cause and Effect, Correlation, and Causation

Cause and effect is the relationship between an event (the cause) and the event it produces (the effect). It is one of the oldest and most natural ways humans make sense of the world — something happens, and we immediately ask what made it happen. Systems thinking depends on getting cause and effect right, because every fix, policy, or decision is really a bet that a particular cause will produce a particular effect.

That bet goes wrong constantly because of a mistake known as confusing correlation vs. causation. Two things are correlated when they tend to change together — when one goes up, the other tends to go up (or down) too. But correlation alone never proves that one causes the other; both might be driven by a hidden third factor, or the relationship might be pure coincidence. The classic example: ice cream sales and drowning deaths both rise every summer, rising and falling together throughout the year. Nobody seriously believes ice cream causes drowning. Both are actually driven by a third factor — hot weather, which makes people buy more ice cream and also sends more people swimming, raising drowning risk. Mistaking that correlation for causation would lead you straight to a useless "fix": banning ice cream sales would do nothing to make swimming safer.

The Classic Trap

Watch for this pattern: whenever two things rise and fall together, it's tempting to assume one causes the other. Before you act on that assumption, ask what third factor might be driving both — that question alone catches most correlation-causation mistakes before they turn into bad decisions.

Cause-and-effect relationships rarely stop at a single link. One effect commonly becomes the cause of the next event, forming a chain. The diagram below lets you click through a real chain of causes and effects, from a first trigger down to the kind of underlying condition the next section calls a root cause.

Diagram: Cause-and-Effect Chain

Run the Cause-and-Effect Chain diagram fullscreen

Cause-and-Effect Chain

Type: diagram sim-id: cause-effect-chain
Library: Mermaid
Status: Specified

Purpose: Show a real multi-step cause-and-effect chain (a printer that jams every afternoon, traced back through its intermediate causes to its root cause) so learners can click each step to reveal why it leads to the next.

Bloom Taxonomy Level: Analyze Bloom Taxonomy Verb: Trace

Learning Objective: Given a chain of events, the learner will trace each cause to its effect and identify which link in the chain is the root cause versus a surface-level symptom (Bloom: Analyzing).

Visual style: Mermaid flowchart, top-to-bottom (graph TD), five rectangular nodes connected by arrows in a single chain: "Printer positioned near a sunny window" → "Afternoon sun warms the room" → "Paper stored nearby absorbs humidity" → "Damp paper sheets stick together" → "Printer jams (the symptom users report)."

Interactivity requirement: every node MUST have a Mermaid click directive (click NodeId call showInfo("node-id")) wired to a JavaScript callback that opens an infobox with that node's one-sentence explanation of why it leads to the next node in the chain. Clicking the final "Printer jams" node opens an infobox that explicitly labels it "Symptom — treating this alone does not stop it from recurring," and clicking the first node opens an infobox labeled "Root cause — removing this stops the whole chain."

Key labels and annotations: color the first node (the root cause) in a distinct accent color and the last node (the symptom) in a different accent color, with a small legend below the diagram reading "Root cause" and "Symptom" in matching colors, so the two ends of the chain are visually distinguishable even before clicking anything.

Color scheme: neutral gray for the three intermediate nodes, the book's accent orange for the root-cause node, and a warning red for the symptom node.

Implementation: Mermaid graph TD syntax embedded in the page's generated sim wrapper, with a small companion JavaScript showInfo(id) function (shared with other clickable-Mermaid diagrams in this book) that populates a <div> info panel below the diagram on each click.

From Symptom to Root Cause

When something goes wrong inside a system, what you notice first is rarely the true reason it happened. A symptom is an observable sign that something is wrong, without itself being the underlying reason. The root cause is the original, underlying condition that, if removed or corrected, would prevent the problem from recurring. Root cause analysis is the systematic practice of tracing a problem backward through its chain of causes and effects until you reach that underlying condition, rather than stopping at the first cause you find.

Picture an office where a shared printer jams almost every afternoon. The symptom is obvious: paper jams, and an error light blinks. A quick, symptom-level fix — clearing the jam and restocking paper — restores printing for an hour, then the jam returns. Root cause analysis pushes further: why does it jam every afternoon specifically? Investigation reveals that the printer sits near a window, and afternoon sun warms the room enough to make the paper slightly humid, causing sheets to stick together as they feed. The root cause isn't the printer at all — it's paper storage location relative to a heat source. Moving the paper supply away from the window, or relocating the printer, removes the true cause and stops the jams for good, while clearing jams one afternoon at a time never would.

One Question That Cuts Through Symptoms

Next time a "quick fix" keeps needing to be repeated, ask: "If I fixed this exact same way tomorrow, would it come back?" If the honest answer is yes, you've found a symptom, not a root cause — and it's worth digging one layer deeper before you act again.

Key Takeaways

You now have a working vocabulary for describing any system you encounter, in any domain:

• A system is a set of connected parts producing a behavior no single part could produce alone, and a subsystem is a complete system nested inside a larger one.
• A system boundary separates what's inside a system from its environment, and that boundary is a choice, not a fixed fact.
• Inputs, outputs, and throughput describe what crosses a boundary and what happens in between; open systems exchange matter and energy freely, while closed systems exchange only energy.
• Linear thinking looks for one cause and one effect; systems thinking looks for the web of interacting causes and feedback around a situation, informed by both reductionism (understanding the parts) and holism (understanding the whole).
• Complexity distinguishes complicated systems, which are hard but ultimately predictable, from truly complex systems, whose behavior can genuinely surprise even experts.
• Interconnection and interdependence explain why a disruption in one part of a system can ripple outward to parts that seem unrelated.
• Cause and effect reasoning is only as good as your ability to avoid mistaking correlation for causation, and to trace a symptom back to its true root cause through root cause analysis.

You've Built Your First Lens

Whoo-hoo! You just built the lens every later chapter will look through: you can now name a system's boundary, trace its inputs and outputs, and ask whether you're looking at a real root cause or just its latest symptom. That's this chapter fully handled — every idea ahead builds on exactly what you just learned.