Contents
Use this when you suspect a problem is systemic but can't see the connections — when the variables are clear enough to list but the relationships between them remain invisible. Connection Circles force you to map how elements in a system influence each other, revealing feedback loops and hidden dependencies that linear thinking consistently misses.
Section 1
What This Tool Does
Most people think in lists. When confronted with a complex situation — declining user engagement, a supply chain that keeps breaking in new places, a team that ships features but never moves the metric — the instinct is to enumerate the factors. Pricing. Competition. Onboarding friction. Engineering velocity. The list grows. Each item sits in its own row, isolated, waiting for someone to prioritise it. And that's where the thinking stalls, because the real problem was never any single item on the list. The real problem is how those items interact.
Connection Circles emerged from the systems thinking tradition, most directly from the work of practitioners at the MIT Sloan School of Management and the Waters Foundation, which adapted systems dynamics tools for broader use. The technique is deliberately primitive — a circle, a set of elements written around its perimeter, and arrows drawn between elements that influence each other. No software required. No mathematical modelling. Just a group of people with a whiteboard, forcing themselves to answer one deceptively difficult question for every pair of elements: "Does this thing change that thing? And if so, in which direction?"
The mechanism is almost embarrassingly simple, which is precisely why it works. You write 5–10 key variables around the circumference of a circle. Then you draw directed arrows from each element to every other element it causally influences, marking each arrow with a "+" (same direction — when A increases, B increases) or a "−" (opposite direction — when A increases, B decreases). What emerges is a web of relationships. And within that web, you start to see loops — chains of influence that circle back on themselves, either amplifying (reinforcing loops) or stabilising (balancing loops). The core cognitive shift is this: you stop seeing a collection of independent problems and start seeing a system of interdependent behaviours, where intervening on one element ripples through every element it touches. That shift changes which interventions you choose, which metrics you watch, and which "obvious" fixes you learn to distrust.
Connection Circles sit at the entry point of systems mapping. They're less rigorous than formal Causal Loop Diagrams and far less technical than Stock and Flow models. That's the point. They're designed to be the first systems tool a team reaches for — the one that requires no training in systems dynamics notation, no specialised software, no facilitator with a PhD. A product manager, a founder, a department head can draw one in fifteen minutes and surface structural insights that months of linear analysis missed. The tradeoff is real: Connection Circles sacrifice precision for accessibility. They won't give you simulation-ready models. But they will show you where the feedback loops are hiding, and that's usually enough to stop you from making the most expensive mistake available — optimising a single variable in a system where everything is connected to everything else.
Section 2
How to Use It — Step by Step
Instructions on the left. Worked example — "Why is our B2B SaaS company growing revenue but seeing net revenue retention decline quarter over quarter?" — on the right.
Step 1 — Bound
Define the system and list its key elements
Start by naming the system you're trying to understand. Not "everything about the business" — a specific dynamic, tension, or pattern you want to explain. Then brainstorm the 5–10 most important variables that participate in that dynamic. These should be things that can increase or decrease — measurable quantities or observable states, not static categories. "Customer support" is a category. "Support response time" is a variable. "Engineering team" is a noun. "Engineering capacity allocated to new features" is something that moves. Aim for 6–8 elements on your first pass. Fewer than five produces a trivially simple map. More than ten becomes unreadable.
Worked example
B2B SaaS retention puzzle
System: "The dynamic between growth investment and customer retention at a Series B SaaS company doing $18M ARR."
Elements identified: (1) New customer acquisition rate, (2) Sales team headcount, (3) Engineering capacity on new features, (4) Engineering capacity on product stability/bugs, (5) Product reliability (uptime, bug count), (6) Customer satisfaction, (7) Churn rate, (8) Revenue. Eight variables, each one something that rises or falls.
Step 2 — Arrange
Place elements around the perimeter of a circle
Draw a large circle on a whiteboard, flip chart, or digital canvas. Space your elements evenly around the circumference. Physical spacing doesn't encode meaning — it's just a layout convention that makes the arrows readable. Write each element clearly. If you're working with a team, this is the moment to confirm that everyone agrees on what each element means. "Product reliability" might mean uptime to the engineering lead and bug count to the support manager. Resolve ambiguity now, not after you've drawn thirty arrows.
Worked example
Arranging the SaaS elements
Eight elements spaced evenly around a circle, roughly at clock positions: New customer acquisition (12 o'clock), Sales headcount (1:30), Engineering on new features (3), Engineering on stability (4:30), Product reliability (6), Customer satisfaction (7:30), Churn rate (9), Revenue (10:30). The team confirms: "Product reliability" means a composite of uptime percentage and open P1/P2 bug count. "Customer satisfaction" means NPS as measured quarterly.
Step 3 — Connect
Draw arrows between elements that influence each other
This is where the real thinking happens. Take each element in turn and ask: "When this element increases, which other elements change as a direct result?" Draw an arrow from the cause to the effect. Label it "+" if the effect moves in the same direction (A goes up, B goes up) or "−" if it moves in the opposite direction (A goes up, B goes down). Be disciplined about directness — you want causal influence, not mere correlation. If A only affects C through B, draw A→B and B→C, not A→C. Skip pairs with no meaningful causal link. Not everything connects to everything. The goal is an honest map, not a maximally dense one.
Worked example
Drawing the SaaS connections
Revenue → Sales headcount (+): More revenue funds more sales hires. Sales headcount → New customer acquisition (+): More reps, more deals closed. New customer acquisition → Revenue (+): More customers, more ARR. That's one loop already visible. Continue: New customer acquisition → Engineering on new features (+): More customers create pressure for feature requests. Engineering on new features → Engineering on stability (−): Engineering time is finite; more feature work means less stability work. Engineering on stability → Product reliability (+): More stability investment improves reliability. Product reliability → Customer satisfaction (+): Reliable product, happier customers. Customer satisfaction → Churn rate (−): Satisfied customers churn less. Churn rate → Revenue (−): Higher churn erodes ARR. The team also draws: Product reliability → New customer acquisition (+): Word of mouth and case studies from reliable product help close deals.
Step 4 — Trace
Identify feedback loops and classify them
Now step back and trace the loops. Follow the arrows in chains until you return to an element you've already visited. For each loop, count the number of "−" arrows. An even number of negatives (including zero) means the loop is reinforcing — it amplifies change. An odd number means it's balancing — it resists change and pushes toward equilibrium. Name each loop with a short phrase that captures its behaviour. These names become the shared vocabulary your team uses to discuss system dynamics going forward.
Worked example
Loops in the SaaS system
Loop 1 — "Growth Engine" (reinforcing): Revenue → Sales headcount → New customer acquisition → Revenue. All "+" arrows. More revenue funds more sales, which brings more customers, which generates more revenue. This is the loop the board sees.
Loop 2 — "Reliability Death Spiral" (reinforcing, but in the wrong direction): New customer acquisition ↑ → Engineering on new features ↑ → Engineering on stability ↓ → Product reliability ↓ → Customer satisfaction ↓ → Churn rate ↑ → Revenue ↓. Count the negatives: three "−" signs. Odd number = balancing? Not quite — trace the direction of change. When acquisition increases, this chain amplifies revenue decline through churn. It's a reinforcing loop running in a destructive direction. The team names it the "Reliability Death Spiral."
Loop 3 — "Reputation Flywheel" (reinforcing): Product reliability → Customer satisfaction → Churn rate (−) → Revenue → Engineering on stability → Product reliability. When reliability is high, this loop reinforces growth. When it's low, it reinforces decline.
Step 5 — Interpret
Identify leverage points and design interventions
The loops tell you where the system is vulnerable and where small interventions can produce outsized effects. Look for elements that appear in multiple loops — these are leverage points. Look for loops that are currently dominant — the one that's actually driving the behaviour you observe. Then ask: what would it take to weaken the destructive loop or strengthen the virtuous one? The best interventions change the structure of the system, not just the value of a single variable. Adding a new connection, breaking an existing one, or introducing a delay can shift which loop dominates.
Worked example
Finding the leverage point
"Engineering on stability" appears in both the Reliability Death Spiral and the Reputation Flywheel. It's the pivot point. The current policy — letting customer acquisition pressure dictate engineering allocation — means the Growth Engine loop is starving the Reputation Flywheel and feeding the Death Spiral. The intervention: ring-fence 30% of engineering capacity for stability work regardless of feature demand. This breaks the direct link between acquisition pressure and stability underinvestment. It doesn't slow growth — it prevents growth from destroying the retention that makes growth sustainable. The team also identifies a structural addition: a new connection from Churn rate back to Engineering on stability, formalised as a policy that any quarter where churn exceeds a threshold automatically triggers a reallocation of engineering resources. This creates a balancing loop that didn't previously exist.
Section 3
When It Works Best
✓
Ideal Conditions for Connection Circles
| Dimension | Best fit |
|---|---|
| Problem type | Situations where multiple variables interact and the observed behaviour seems paradoxical or counterintuitive — growing revenue but declining retention, increasing marketing spend but flattening conversion, hiring more people but shipping slower. These are symptoms of feedback loops, and Connection Circles are built to make those loops visible. |
| Team familiarity with systems thinking | Low to moderate. This is the on-ramp tool. Teams that have never drawn a causal loop diagram can produce a useful Connection Circle in 30 minutes. The notation is intuitive — arrows and plus/minus signs. No training in systems dynamics required, which makes it the right choice when you need systems insight from a group that doesn't speak systems language. |
| Number of variables | Sweet spot is 6–10 elements. Fewer than five and the map is trivially obvious. More than twelve and the arrows become an unreadable tangle. If your system genuinely has twenty important variables, use Connection Circles to identify the most important subsystem first, then model that subsystem in more detail with Causal Loop Diagrams. |
| Decision stage | Early sensemaking — when the team is trying to understand why something is happening before deciding what to do about it. Connection Circles are diagnostic, not prescriptive. They reveal structure. The intervention design comes after the map is drawn. |
| Stakeholder alignment | Especially valuable when different functions hold different mental models of the same system. Sales thinks the problem is product. Product thinks the problem is support. Support thinks the problem is sales overpromising. The Connection Circle forces all three perspectives onto one map, making the interactions between their domains visible for the first time. |
| Time available | 30–90 minutes for a useful first draft. Unlike formal systems modelling, which can take days, Connection Circles deliver insight within a single working session. The speed-to-insight ratio is the tool's primary advantage over more rigorous alternatives. |
Section 4
When It Breaks Down
⚠
Failure Modes
| Failure pattern | What goes wrong | What to use instead |
|---|---|---|
| Everything connects to everything | Teams draw arrows between every pair of elements, producing a web so dense it communicates nothing. The map looks impressive and is analytically useless. This usually means the elements are too abstract ("culture," "strategy") or the team isn't distinguishing direct causation from indirect influence. | Tighten element definitions to measurable variables; enforce a "direct influence only" rule; reduce to 6–7 elements |
| Missing polarity discipline | Arrows are drawn without "+" or "−" labels, or labels are applied inconsistently. Without polarity, you cannot classify loops as reinforcing or balancing — which means you cannot identify whether the system amplifies or dampens change. The map becomes a relationship diagram, not a causal model. | Enforce polarity labelling on every arrow before moving to loop identification; use the test "when A increases, does B increase (+) or decrease (−)?" |
| Static snapshot bias | The circle captures relationships as they exist today but ignores delays. In reality, the arrow from "engineering investment" to "product reliability" has a 3–6 month lag. The arrow from "churn" to "revenue impact" might take a quarter to materialise. Connection Circles have no native mechanism for representing time delays, which can lead to interventions that look right on the map but fail because the timing is wrong. | Annotate critical arrows with estimated delay times; graduate to Causal Loop Diagrams or Stock and Flow Diagrams for time-sensitive analysis |
| Confusing correlation with causation | Two variables move together, so the team draws an arrow. But co-movement isn't causation — both might be driven by a third variable not on the map. Connection Circles offer no statistical test for causality. The map reflects the team's beliefs about causation, which may be wrong. | Treat the map as a hypothesis generator; validate key arrows with data before designing interventions; use 5 Whys to pressure-test causal claims |
| Omitted variables | The most important element in the system isn't on the circle because nobody thought to include it. The map is internally consistent but structurally incomplete. This is especially dangerous when the missing variable is something the team doesn't control — a competitor's behaviour, a regulatory change, a macroeconomic shift. | Include at least one external/environmental variable; run a "what's missing?" check after the first draft; invite an outsider to review the element list |
| Premature precision | Teams try to quantify the strength of each connection ("this arrow is a 7 out of 10") without the data to support it. Connection Circles are qualitative tools. Bolting pseudo-quantitative scores onto them creates false confidence in the model's accuracy. | Keep Connection Circles qualitative; if you need quantitative modelling, graduate to Stock and Flow Diagrams with simulation software |
The most dangerous failure mode is everything connects to everything — and it's the one that feels most productive while it's happening. The team is engaged, arrows are flying, the whiteboard looks like a complex systems map. But density is not insight. A Connection Circle where every element connects to every other element is informationally equivalent to saying "it's all related" — which is what you already knew before you started. The discipline that prevents this: before drawing any arrow, the facilitator asks "Can you describe the specific mechanism by which A changes B?" If the answer is vague — "well, they're kind of related" — the arrow doesn't get drawn. Mechanism specificity is the quality filter. Without it, the tool produces a hairball instead of a map.
Section 5
Visual Explanation
Connection Circle — B2B SaaS retention puzzle. Arrows show causal influence with polarity (+/−). Two feedback loops are highlighted: the Growth Engine (gold) and the Reliability Death Spiral (red).
Section 6
Pairs With
Connection Circles are a sensemaking tool, not a decision-making tool. They reveal structure. What you do with that structure depends on what you pair them with.
Use before
5 Whys
Before drawing the circle, use 5 Whys on the presenting symptom to generate candidate elements. "Revenue retention is declining" — why? Because churn increased. Why? Because satisfaction dropped. Why? Because reliability degraded. Each "why" answer becomes a potential element on the circle. The 5 Whys gives you the raw material; the Connection Circle reveals how those materials interact.
Use before
Iceberg Model
The Iceberg Model asks what patterns, structures, and mental models lie beneath a visible event. Connection Circles operate at the "structure" level of the iceberg — mapping the systemic relationships that produce the patterns you observe. Use the Iceberg Model to ensure you're mapping the right layer of the system, not just the surface events.
Use after
Causal Loop Diagrams
When a Connection Circle reveals important feedback loops, graduate to a formal Causal Loop Diagram to model them with proper notation — including delays, loop labels, and archetype identification. The Connection Circle is the sketch; the CLD is the architectural drawing.
Use after
Second-Order Thinking
Once the circle shows you the feedback loops, Second-Order Thinking helps you trace the consequences of any proposed intervention through those loops. "If we ring-fence engineering capacity, what happens to feature velocity? And what does reduced feature velocity do to competitive positioning? And what does that do to acquisition?" The circle provides the map; second-order thinking walks the paths.
Use after
Impact-Effort Matrix
A Connection Circle often surfaces multiple leverage points. The Impact-Effort Matrix helps you prioritise which ones to act on first — high-impact structural changes that are feasible now versus deep systemic rewiring that requires months of investment.
Mental model
System Archetypes
System Archetypes are recurring patterns of feedback loop behaviour — "Fixes That Fail," "Shifting the Burden," "Limits to Growth." Once your Connection Circle reveals a loop structure, check it against the archetype library. If your system matches a known archetype, decades of systems thinking research can tell you what happens next and which interventions work.
Section 7
Real-World Application
Spotify — understanding the tension between squad autonomy and platform coherence
The scenario
By 2014, Spotify's "squad model" — small, autonomous cross-functional teams each owning a feature area — had become the most discussed organisational design in tech. The model was working brilliantly for speed of iteration. Individual squads shipped fast, experimented freely, and felt genuine ownership. But a systemic problem was emerging that no single squad could see: as the number of squads grew past 50, the overall product experience was becoming inconsistent. Design patterns diverged. Shared infrastructure accumulated technical debt because no squad "owned" it. Onboarding new engineers was taking longer because every squad had different tooling. The paradox was visible in the metrics: individual squad velocity was high, but platform-level reliability and coherence were declining.
How the tool appliedSpotify's engineering leadership used systems mapping exercises — including Connection Circle-style workshops — to make the feedback dynamics visible across the organisation. The elements they mapped included: squad autonomy, squad count, shared infrastructure quality, cross-squad coordination cost, engineer onboarding time, individual squad velocity, platform reliability, and user-facing consistency. The connections revealed two competing loops. A reinforcing "autonomy flywheel": squad autonomy → squad velocity → feature output → user growth → more squads → more autonomy. And a balancing loop that was slowly winning: squad count → coordination cost → shared infrastructure neglect → platform reliability decline → user experience degradation → growth slowdown.
What it surfacedThe critical insight was that "shared infrastructure quality" was a leverage point sitting in both loops but owned by neither. No squad had incentives to invest in it because their metrics were squad-level. The systems map made visible what Henrik Kniberg and Anders Ivarsson had described in their widely circulated 2012 whitepaper on the Spotify model: the need for "chapters" and "guilds" — cross-cutting structures that created ownership for shared concerns without undermining squad autonomy. The Connection Circle-style analysis showed why those structures were necessary in systemic terms, not just organisational ones.
The non-obvious factorWhat made this application instructive wasn't the sophistication of the mapping — it was the audience. Spotify's engineers were deeply sceptical of top-down organisational mandates. A directive from leadership saying "we need more cross-squad coordination" would have been resisted as bureaucratic overhead. But when the same engineers drew the system map themselves and saw the feedback loops with their own hands, the conclusion was self-evident. The Connection Circle didn't tell them what to do. It showed them the structure they were operating within, and the intervention — investing in platform teams and shared infrastructure ownership — emerged from the map rather than from a management decree. The tool's simplicity was the feature: engineers who would have dismissed a consultant's slide deck engaged deeply with a whiteboard exercise they could critique and modify in real time.
Section 8
Analyst's Take
Faster Than Normal — Editorial View
Connection Circles persist because they solve the right problem at the right altitude. Most teams don't need a simulation model. They need to see the loops. They need the sales leader to understand that her hiring plan affects engineering allocation, which affects product reliability, which affects the churn rate that erodes the revenue her hires are supposed to generate. That chain of influence is invisible in a spreadsheet, invisible in a KPI dashboard, invisible in every status update and quarterly review. A Connection Circle makes it visible in fifteen minutes with a marker and a whiteboard. The tool's lack of mathematical rigour is not a weakness — it's a design choice that maximises the number of people who can participate in systems thinking. And participation is the mechanism. A systems map drawn by one analyst and presented to a team is a slide. A systems map drawn by the team together is a shared mental model.
The failure I see most often: teams draw the circle, identify the loops, nod sagely, and then go back to optimising individual variables as if the map didn't exist. The Connection Circle reveals that engineering allocation is a leverage point, and the next week's sprint planning ignores it entirely because the feature roadmap was already committed. The map doesn't change behaviour unless it changes decisions. The fix is to anchor the circle's output to a specific upcoming decision — "Given this system structure, how should we allocate the next quarter's engineering capacity?" — rather than treating it as a standalone sensemaking exercise. A Connection Circle without a decision attached to it is an interesting conversation. With a decision attached, it's a strategic tool.
The highest-leverage modification I've found: draw the circle twice. First, draw the system as it operates today — the current connections, the current loops, the current dominant dynamics. Then draw it again as you want it to operate — with new connections added, old connections weakened, and different loops dominant. The gap between the two maps is your strategic agenda. It tells you exactly which structural changes you need to make, which new feedback mechanisms to create, and which existing dynamics to disrupt. Most teams only draw the first map. The second map is where the strategy lives.
Section 9
Top Resources
01
The Fifth [Discipline](/mental-models/discipline) — Peter Senge (1990)
BookThe foundational text for systems thinking in organisations. Senge introduced Connection Circles and causal loop thinking to a management audience, embedding them within his broader framework of learning organisations. Chapters 5–7 cover the core systems tools, including the circle-and-arrow mapping approach. Dense but essential — this is where the modern practice of organisational systems mapping begins.
02
Thinking in Systems: A Primer — Donella Meadows (2008)
BookThe most accessible introduction to systems thinking ever written. Meadows — one of the original authors of The Limits to Growth — explains feedback loops, leverage points, and system behaviour with extraordinary clarity. Her chapter on leverage points ("Places to Intervene in a System") is the single best guide to translating a Connection Circle's output into effective interventions. Read this before you facilitate your first session.
03
Book
Not a systems thinking book, but essential for understanding why Connection Circles are necessary. Kahneman's research on how humans default to linear causal narratives — A causes B, full stop — explains the cognitive bias that systems mapping tools are designed to override. The sections on the "what you see is all there is" heuristic are particularly relevant: Connection Circles force you to see what you'd otherwise ignore.
04
Systems Thinking Playbook — Linda Booth Sweeney & Dennis Meadows (2010)
BookA collection of 30 short exercises designed to build systems thinking intuition, many of which use Connection Circle-style mapping as their core activity. Ideal for facilitators who want to run systems mapping workshops but need structured exercises rather than open-ended whiteboard sessions. Each exercise includes facilitation notes, common pitfalls, and debrief questions.
05
The Fifth Discipline Fieldbook — Peter Senge et al. (1994)
BookThe practical companion to The Fifth Discipline. Where the original book explains the theory, the Fieldbook provides step-by-step facilitation guides for Connection Circles, causal loop diagrams, and system archetype identification. Includes worked examples from companies including Ford, Federal Express, and Intel. The "Systems Thinking" section (Part III) is the most directly useful reference for anyone facilitating their first Connection Circle session.
Decision Tools Library — Browse by phase
Why this matters next
mental modelsIncentives
5 Whys applied the Incentives mental model
mental modelsSecond-Order Thinking
5 Whys applied the Second-Order Thinking mental model
mental modelsLeverage
5 Whys applied the Leverage mental model
mental modelsTechnical Debt
5 Whys applied the Technical Debt mental model
mental models5 Whys
5 Whys applied the 5 Whys mental model
mental modelsSystems Thinking
5 Whys applied the Systems Thinking mental model
Continue exploring
CDRLBLSDCMSA
Decision tool
Causal Loop Diagrams
Formally map cause-and-effect relationships with polarity to show how variables
Decision tool
Reinforcing Feedback Loop
Understand the mechanism behind exponential growth and vicious/virtuous cycles
Decision tool
Balancing Feedback Loop
Understand the mechanism that pushes back against change to create stability or
Decision tool
Stock and Flow Diagrams
Model how things accumulate (stocks) and change over time (flows) — the bathtub
Decision tool
Concept Map
Visualise relationships between entities in a concept or domain to build shared
Decision tool
System Archetypes
Recognise recurring structural patterns — Fixes that Fail, Shifting the Burden,
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.