Map and Change Complex Systems

Proof required

Submit a causal loop diagram (hand-drawn, Kumu, or Loopy) showing the reinforcing loops, balancing loops, delays, and stocks. Label each loop as reinforcing (R) or balancing (B) and give each a name that describes its mechanism. Submit a 300-word behaviour-over-time narrative: what pattern does this system tend to produce, why the reinforcing loop(s) produce that pattern, and where the delays create unexpected behaviours.

What gets checked

• Loop labels are causal, not correlational — 'more sales → more revenue → more marketing → more sales' is correlational if you haven't explained the causal mechanism at each step; 'more sales → more testimonials (R: Social Proof) → more prospect conversion → more sales' shows the mechanism
• Delays are named and quantified where possible — 'delay: hiring takes 3 months' is a named delay; 'delay' alone is not; quantification matters because delays determine whether a system oscillates or reaches equilibrium
• Behaviour-over-time narrative explains a counterintuitive result — the most common early system thinking failure is a narrative that just restates what the diagram shows; the goal is to explain a behaviour that would not be obvious without the diagram

Common mistakes

• A diagram that is an influence map rather than a causal loop diagram — an influence map shows what affects what; a causal loop diagram shows feedback loops, which means every element must eventually link back to an earlier element in a cycle; if the diagram has no cycles, it is not a system map
• Reinforcing loops that have no dampening mechanism — a diagram with 3 reinforcing loops and no balancing loop or constraint is almost certainly incomplete; real systems have limits on growth
• A behaviour-over-time narrative that describes the current state rather than the dynamic pattern — 'the system is currently producing low output' is a state description; 'the system tends to oscillate between overproduction and shortage because the production delay means corrections overshoot' is a dynamic description

Resources

What a verifier looks for

• Ask the submitter to trace the path of a specific perturbation through the diagram — 'if a new competitor entered the market, walk me through what the diagram predicts would happen over 12 months'; this tests whether the diagram is a genuinely operational model or a post-hoc rationalisation
• Ask which loop is most dominant and why — dominant loops determine whether a system grows, oscillates, or stabilises; a submitter who cannot name the dominant loop has not completed the analysis
• Ask where the biggest delay is and what would happen if it were halved — delays are the most powerful and least intuitive system element; understanding how delay changes behaviour is the core insight that separates system thinkers from pattern recognisers
• Ask what is missing from the diagram — all causal loop diagrams are simplifications; a submitter who can name what they chose to leave out has thought more carefully than one who believes the diagram is complete

Proof required

Submit the diagnostic report (600–1,500 words): problem description, causal loop diagram or annotated system map, the feedback structure that maintains the problem, the leverage point identified (with a specific systemic intervention — not a task or metric), and the systemic failure mode in previous interventions. Submit evidence the report was presented to decision-makers (a meeting agenda, email thread, or document-sharing receipt showing the audience).

What gets checked

• Leverage point is specific and systemic — 'better communication' is not a leverage point; 'changing the information delay between the field team and the product team from 6 weeks to 1 week, which would allow the balancing loop to respond before the reinforcing loop has already committed resources' is a systemic intervention at a specific structural point
• Previous intervention failure mode is explained structurally — 'previous solutions didn't work' is not an explanation; 'the previous intervention (hiring more support staff) addressed the output of the reinforcing loop without changing the structure that drives it — customer complaints feed into a priority queue that deprioritises root cause fixes, so adding staff increased throughput without changing the queue logic' is
• Report was presented to people with actual decision authority — presenting to peers is valuable but does not satisfy this requirement; the audience must include at least 1 person who could act on the diagnosis

Common mistakes

• Persistence of a problem explained by a single cause rather than a system structure — 'the problem persists because of bad leadership' is a single-cause explanation; a systemic diagnosis names the feedback structure that keeps even good leaders from solving it
• Leverage point that is a metric or a target rather than a structural change — 'set a target of reducing complaints by 20%' is not a leverage point in the systems thinking sense; leverage points change the structure of the system (a delay, a feedback signal, a rule, a goal) not the output of the system
• A report that was shared but not presented — sharing a document in Slack is not presenting a diagnosis; the presentation must involve a conversation where the audience can challenge the diagnosis

Resources

What a verifier looks for

• Ask the submitter what would change if the leverage point intervention were implemented — the answer must describe a structural change (a different delay, a new feedback signal, a changed rule) not just an expected output improvement
• Ask why the previous interventions addressed the wrong level — 'they treated a symptom not a cause' is insufficient; the response must name the specific structural element the previous interventions missed
• Ask who in the audience was most resistant to the diagnosis and why — persistent problems persist partly because the system structure is protected by stakeholders who benefit from it; a submitter who encountered no resistance probably did not present the diagnosis to the people whose decisions maintain the problem
• Reviewer minimum for M3: someone who has applied systems thinking in real organisations — not just someone who has read the books; the verification session should reveal whether the M2 diagnosis is actionable to a practitioner

Proof required

Submit your M1 diagram and M2 report plus the reviewer's written assessment: the diagram challenge and your response, the leverage point challenge and your response, the novel problem statement and your live systemic structure diagnosis, and their sign-off confirming their role and a live session.

What gets checked

• Diagram challenge response identifies the missing loop by naming its mechanism — not 'I should have included more loops' but 'I missed the employee burnout loop: as the system increases throughput pressure, experienced employees leave, tacit knowledge decreases, error rates increase, and throughput pressure increases further; this is a second reinforcing loop that accelerates the problem I diagnosed'
• Leverage point challenge response engages with Meadows' hierarchy — not 'my leverage point was good enough' but 'my intervention was at rules level (level 5); a higher-leverage intervention would be at goals level (level 3) — changing what the system optimises for — but that requires executive authority I don't have; I targeted the highest leverage point accessible to me'
• Novel problem live diagnosis names a candidate loop structure within 5 minutes — the diagnosis does not need to be complete, but it must be structural: 'this sounds like a fixes-that-fail archetype — a short-term fix relieves the symptom but makes the underlying condition worse; the most likely missing element is the delay between the fix and the unintended consequence'

Common mistakes

• Diagram challenge response that defends the original diagram rather than engaging with the missing loop — the reviewer has more system thinking experience; the correct response is to accept the challenge, name the missing mechanism, and describe how it changes the diagnosis
• Novel problem live diagnosis that describes the symptoms rather than the structure — 'it sounds like they have a resource problem' is a symptom description; 'the most likely structure is a reinforcing loop where understaffing increases error rates, which increases rework, which consumes the capacity that was meant for process improvement' is a structural hypothesis
• A reviewer who has studied systems thinking but not applied it to real organisational problems — the challenge questions require someone who has personally encountered the gap between the diagram and the decision-makers' reaction to it

Resources

What a verifier looks for

• The novel problem should be real and drawn from the reviewer's own experience — a real problem that the reviewer knows has a system structure produces a better live diagnosis session than a constructed example; the submitter doesn't know the answer, and neither does the reviewer need to reveal it
• After the live diagnosis, ask the submitter what additional information they would need before they would be confident in the diagnosis — this is the most important question in the session; knowing what you don't know is the defining skill of a mature system thinker
• Reviewer minimum qualification: 5+ years of applying system thinking to real organisational decisions — not purely academic or theoretical; must have experience of the gap between the diagram and the decision
• Ask the submitter what they find hardest about system thinking in practice — the honest answers (getting decision-makers to accept that there are no single causes; holding the time horizon long enough to see the feedback effects) are qualitatively different from the theoretical answers ('it's complex')