03 · Systems Thinking for Leaders

A recurring problem that keeps recurring despite good people trying hard to fix it is almost never a people problem. It's a structure problem: an incentive, a feedback loop, or a handoff that quietly produces the bad outcome no matter who's standing in the role. Leaders who only look at symptoms cycle through blaming individuals, replacing them, and watching the same problem reappear under the next person's name. This module gives you a way to see the structure behind a recurring issue and change the structure instead of the person.

1. The tell: same problem, different people

If a role has had three people rotate through it in two years and each one eventually produced the same complaint from the same other team, the problem is not the three people — it's near-certainly the structure they were all placed into. Systems thinking starts with taking that possibility seriously before looking for who to blame.

2. The Loop Diagram

A lightweight way to map what's actually producing a recurring problem, without special software — three columns on paper.

LOOP DIAGRAM — recurring problem: ________________________

STEP 1: What happens first (the trigger)?
  ______________________________________________

STEP 2: Who responds, and what does their incentive push them
        to do — even if it's not the best outcome for the whole?
  ______________________________________________

STEP 3: What does that response cause downstream?
  ______________________________________________

STEP 4: Does the downstream effect feed back into step 1,
        making it worse, better, or the same next time?
  (REINFORCING = gets worse each cycle / BALANCING = self-corrects)
  ______________________________________________

THE LEVER: at which step could a structural change (not a
person change) break the loop?
  ______________________________________________

The critical discipline is step 2: naming the incentive that made the response rational for the person in it, even when the response looks irrational from outside. People are usually responding sensibly to the system they're actually in, not the one you assume they're in.

3. Worked example: the loop behind late deliveries

Marcus runs an engineering org. Every quarter, a different team lead misses a deadline the same way — they report "on track" until two weeks before the deadline, then reveal it's slipping by a month. Three different leads, same pattern. Marcus is in a retro with Elena, the latest one.

Marcus: Walk me through when you knew this was going to slip.

Elena: Honestly? About five weeks ago.

Marcus: And you reported green for four of those five weeks. Why?

Elena: Because the last person who reported yellow at week six got asked in the leadership sync, in front of everyone, what they were doing to "get back to green" — like yellow was a personal failure to fix quietly, not information. I didn't want that conversation, so I kept trying to fix it myself until I couldn't hide it anymore.

Marcus: So the incentive I built — a public sync where yellow gets treated as a discipline problem — is what's teaching every lead to hide yellow until it's red. That's on the structure, not on you specifically.

Elena: I mean, yes. Nobody wants to be the one who "couldn't execute" in front of the VP.

Marcus: Then the lever isn't "manage Elena's honesty better," it's changing what happens when someone reports yellow. Here's what I'll change: yellow status in the sync gets one question — "what do you need," not "why did this happen" — and I'll say that explicitly at the next sync so it's not just a private promise to you.

Marcus used the Loop Diagram in his head: trigger (deadline risk emerges), response (hide it, because yellow is punished), downstream effect (problem grows silently), feedback (worse public failure reinforces that yellow is dangerous, teaching the next lead the same lesson). The lever is at the response step — change what yellow means publicly, not who reports it.

4. Reinforcing loops vs. balancing loops

• Reinforcing loops amplify in one direction each cycle — hiding bad news makes the eventual reveal worse, which increases the incentive to hide next time. Left alone, these tend to explode into a crisis.
• Balancing loops self-correct — a team that overspends gets budget cut next quarter, which corrects the overspend. These are usually fine to leave alone; intervening in a balancing loop that's working can actually break something healthy.

The most common leadership mistake is treating a reinforcing loop as if it will self-correct ("they'll figure it out") when nothing in the structure pushes it back toward balance.

5. Stocks vs. flows: why "just work harder" doesn't fix backlogs

A useful systems distinction: a stock is an accumulated quantity (the backlog size, team trust, technical debt); a flow is the rate that adds to or drains it (tickets closed per week, promises kept per month). A leader who only manages the flow while ignoring the stock will find that heroic weekly effort never actually shrinks the backlog, because new work is entering the stock faster than the flow drains it. The fix is almost never "push the flow harder" — it's reducing what enters the stock (intake control) or accepting a larger stock is normal and managing expectations around it, rather than running the team at unsustainable flow indefinitely.

6. A caution: not everything is a system problem

Systems thinking becomes an excuse when it's used to avoid ever holding an individual accountable — "it's the system" can be true and can also be a shield for genuinely poor individual performance that persists after the structure is fixed. The test: if you fix the incentive and the problem still recurs with the same person but not with others rotated through the same structure, it has become an individual issue, and you should address it as one directly, using the tools from Level 2.

How It Actually Works

"Same problem, different people" is the diagnostic tell for a systems problem because it rules out the most common false explanation: individual deficiency. If a role, not a person, is what's failing — three successive good performers all struggle with the same handoff — the explanatory weight has to shift from individual competence (which varied across three people) to something structural that stayed constant across all three: an information gap, a misaligned incentive, or a feedback delay built into the process itself. This is a direct application of a statistical principle: when an outcome varies little despite a varying input (different people), the causal factor is more likely to lie in what didn't vary (the structure) than in what did.

Why reinforcing and balancing loops behave so differently, and why confusing them leads to wrong interventions. A reinforcing loop amplifies a deviation in the same direction each cycle (missed deadlines erode trust, eroded trust increases oversight, increased oversight slows the team down, slower work causes more missed deadlines) — mathematically, this is positive feedback, and without an external intervention it compounds rather than settling. A balancing loop pulls a system back toward a setpoint (a team naturally slows down as quality issues rise, which reduces the issues, which lets them speed up again) — negative feedback, which is self-correcting. Applying a balancing-loop intervention (just wait, it'll self-correct) to a reinforcing-loop problem lets the compounding continue unchecked; applying a reinforcing-loop intervention (push harder) to a balancing-loop problem fights a self-correcting mechanism that didn't need fighting. Diagnosing which loop type is active, using the actual causal map, is what determines which intervention direction is even plausible.

Why "just work harder" doesn't fix backlogs — the stock-and-flow distinction. A backlog is a stock — an accumulated quantity — that only changes based on the flow rates in and out of it (new work arriving vs. work completed). Working harder increases the outflow rate, but if the inflow rate is equal or growing (new requests keep arriving at the same or higher pace), the stock's steady-state size doesn't actually change — it just moves faster through a still-growing or still-full backlog. This is the same dynamic studied formally in system dynamics (Forrester): you cannot fix a stock problem by adjusting only one flow when the other flow is the actual driver, which is why sustained backlog problems usually require addressing intake (the inflow), not just throughput (the outflow).

Exercise

Pick a problem in your organization that has survived at least two different people trying to fix it. Run the Loop Diagram in section 2 on it, being rigorous about naming the real incentive in step 2 — the one that makes the unwanted behavior locally rational, not the one that's comfortable to write down. Identify one structural lever, distinct from "talk to the person again," and make that change this month.