Map the System and Set Its Boundary

In the last chapter you learned to see a problem as part of a system and to spot the loops that keep it running. Seeing it in your head is a good start, but a system quickly gets too tangled to hold there. This chapter turns that seeing into a simple drawing you can point at, a system map, and then answers the question every map forces on you: where does the system stop? Get the map and its edge right, and you will know exactly what to work on and what to leave alone.

How Do You Draw a System as a Map?

A system map is a simple picture of a system: you draw each part as a box, sometimes called a node, and draw an arrow from one part to another whenever the first one affects the second. That is the whole idea. The boxes are the parts you already know how to find, the stakeholders, inputs, steps, and outputs from the last chapter. The arrows are the connections, the “this affects that” links that a bare list always hides.

Because you learned to spot feedback loops, your map can show them too. When the arrows lead you back to a box you already passed, you have drawn a loop, so you mark it. A map with its loops marked shows at a glance not just what the parts are, but how they push on each other and where a problem might be feeding itself.

This everyday drawing has a formal relative professionals call a causal loop diagram (CLD). You do not need its notation here; it is enough to know the name, so that if you meet a CLD later, you will recognize it as a more formal version of the same boxes-and-arrows idea.

Draw the Parts and the Connections, Step by Step

You can build a system map in four steps.

1. List the parts. Write down the stakeholders, inputs, steps, and outputs, and put each one in its own box.

2. Draw the arrows. For each pair of boxes, ask “does one affect the other?” If it does, draw an arrow from the cause to the thing it affects. Skip the pairs that do not connect.

3. Mark the loops. Follow the arrows. Wherever they circle back to a box you already passed, you have a feedback loop, so mark it and note whether it is reinforcing or balancing.

4. Note the boundary. Draw a line around the parts you are treating as inside the system, and leave the rest outside. Deciding where that line goes is the next section.

The order matters less than the habit: parts, then connections, then loops, then edge. Most beginners stop after the parts, which is exactly the bare list the last chapter warned against.

What Is a System Map Made Of?

It helps to see the convention once. A finished map shows a few labeled boxes for the parts, arrows for what affects what, one arrow path circling back to mark a feedback loop, and a dashed line drawn around the parts you are treating as inside the system, with anything out of scope left outside it.

Here is that convention written out as a simple text sketch. Read each arrow as “affects”:

[Box A] --> [Box B]        an arrow means "A affects B"
[Box B] --> [Box C]
[Box C] --> [Box A]        arrows circling back = a feedback loop
- - - - - - - - - - - -    dashed line = the boundary
[Box D]                    left outside the line = out of scope

That is the whole notation: a box is a part, an arrow means one part affects another, a set of arrows that circles back marks a feedback loop, the dashed line is the boundary, and anything drawn outside it is out of scope. Your own maps can be pen-and-paper sketches that follow exactly these conventions.

Where Does the System Stop?

Every map needs an edge. The boundary is the line you draw around the parts you will treat as inside the system, leaving everything else outside. It is a choice, not a fact, and it is one of the most important choices you make.

Draw the boundary too wide and the system becomes unsolvable. If “the neighborhood recycling problem” has to include the city’s waste policy, the companies that make the packaging, and national recycling law, you end up with a fascinating map and nothing you can actually change. Draw it too narrow and you cut out the very thing driving the problem. If you map only “the bins” and leave out the residents and the weekly collection, you have missed where the loop lives.

So how do you find the right edge? Lean on something you already learned. Back in Chapter 2 you sorted causes into the ones in reach, that you or the people with you can act on, and the ones out of reach, that sit with someone else or with forces no one nearby controls. A good boundary usually wraps around the in-reach causes and draws the line just past them, leaving the out-of-reach causes outside as context you have noted but are not trying to move.

Two signals tell you to adjust. If your map is full of boxes you can only shrug at, the boundary is too wide, so pull it in toward what you can act on. If a key arrow in your loop points to something you left outside the line, the boundary is too narrow, so widen it to bring that part in.

Watch for Second-Order Effects

There is one more thing a boundary makes visible: what happens just outside it when you change something inside. A second-order effect is a knock-on consequence, a change you cause in one part of the system that shows up somewhere else, often not where you were looking.

Here is the everyday shape of it. Suppose one checkout queue in a shop is slow, so you add a rule that sends anyone with more than ten items to a different till. The first queue speeds up, which is what you wanted. But the second queue now fills with full trolleys and grinds to a halt. You did not remove the wait, you moved it. That is a second-order effect.

They matter most right at the boundary, because that is where your changes leak into the parts you left outside. Before you commit to a fix, run one quick check: if I change this, what happens to the parts next to it? Naming a likely second-order effect ahead of time is far cheaper than discovering it after.

Map One Process and Defend Its Boundary

Let us build one map end to end, on an everyday setup.

The process. A community choir rehearses once a week in a hall booked for exactly two hours. Lately they never get through the evening’s songs.

Step 1, list the parts. The singers, the conductor, the two-hour room booking, the evening’s song list, and the warm-up that is meant to open each session.

Step 2, draw the arrows. The conductor sets the song list, which shapes what the singers rehearse. The room booking caps the time available. Chatting at the start pushes back the warm-up, which pushes back the songs.

Step 3, mark the loop. Here is the reinforcing loop: rehearsals start late, so time runs short, so the conductor trims the warm-up, so the singers are less ready and stop more often to fix mistakes, so the session runs even later, so the next week everyone expects a loose start and arrives even more relaxed. More lateness feeds more lateness.

Step 4, set the boundary. Inside: the singers, the conductor, the song list, the warm-up, and the two-hour slot. Outside: the choir’s public concerts, how new members are recruited, and the hall’s booking system. Why there? The late-start loop lives entirely inside the rehearsal, so those are the in-reach parts. The two-hour cap is fixed by the venue, out of reach, so it sits just outside the line as context.

One second-order effect. Suppose they fix late starts with a hard rule: the warm-up begins at seven sharp, latecomers or not. Anyone arriving late now misses the warm-up entirely and feels out of step, and a few drift away. Solving the lateness could quietly shrink attendance, a knock-on worth watching for.

Your Turn!

Now build a map of your own, using the choir map as your model.

Scenario. A neighborhood tool-lending library lets residents borrow things like drills, ladders, and garden tools for a few days at a time. Lately the most useful tools are almost never on the shelf, and people are starting to give up on it.

Your task. 1. List the main parts of this system, the stakeholders, inputs, steps, and outputs, and sketch each as a box. Draw arrows for what affects what. 2. Find and mark one feedback loop. Say whether it is reinforcing or balancing, and how you can tell. 3. Draw a boundary around the parts you would treat as inside the system. Then judge it: too wide, too narrow, or about right? Adjust it if you need to, and say why.

Do this in your own working document, on paper or on screen, and think it through yourself. Drawing the map and setting its edge is the exact skill this course is building, so resist the urge to hand it to an AI tool to do for you.

Then check your answer against the model solution found at the end of this chapter.

Let’s Recap!

• A system map draws each part as a box and each “this affects that” connection as an arrow, with any feedback loops marked.

• Build it in four steps: list the parts, draw the arrows, mark the loops, then set the boundary.

• The boundary is the edge of the system: too wide makes the problem unsolvable, too narrow leaves out what drives it.

• A good boundary usually wraps around the causes you can act on, keeping out-of-reach causes outside as context.

• A second-order effect is a knock-on change your fix causes elsewhere, most likely just across the boundary, so name it before you act.

You can now define a problem, trace it to a root cause, see it as a system, and map that system with a boundary. In the last chapter, you will watch all four moves run on a single everyday problem, from the first vague frustration to a finished map, exactly the way you will run them yourself.

Model Solution

Here is one strong way to map the tool-lending library. Yours does not need to match it box for box; it needs real parts, a real loop, and a defended edge.

The parts. Stakeholders: the borrowers and the volunteer who runs checkout. Inputs: the tools themselves and the opening hours. Steps: borrow, use, return, then check and repair. Output: how many useful tools are actually on the shelf.

The arrows and the loop. A borrower takes a tool, uses it, and returns it, sometimes late or damaged. The volunteer checks and repairs it before it goes back out. The reinforcing loop: tools come back late or broken, so fewer are available, so the popular ones are always out, so borrowers hang on to whatever they do grab “just in case,” so even fewer come back on time. Reinforcing, because scarcity feeds more scarcity.

The boundary. Inside: the tools, the borrowers, the volunteer, the borrow-and-return process, and the opening hours. Outside: the hardware shops nearby, what people are building at home, and the library’s funding. Too wide would be mapping “why the neighborhood does so much DIY.” Too narrow would be mapping only “the shelf” while leaving out returns, which is exactly where the loop lives, so the edge has to include the return-and-repair step.

Compare that with a bare list of tools and borrowers: it names the parts but hides the scarcity spiral. The map, with its loop and its boundary, shows both what to fix and how far to reach.