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

You'll sign in first, then come straight back here.

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

You'll sign in first, then come straight back here.

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')

You'll sign in first, then come straight back here.