You cut the support backlog in half with a weekend blitz, and six weeks later it's back. You add a star engineer to the late project, and it slips again. The fix worked, briefly, and then the system quietly undid it. That recurring frustration is the clearest signal you're standing in a system, not looking at a one-off problem, and that the tools you need aren't harder work but a different way of seeing.

The quick version

  • Stocks are the things that accumulate (cash, headcount, trust, backlog). Flows are the rates that fill or drain them (hiring, attrition, sales, churn).
  • Stocks change slowly and only via flows, so a stock can keep falling even after you fix the inflow. That delay is where most management mistakes live.
  • Causal loops chain cause and effect back on themselves. Reinforcing loops amplify (snowballs); balancing loops resist and stabilise (thermostats).
  • The high-leverage move is rarely to push harder on the event. It's to change the loop structure or the goal driving it.

The idea in depth: structure drives behaviour

The discipline behind these words is system dynamics, created in the mid-1950s by MIT's Jay W. Forrester, an electrical engineer who turned a control-theory lens on management. His trigger was concrete: managers at a General Electric appliance plant could not explain why employment swung in a roughly three-year cycle even though demand was fairly steady. By hand-simulating the plant's own ordering and hiring rules, Forrester showed the oscillation came from the firm's internal structure, its stocks, flows and delays, not from the market (System Dynamics Society; MIT Sloan Management Review). He set it out in Industrial Dynamics (1961).

That is the one idea worth keeping close: structure drives behaviour. Swap the same people into the same broken structure and you tend to get the same broken result. So stop asking "who messed up?" The better question is "what arrangement of stocks, flows and loops would make this outcome almost inevitable?"

Stocks and flows: why your fixes drain away

A stock is anything that accumulates and that you could, in principle, count at a single moment: cash in the bank, people on the team, water in a bathtub, trust with a customer. A flow is the rate that changes it over time. The late Donella Meadows, lead author of The Limits to Growth and one of the field's clearest teachers, put the mechanics plainly in Thinking in Systems: A Primer (drafted in the 1990s, published posthumously in 2008, edited by Diana Wright): a stock rises when total inflow exceeds total outflow, falls when outflow exceeds inflow, and holds steady when they match (Chelsea Green).

flowchart LR
    in(["Inflow: hiring"]) ==> S(("Stock: team size"))
    S ==> out(["Outflow: attrition"])
    S -. "fills / drains over time" .-> S
A stock only ever changes through its flows, you cannot edit it directly. Leaders Loop

This sounds trivial and isn't. In a now-classic study, Linda Booth Sweeney and MIT's John Sterman showed business-school students a bathtub with simple graphs of its inflow and outflow, and asked them to sketch the water level over time. Many couldn't, fewer than half of these numerate, business-trained subjects got the basic pattern right ("Bathtub Dynamics," System Dynamics Review, 2000; PDF via MIT). The reliable error is to confuse the flow with the stock, and assume that slowing the inflow drops the level. It doesn't. As long as inflow still beats outflow, the stock keeps climbing, just more slowly.

A stock can keep falling for months after you've fixed the inflow. That lag is not a sign the fix failed, it's the system being a system.

So the move is to manage the flows and the delay, not just the headline number. If attrition (an outflow) is draining your team stock, hiring faster (a bigger inflow) papers over it but leaves you running to stand still; cutting the cause of attrition is the durable fix. Because the stock responds with a lag, you have to hold your nerve through the period where the chart hasn't moved yet. Most "the change didn't work, revert it" calls are really just impatience with stock-and-flow delay.

Causal loops: reinforcing snowballs, balancing thermostats

Stocks and flows don't sit still; they feed back on themselves. A causal loop is a closed chain where a change in something eventually comes back around to change that same thing again. There are exactly two flavours, and naming them is most of the skill.

A reinforcing loop (R) amplifies: more leads to more (or less to less). Happy customers refer others, who become happy customers, a snowball. So do vicious versions: an overloaded team ships bugs, bugs create support load, support load steals build time, which overloads the team further. Reinforcing loops are behind every "it came out of nowhere" growth and every death spiral.

A balancing loop (B) resists and seeks a goal, like a thermostat pulling a room back to a set temperature. It's why your weekend backlog blitz didn't last: clearing the queue made response times feel fine, urgency dropped, the team eased off, and the queue refilled to its comfortable level. The loop was defending a goal you never set on purpose. Meadows is blunt that balancing loops are "both sources of stability and sources of resistance to change", which is why so many improvement efforts feel like pushing a spring (Meadows, Thinking in Systems).

flowchart TD
    L(["Late project"]) ==> P(["Pressure to add people"])
    P ==> H(["New hires onboarded"])
    H ==> O(["Existing staff spend time training them"])
    O ==> L
    H -. "eventually adds capacity (delayed)" .-> C(("Delivery capacity"))
Brooks's Law as a balancing loop with a delay: adding people to a late project can make it later before it helps. Leaders Loop

So the move when a fix won't stick is to ask: which loop is undoing me, and what goal is it defending? If a balancing loop keeps restoring the old state, hammering the symptom harder just makes the loop push back harder. You change the goal (make a service-level target explicit and staffed to it) or you weaken the loop, rather than out-muscling it week after week. This connects directly to hypothesis-driven problem solving: "a hidden balancing loop is resetting our metric" is a testable hypothesis, not a vibe.

Leverage and the iceberg: where to push

Once you can see structure, the obvious question is where do I push to get the most change for the least effort? Meadows's most-cited essay, "Leverage Points: Places to Intervene in a System" (1999), ranks twelve such places from weakest to strongest. Her central, counter-intuitive finding: the interventions people reach for first, tweaking numbers like budgets, prices and targets, are the weakest. The strongest are the loop structures themselves, the goal of the system, and the mindset the whole thing rests on (The Donella Meadows Project).

A useful companion is the iceberg model, widely taught in the systems community: visible events sit on top of patterns (trends over time), which sit on structures (the stocks, flows and loops), which rest on mental models (the beliefs that keep the structure in place). React at the event line and you firefight forever; intervene lower and the fix holds (Ecochallenge / Academy for Systems Change).

flowchart TD
    E(["EVENTS, what just happened?"]) --> P(["PATTERNS, what keeps happening?"])
    P --> S(["STRUCTURE, what loops produce the pattern?"])
    S --> M(["MENTAL MODELS, what beliefs hold it in place?"])
    M -. "highest leverage" .-> S
The iceberg: most effort lands on events; durable change comes from the layers below. Leaders Loop, after the systems-thinking iceberg model

An honest limitation. Causal-loop diagrams are a thinking aid, not proof. They make your assumptions visible and arguable, but a clean diagram can be confidently wrong, and quantifying real stocks and flows is genuinely hard. Forrester and Sterman build simulation models precisely because intuition about delays and feedback is unreliable. Treat the diagram as a map for a better conversation, not a result. And like any mental model, systems thinking is one lens among several; pair it with first-principles and statistical reasoning rather than letting every problem become a loop diagram.

A worked example

A 40-person SaaS company has a growth problem dressed up as a sales problem. New-customer sign-ups are healthy, but revenue is flat. The instinct is to push the visible event: hire more sales reps, run more campaigns.

Drawn as stocks and flows, the picture changes. Active customers is a stock. The inflow is new sign-ups; the outflow is churn. Sign-ups are strong, so the leadership team has been staring at a healthy inflow and assuming the stock must be growing, the exact bathtub error from the Sterman study. But churn (the outflow) has crept up to nearly match sign-ups, so the customer stock is barely moving. (Figures here are illustrative.)

Now look for the loop. Onboarding is thin, so new customers struggle in week one; frustrated customers raise tickets; the small support team gets swamped; swamped support means even thinner help for the next cohort, a reinforcing churn loop quietly cancelling the sales engine. Hiring more reps pours water into a tub whose drain is wide open; worse, more sign-ups feed the overwhelmed support team and widen the drain.

The systemic move targets the outflow and the loop, not the event. Redirect a fraction of the sales budget into onboarding and early-life support; new customers succeed sooner, ticket load per cohort falls, support gets ahead, the next cohort lands better, the reinforcing loop now runs in your favour. Because active customers is a stock with a delay, revenue stays flat for a few weeks before it bends. A team that doesn't understand stock-and-flow lag kills this fix at week three; a team that does holds the line, and that patience is the whole edge.

Frequently asked questions

Isn't this just "think about root causes"?

It's that with a structure attached. Root-cause analysis tends to walk a linear chain backwards to a single culprit. Systems thinking insists the cause is often a loop, a circular structure with delays, so there may be no single root, and pushing on the obvious one can make things worse. The stock/flow/loop vocabulary is what lets you describe a circular cause precisely instead of waving at "it's complicated."

How is this different from first-principles thinking?

They're complementary lenses. First-principles reasoning breaks a problem down to fundamentals and rebuilds; systems thinking studies how the parts interact and feed back over time. Use first principles to question what a component should be, and systems thinking to understand why the assembled whole behaves as it does. See first principles vs heuristics vs analogical reasoning.

Do I need software or simulation to use this?

No, most of the value is in the literacy. Sketching a causal-loop diagram on a whiteboard with your team, labelling stocks, flows and the R/B loops, surfaces hidden delays and reinforcing traps in an hour. Formal simulation (Vensim, Stella, system-dynamics models) earns its keep when stakes are high and delays are long, because human intuition about feedback is demonstrably poor, but it's the deep end, not the entry point.

Why do my fixes work and then stop working?

Usually a balancing loop you didn't know you were fighting. It's defending an implicit goal, a comfortable backlog level, a habitual pace, and restores it once your push stops. Make the goal explicit and resource it, or change the loop; don't just push the symptom harder, because the loop will push back exactly as hard.

What's the single most common mistake?

Confusing a flow for a stock, assuming that slowing an inflow lowers the level. As long as inflow still exceeds outflow, the stock keeps rising. Emissions and atmospheric carbon are the textbook case; team morale, technical debt and cash run the same way.

Related in the Toolkit

Where to go next