What is Connection Circles?

Map the elements of a system and the relationships between them — the simplest systems mapping tool

How does Connection Circles work?

Connection Circles provides a step-by-step process for evaluating your options and making a structured decision. Follow the guided steps above to work through the tool with your specific situation.

When should you use Connection Circles?

Use Connection Circles when you face a decision that would benefit from structured analysis rather than gut instinct. It is particularly valuable for high-stakes or irreversible decisions where the cost of being wrong is significant.

Connection Circles: How to Use It…

Connection Circles: How to Use It… | Faster Than Normal

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.

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.

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

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.

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 applied

Spotify'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 surfaced

The 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.

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

The Fifth [Discipline](/mental-models/discipline) — Peter Senge (1990)

Book

The 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.

Thinking in Systems: A Primer — Donella Meadows (2008)

Book

The 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.

Thinking, Fast and Slow — Daniel Kahneman (2011)

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.

Systems Thinking Playbook — Linda Booth Sweeney & Dennis Meadows (2010)

Book

A 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.

The Fifth Discipline Fieldbook — Peter Senge et al. (1994)

Book

The 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.

Connection Circles

Continue exploring

What This Tool Does

How to Use It — Step by Step

Define the system and list its key elements

B2B SaaS retention puzzle

Place elements around the perimeter of a circle

Arranging the SaaS elements

Draw arrows between elements that influence each other

Drawing the SaaS connections

Identify feedback loops and classify them

Loops in the SaaS system

Identify leverage points and design interventions

Finding the leverage point

When It Works Best

Ideal Conditions for Connection Circles

When It Breaks Down

Failure Modes

Visual Explanation

Pairs With

Real-World Application

Spotify — understanding the tension between squad autonomy and platform coherence

Analyst's Take

Top Resources

This connects to...

Continue exploring

More like this, in your inbox

What This Tool Does

How to Use It — Step by Step

Define the system and list its key elements

B2B SaaS retention puzzle

Place elements around the perimeter of a circle

Arranging the SaaS elements

Draw arrows between elements that influence each other

Drawing the SaaS connections

Identify feedback loops and classify them

Loops in the SaaS system

Identify leverage points and design interventions

Finding the leverage point

When It Works Best

Ideal Conditions for Connection Circles

When It Breaks Down

Failure Modes

Visual Explanation

Pairs With

Real-World Application

Spotify — understanding the tension between squad autonomy and platform coherence

Analyst's Take

Top Resources

This connects to...