Structure, not intent, drives behaviour
2026-07-24 · What Counts as Complex
The same person becomes someone else in a new role; the same team grows a new temperament when you rewire one reporting path. We're used to blaming behaviour on who and what they want — yet for a whole class of problems, no matter who you put in and how badly they want to do well, the outcome is the same. Because what decides it isn't the person on stage, it's how the wires backstage are hooked up.
You turn the hot tap in the shower; the water's still cold, so you turn it more; still cold — and just as you've got it about right, scalding water arrives, you crank it back, overshoot, and now it's freezing. Every single move was toward "just right," yet you keep flip-flopping between cold and hot. You're not clumsy: there's a delay in the pipe, and you're wrestling a system that answers you late.
This topic is about exactly that structure — where your action loops around and comes back to you: the feedback loop. It's the plainest, and most underrated, link in this site's throughline of "local rules growing into whole-system behaviour": how a system will move often depends not on what pushes it from outside, but on how these internal loops are wired. Fix the wiring and you fix the behaviour — growth, collapse, endless oscillation are all the inevitable output of a particular way of hooking things up, and have little to do with who's sitting inside.
The conclusion is faintly offensive: much of the time, scolding is useless. Swap out the person who "messed it up" and their replacement will mostly mess it up the same way — because it's the loop that fails, not the person. To change the outcome, you have to change the wiring.
There are only two kinds of feedback. Learn both and you're set for life.
One says "the more, the more" — positive feedback, also called a reinforcing loop. Interest on a bank balance: more money makes more interest, the interest becomes principal, which makes still more interest. The squeal when a microphone gets too close to a speaker: the speaker amplifies what the mic picks up, the mic picks that up and amplifies it again, screaming within a fraction of a second. Positive feedback doesn't care about good or bad — it only amplifies: rolling small differences into large ones, pushing a deviation ever further out. Its signature behaviour is explosive growth, or headlong collapse.
The other says "the more, the less" — negative feedback, also called a balancing loop. A home thermostat: cold, so it heats; reaches the setpoint, so it stops; overshoots, so it stays off longer. Its job is to correct — to drag the system toward a target, damping what's too high, lifting what's too low. Its signature behaviour is stability: small wobbles around a target, never wandering far. Almost everything inside your body is run by negative feedback — temperature, blood sugar, blood pressure — a crowd of invisible thermostats pinning you into the narrow band where you can stay alive.
Note that "positive/negative" has nothing to do with good or bad. Positive feedback can be enriching compound interest or a bank run; negative feedback can be life-saving thermoregulation or a ceiling you can't break through however hard you try. The name describes the wiring — self-amplifying or self-correcting — not whether it's good for you.
This already gives us the topic's most important sentence: the shape of behaviour is set by how the loop is wired, not by anyone's effort or intent. A system full of positive feedback can't be stabilized by wanting harder; a system locked by negative feedback just pushes back harder when you push it. So before you reach for "try harder," ask: which kind of loop am I standing in?
When a result keeps recurring and doesn't improve no matter who you swap in, don't rush to ask "who failed." First draw it as a ring of arrows: does A raise B, and does B come back to raise A or damp it? Same-direction (positive) → what you need is how to break the loop before it snowballs, not to push harder with it; opposite-direction (negative) → either move the setpoint or accept it will just wobble nearby, and stop expecting it to travel. Scolding won't rewire a loop; changing the wiring will.
For a loop to move, something has to accumulate — and what accumulates is the memory that lets the past shape the present.
System dynamics splits this into two things → ref · System Dynamics: a stock is the amount sitting there; a flow is the rate going in or out per unit of time. The water in a bathtub is a stock; the tap and the drain are flows. A bank balance is a stock; income and spending are flows. A country's population is a stock; births and deaths are flows. The stock is the photograph; the flow is how the photograph is changing right now.
It sounds trivial, but the human brain fails at this systematically, and badly. Sterman at MIT ran a famous experiment: show a group of highly educated people a chart of a tank's inflow and outflow rates over time, and ask how the water level changes. Most get it wrong. The commonest error is to take the direction of the flow as the direction of the stock: seeing "the inflow rate is falling," they conclude "the level is falling." But as long as inflow still beats outflow, the level keeps rising, even while the inflow decelerates the whole time. People are wired to conflate "the rate of change" with "the amount itself."
Why is the distinction worth money? Because what you can act on directly is usually a flow, while what you care about is a stock, and between them sits a process of accumulation. Losing weight cares about body weight (a stock) but changes daily intake and burn (flows); paying off debt cares about the balance (a stock) but changes the monthly payment (a flow). Fix a flow once and expect the stock to follow instantly, and you will almost surely be disappointed — a stock has inertia; it remembers every past entry.
Add a delay to a negative loop and steady correction becomes oscillation — the most practically useful thing in this topic.
Back to the shower. A thermostat doesn't oscillate because it knows almost instantly that the room's gone cold. But the shower pipe has a length: turn the valve and the hot water takes a few seconds to reach the head. So you're making a now adjustment based on the temperature of a few seconds ago. Cold — crank the hot — still cold (the hot's on its way) — keep cranking — suddenly leap back scalded — crank it back — freezing again in a moment. Every step was a correct correction, but you were correcting an already-stale error, so you always overshoot. The delay turns a negative loop that should converge to "just right" into an oscillation swinging around "just right."
This isn't a quirk of clumsy hands; it's the generic fate of a delayed negative loop. In inventory management it has its own name — the bullwhip effect: end-customer demand twitches a little, the retailer orders a bit extra to be safe, the wholesaler sees retail orders rise and stocks a bit more, the factory sees wholesale orders rise and ramps up hard — amplification layered on delay layered on delay, and by the time the top of the chain reacts, demand has long since fallen back, so the whole chain ends up drowning in stock at once. In MIT's famous "Beer Game," a room full of smart people, merely by sitting on this chain, produce violent inventory swings almost without exception — not because they're stupid, but because the structure forces them to be.
Once you know this, the whole approach to oscillation changes. Oscillation isn't because some link was "poorly tuned"; it's the combination of delay and aggressiveness. So the real fix is one of two things: shorten the delay (let feedback return faster — small batches, frequent restocking, shorter reporting chains), or slow your correcting hand (don't fix it all at once; leave time to observe). Conversely, the most tempting option — "it hasn't come back yet, so push harder" — is precisely the hand that keeps widening the swing.
When a system swings between extremes (orders lurching up and down, moods high then low, policy loose then tight), don't first ask "who overreacted this time." Measure two things: how long feedback takes to return (delay), and how heavy a hand each correction lays down (gain). Oscillation is almost always the product of "delay too long × hand too heavy." Change whichever you can — shorten the delay, or lower the strength of a single correction — both beat "be more careful next time." Pushing harder is the one guaranteed-wrong option.
"Structure determines behaviour" is a strong claim, and precisely because it's strong it's easily overused. Here are its edges.
First, "structure determines behaviour" is not "people and intent don't matter at all." The precise version is: within a given structure, individual differences tend to be flattened by the loop — swap anyone in and it's much the same. But the structure itself is built by people, and can be changed by people. The loop shrinks the payoff of "trying hard inside the system" and magnifies the payoff of "changing the system." Reading it as "it's all the structure's fault, individuals are powerless" mistakes a judgment about where the leverage is for fatalism — on the contrary, it's telling you where to push: stop grinding inside the loop, go change the wiring.
Second, being able to draw the loops isn't being able to quantify them. The language of positive/negative feedback and delay gives you qualitative intuition — will it grow or settle, will it oscillate. But in a real system, dozens or hundreds of loops are tangled together, and which one dominates right now, and where the tipping point is, can't be answered by "counting arrows"; it needs real data and simulation. A loop diagram is a useful map, but the map is not the terrain. Taking a pretty causal-arrow diagram for "I now understand and can predict this system" is system dynamics' most common self-deception.
Third, and most easily missed: some systems' behaviour comes mainly not from internal loops but from external shocks. The feedback frame excels at explaining endogenous dynamics — how a system amplifies or damps its own perturbations. But if a thing's ups and downs are mostly driven by unrelated random events crashing in from outside (pure external news, disasters, abrupt policy changes), then laboring to draw its internal loops may be beside the point — you should build a different model. The test is simple: turn off the external inputs — does the system still move on its own? If yes, then feedback loops take the stage; if no, the main act is outside.
Before explaining a system with loops, clear three gates: ① Is its behaviour mainly endogenous (does it still move with external inputs off)? ② Am I talking qualitative shape (growth / stability / oscillation), or masquerading as quantitative prediction? ③ Do I admit the structure is changeable, and haven't swapped "structure determines" for "no one is responsible"? Fail any gate and hold off on drawing conclusions from the loop.
Neither. Everything you want to grow — learning, compound interest, network effects, the compounding of skill — starts on positive feedback; without it nothing gets off the ground. And negative feedback can be a comfortable steady state or a ceiling you can't break through however hard you try (much of what feels like a rat race is a pile of negative loops pinning everyone in place). Healthy systems are usually a mix — positive feedback for growth, negative for brakes — and the trouble almost always is which half is missing: positive without a brake → bubble or cancer; negative without a growth engine → stagnation.
Not necessarily. Some delays are useful buffers — inventory, savings, reservoirs, the middle layers of an organization all use "temporary holding" to absorb upstream jitter, and actually dampen oscillation. What really makes trouble is information delay (you learn the truth too late), not material buffering delay (things held in store). So the precise target isn't "cut every delay" but "shorten the time for information to loop back while keeping the buffers that absorb shocks." A blanket drive for "zero inventory, zero redundancy" often cuts the damping buffer and the oscillation-causing lag together.
It does — if you stop halfway. The full claim is two sentences: within a given structure, individual differences are flattened (so don't just blame the person); but the structure is built by people and can be changed by people (so someone is responsible for not changing it). Real accountability therefore moves up from "who pressed the wrong button" to "who had the power to rewire this loop and didn't." The feedback view doesn't abolish responsibility; it puts it at the right layer — from operator to designer.
It's hard, because the delay severs the intuitive link between cause and effect — your action loops back only much later, and by then you no longer connect it to that first move (this is exactly what makes every "symptom-maintaining loop" so stubborn). One clumsy method works: take a recurring, baffling event and force it into a ring of arrows, making yourself answer "did this action of mine, in the end, loop back to strengthen the very thing I wanted to remove." Many personal and organizational knots loosen at first sight of the drawing — because you see, for the first time, that you're part of the loop, not a victim outside it.