Experience & Systems Mapping · Method
Systems Mapping
Modelling the feedback loops, delays, and leverage points that explain why a system keeps producing the same outcome, no matter how many times you fix it.
Time required
Several sessions with the people inside the system; days to weeks, not hours
Group size
The team inside the system — people who know what actually happens, not what is written down
The visual
Two loops. One explains why it always comes back.
A systems map contains VARIABLES that rise and fall and CAUSAL ARROWS showing what drives what. The arrows form CLOSED LOOPS, and this is what makes a systems map different from every other map on this site. A loop can feed itself, amplify itself, or resist change and restore a previous state. An ecosystem map shows who is in the system; a systems map shows why the system keeps doing what it does.
The diagram below shows two loops. The REINFORCING loop on the left amplifies — once running, it runs away. The BALANCING loop on the right resists — it absorbs interventions and restores the previous state. The DELAY on the cross-arrow is why nobody connects cause to symptom. The LEVERAGE POINT glows far from where the pain is felt.
What it is
A model of why, not a picture of who
Systems mapping models why a system behaves the way it does, and why it keeps doing it. Where every other mapping method produces a picture of an arrangement — who is connected to whom, what sits beneath a moment, how many paths there are — a systems map is a model of a DYNAMIC: it has time and causality in it, and it explains behavior rather than describing structure.
Its raw material is three things. FEEDBACK LOOPS are closed causal chains where an effect comes back around to influence its own cause. REINFORCING loops amplify: success breeds success, or decline breeds decline, and once running they run away. BALANCING loops resist: they pull the system back toward equilibrium, and they are the reason your intervention seemed to work and then quietly stopped working.
DELAYS are the gaps between a cause and its visible symptom, and they are the single greatest source of confident, wrong action — because when the delay is long enough, nobody connects the two. LEVERAGE POINTS are the places where a small change produces a large effect, which are reliably NOT where the pain is felt, and not where everyone is already pushing.
The core teaching
You cannot fix a system by attacking the symptom.
If a problem keeps returning after you solve it, you did not solve it. You disturbed a system whose structure produces that problem, and the structure recovered. Systems push back — the harder you push on the symptom, the harder the balancing loops push back. This is so reliable it has a name: policy resistance. The recurring problem is not evidence that people are not trying hard enough. It is evidence that the structure is intact.
The boundary with Ecosystem Mapping
An ecosystem map can show you a bottleneck. Only a systems map can tell you the bottleneck REGENERATES — every time you clear it — because a balancing loop restores it. Ecosystem mapping asks how the system is connected. Systems mapping asks why it keeps doing what it does. They are the cast and the wiring versus the physics.
Try it
Fix the symptom. Watch the system put it back. Then find the leverage.
The same two interventions, in the same system. One is what most organizations do, forever. One is what actually changes the outcome. The contrast is the whole point.
When to deploy
The signature symptom is a problem that keeps coming back
Systems mapping is worth the trouble when something specific is happening: a problem that returns after being solved, repeatedly, by competent people. That pattern is almost always structural — and structure is what this method finds.
Right moment
- —A problem keeps returning after being solved — this has happened more than twice
- —Interventions seem to work and then quietly stop working, or make things worse elsewhere
- —Cause and effect appear unrelated, or separated by long stretches of time
- —Everyone is already pushing hard on the obvious lever and nothing is moving
Wrong moment
- —The problem is genuinely simple and linear — not everything is a system
- —You need to know who is in the system and what flows between them (use Ecosystem Mapping first)
- —The organization will not act on a counterintuitive answer — the leverage point is always uncomfortable
- —You need an answer this week — building an honest model requires the people inside the system, and that takes time
The honest limit
A systems map is a model, and every model is wrong in some way that matters. Its loops are hypotheses about causality, not measurements of it — and a confident, elegant diagram of the wrong loops is one of the most persuasive ways to justify an intervention that cannot work. Hold it loosely, test its predictions against history, and be willing to redraw it. The method’s other limit is political: the real loops in an organization are frequently ones nobody wants to name out loud, because naming them implicates someone.
How it works
Build the model from the recurring behavior outward
Start from the recurring behavior, not the incident
Name the pattern that keeps happening. A systems map explains behavior over time, so it needs behavior over time as its subject — not the latest sprint, the pattern across the last year.
Identify the variables that actually move
Find the things that go up and down: workload, quality, trust, headcount, backlog, morale, technical debt. A variable is something with a level; if it cannot rise or fall, it does not belong on this map.
Draw the causal arrows honestly
For each pair, ask what genuinely drives what, and whether it strengthens or weakens. This is where most of the argument lives — teams routinely discover here that they disagree profoundly about what causes what. The argument is the work.
Close the loops, and name them
Follow the arrows until they come back around. A chain that does not close is not a feedback loop — it is a line, and lines do not explain recurring behavior. Then classify: REINFORCING (amplifying) or BALANCING (resisting)? The balancing loops are usually where the mystery lives.
Mark the delays, especially the long ones
Wherever a cause takes time to produce its symptom, mark it. Long delays are why organizations misattribute causes — finding one often explains an entire history of confident, failed interventions.
Find the leverage point
Look for where a small structural change would alter the loops themselves, rather than fighting their output. It is reliably not where the pain is, and often something unglamorous or politically awkward — which is why nobody has done it.
Test the model against history
Ask what the map predicts about the past. If these loops are real, the organization should have already seen X. If the model cannot explain history you already have, it is wrong — and far better to find that out now.
Best practices
What good looks like — and the mistakes
When it goes well
- ✓The subject is a recurring behavior, not a single incident
- ✓The loops actually CLOSE, and each is classified as reinforcing or balancing
- ✓DELAYS are marked, especially the long ones that have disguised causality for years
- ✓The leverage point is somewhere structurally distant from the pain, and the team is prepared to act there
- ✓The model is tested against history: if these loops are real, we should already have seen X
- ✓The map is held loosely as a hypothesis about causality, and redrawn when it fails
Mistake: Drawing lines instead of loops
A causal chain that does not come back around cannot explain a recurring problem. If nothing closes, you have drawn a flowchart, not a system.
Mistake: Attacking the symptom anyway
The most common outcome of a systems map is that the organization understands the structure and then goes and pushes harder on the symptom anyway, because that is what looks decisive. The balancing loop will absorb it, as it always has.
Mistake: Ignoring the delays
Unmarked delays are how a team confidently attributes today's symptom to last week's cause. Finding the delay is often the whole insight.
Mistake: Mistaking it for an ecosystem map
If your diagram is actors and value flows, you have drawn an ecosystem map with circular arrows. Systems maps contain VARIABLES that rise and fall, not actors.
Mistake: Believing the model
An elegant diagram of the wrong loops is powerfully persuasive and will justify an intervention that cannot work. Test predictions before acting on them.
Mistake: Avoiding the loops nobody wants to name
The real dynamics are often political and implicate people in the room. A map that includes only the comfortable loops explains nothing, because the uncomfortable ones are usually the load-bearing ones.
Logistics
Build it with the people inside — and expect argument
The causal arrows are where teams discover they disagree profoundly about what drives what. That disagreement is not an obstacle to the method — it IS the method. Surface it. A map produced by one analyst in isolation records one person’s theory.
Go looking for the loops nobody has written down. The documented causality is the organization’s official story about itself, and it is usually the story that has already failed to fix the problem. The real loops are found by asking people what actually happens, and by watching.
Keep it small enough to be readable. A diagram with forty variables explains nothing to anyone. Find the handful of variables and the two or three loops that genuinely drive the behavior. If the map is not legible on one page, it is not a model — it is a mural.
Mark delays explicitly and estimate them roughly. “Months” versus “years” changes everything about what the map means. A delay long enough to outlast the average tenure in a role will never be attributed correctly by the people in it. Common mapping tools include whiteboards, digital canvases (Miro, MURAL), and network-specific tools like Kumu — named as common examples, not endorsements.
AI & this method
AI draws the elegant version of the loops that have already failed
Toggle between the complete model and the AI-generated map. The contrast shows where AI genuinely helps — and why a confident diagram of the wrong loops is the most dangerous artifact the method can produce.
Example
A quality problem that three leaders could not fix
The traditional tab shows the two loops that explain two years of failure — the obvious balancing loop everyone knew and the reinforcing loop nobody had named. The AI tab shows what happens when the model is built from the description alone.
Shared scenario
An engineering organization has a quality problem that will not go away. Defects escape to customers; the team responds by adding review steps and pushing harder on testing. Quality improves for a quarter, then slides back. This has now happened three times over two years, with three different, competent leaders. Nobody can explain it. They map the system. Both versions map the same organization; only the method differs.
Both tabs map the same organization. Only the method differs.
Start from the recurring behavior, not the latest incident
The team started from the pattern — quality improves, then slides back, three times — and built the map with the engineers inside the system, which is where the argument, and the answer, came from. Variables: defect rate, delivery pressure, time spent testing, technical debt. The causal arrows were where the disagreement lived, and the disagreement was the work.
The obvious loop everyone already knew
The first loop was the obvious one — a BALANCING loop: defects rise, the organization adds review and testing, defects fall. Everyone already knew this loop. It is why every intervention worked, briefly. It is the organization’s entire theory of itself on the quality problem.
The loop nobody had articulated
The second was a REINFORCING loop, and it explained everything. Delivery pressure caused engineers to take shortcuts, which increased technical debt, which made the codebase harder to change safely, which slowed delivery, which increased delivery pressure further. Round and round, accelerating. And it operated with a long DELAY: the shortcuts taken this quarter produced defects two or three quarters later. By then nobody connected them, and the organization confidently attributed the defects to insufficient testing — the thing it could see — while the actual cause went unexamined.
Feeding the problem by fighting it
So each new leader had pushed on the symptom — more testing, more review — and the balancing loop had duly restored quality for a quarter, while the reinforcing loop underneath kept accelerating. The harder they pushed on testing, the more delivery time it consumed, the more pressure built, the more shortcuts were taken. They were feeding the problem by fighting it. Policy resistance, exactly as described.
The leverage point nobody had tried
The leverage point was nowhere near the pain. It was not in testing at all. It was in how work was committed to — reducing the pressure that generated the shortcuts. Unglamorous, politically awkward, and it looked, to anyone watching, like doing nothing about quality. Which is precisely why nobody had tried it for two years.
Frameworks
Where this sits in the wider process
The 2019 Double Diamond explicitly added a pre-diamond systems-mapping step: mapping actors, relationships, feedback loops, leverage points, and unintended consequences of potential interventions BEFORE entering the first diamond. This is a strong, deliberate link — the framework content names it directly.
In Design Thinking, empathy typically means understanding one person's experience. Systems mapping extends that to understanding the structural forces producing the problem — not just the felt experience, but the dynamics that explain why the felt experience keeps happening.
Structural dynamics are where durable opportunity — and durable failure — actually live. Understanding why a customer's system keeps producing the same problem is often what distinguishes a transformative engagement from a feature addition.
Why does the same impediment keep returning, sprint after sprint, after being resolved in multiple retros? If the answer is not obvious, a systems map is the right next step — the impediment is probably structural, and its cause is probably not where the team is looking.
Related methods
How Systems Mapping connects to the wider taxonomy
The reciprocal pair, and the distinction this page most needs to hold. An ecosystem map shows STRUCTURE: the actors and value flows — a picture of how the system is CONNECTED. A systems map models BEHAVIOR OVER TIME: the feedback loops, delays, and leverage points that explain why the system keeps producing the same outcome. Ecosystem is the cast and the wiring; systems is the physics. Ecosystem mapping usually comes first. Reach for systems mapping when a behavior is stubborn and recurring and nobody can work out why.
A different axis entirely — no overlap. A blueprint works in DEPTH: the layers beneath a moment in a journey. It explains why a MOMENT fails. A systems map works in CAUSALITY OVER TIME. It explains why the PROBLEM COMES BACK.
A different axis (BRANCHING: the paths through a thing), and a shared blind spot worth knowing. Like the real flow of a process, a system's real feedback loops are UNDOCUMENTED — and both methods find the truth by asking and watching the people inside, not by reading what is written down.
A natural companion. The balancing loops that defeat your interventions are frequently held in place by unexamined beliefs about how things must be done. Systems mapping finds the structure; Orthodoxies finds the belief holding the structure in place.
Downstream. A systems map produces a hypothesis about causality and a proposed leverage point — and both are assumptions. Treat the leverage point as a leap-of-faith assumption and test it before betting the organization on it.
Sources & further reading
Where to go deeper
Thinking in Systems
Donella Meadows · 2008
The essential and most readable introduction to feedback loops, delays, and leverage points — and the source of the leverage-point insight this page is built around.
The Fifth Discipline
Peter Senge · 1990
For systems thinking in organizations, and the archetypes — including "fixes that fail" and "shifting the burden" — that describe most recurring corporate problems.
Systems Thinking for Social Change
David Peter Stroh · 2015
A practical guide to building causal loop maps with the people inside the system, and to navigating the political reality that the real loops are often ones nobody wants to name.
Experience & Systems Mapping — Method 6 of 6
40 methods across 6 stage groups