Donella Meadows: you don't control a system, you dance with it

There is a scene that repeats itself in a lot of product companies. Someone looks at a dashboard full of metrics that won't move—or that move in the opposite direction to the one they want—and the answer is always the same: more instruments. Another dashboard, another OKR, another reorganisation, another metric that will finally capture what the previous ones missed. Beneath all of it beats a rarely stated belief: that a sufficiently complex system can be governed from a control panel, if only we find the right lever and pull hard enough.

There was a woman who spent much of her life dismantling that belief, and doing so without giving up the hope of intervening in the world. Donella Meadows was a scientist before anything else—a biologist and biophysicist by training—and she came to systems by the least romantic door: the computer models that, in the 1970s, were trying to simulate the behaviour of the entire planet. She came out of that experience with a lesson she would spend the rest of her career refining: that complex systems will not be commanded, but they will be accompanied, and that the difference between the two is almost everything that matters.

A scientist against the illusion of control

Meadows (1941–2001) became known early, and for an uncomfortable book. In 1972 she was the lead author of The Limits to Growth, the report commissioned by the Club of Rome that used system dynamics models to project what would happen if the growth of population, consumption and pollution kept following its trends on a finite planet. The book sold millions of copies and earned her as much praise as scorn; for decades it was the favourite punching bag of those who confused a model with a prophecy. But the work marked her more deeply than the controversy did: it taught her, from the inside, how far our tools for prediction and control reach, and where they break.

She came out of the system dynamics tradition Jay Forrester had founded at MIT, but she ended up distrusting the technological enthusiasm of that very tradition. Her most cited warning is aimed precisely at her own: someone raised in the industrial world who falls in love with systems thinking runs the risk of making a terrible mistake, that of believing that here, in interconnection and in the power of the computer, is at last the key to prediction and control. It is not. The rest of her work is, in large part, the patient development of that refusal.

She died in 2001, at fifty-nine, leaving unfinished the primer with which she wanted to teach anyone to think in systems. Her students and colleagues completed it and published it in 2008 as Thinking in Systems: A Primer. It is a short, generous book, and it remains the best way into a way of seeing that has only grown more relevant.

Structure, not culprits

The first thing Meadows teaches is a change of question. Faced with a behaviour that keeps repeating and grating—an indicator that won't improve, a team that always trips over the same thing, a decision that goes wrong again and again—the instinctive reaction is to look for someone responsible. Who did this? Who do we replace? Meadows teaches you to ask something else: what structure produces this behaviour?

Her basic grammar is three pieces. Stocks—the reservoirs of something that fill and empty: the cash in the bank, the trust of users, the technical debt. The flows that feed and drain them. And, above all, the feedback loops: the circuits through which the state of a stock influences the flows that change it. A reinforcing loop amplifies; a balancing loop stabilises. Almost all the behaviour that surprises us in a system—that it shoots up, that it stalls, that it oscillates—comes out of the way those loops combine, not out of the malice or the clumsiness of any one person.

The corollary is both liberating and demanding. Liberating, because it takes the focus off the hunt for culprits: changing who holds a position rarely changes the outcome if the structure generating the behaviour stays intact. Demanding, because it forces you to look where nothing is visible. In product, a metric that keeps getting gamed is almost never a problem of dishonest people; it is a structure that rewards gaming it. A team that always falls short on discovery usually doesn't need more pressure, but a different loop: one where learning early has visible consequences. The question "who failed?" produces reorganisations; the question "what loop sustains this?" produces changes that last.

Leverage points, and why we push the wrong way

Out of that structural gaze comes her most influential idea. Meadows set it out in a memorable essay, Leverage Points: Places to Intervene in a System. A leverage point is a place within a complex system—a corporation, an economy, a living body, a city, an ecosystem—where a small shift in one thing can produce big changes in everything. Every intervention is looking for one of those points. The trouble is that we almost always choose badly.

Because Meadows did more than name the leverage points: she ranked them from weakest to strongest, in a hierarchy of twelve rungs that runs from the most fiddled-with to the most ignored. At the bottom, where nearly all our energy goes, are the numbers: the parameters, the constants, the fine adjustments. Raise a budget, lower a price, change the quarterly target. They are the most visible points and the weakest; moving a number rarely changes the character of a system. Higher up are the structure of flows and stocks, the strength of feedback loops, the flows of information: who knows what, and when. And right at the top, where we almost never look, are the rules of the system—the incentives, the punishments, the constraints—the goals it pursues and, above all, the paradigm: the set of shared assumptions from which the system thinks about itself.

The practical lesson is uncomfortable. We spend almost all our attention on the lower rungs—the numbers, the dashboards—because those are the ones that let themselves be touched, and we neglect the upper ones—the rules, the goals, the paradigm—which are the ones that actually determine behaviour. And there is a reason for this, one Meadows stated with a bluntness that sticks:

"The higher the leverage point, the more the system will resist changing it — that's why societies have to rub out truly enlightened beings."

— Leverage Points: Places to Intervene in a System (1999)

The points that matter most are exactly the ones the system defends most fiercely, because touching them threatens whoever thrives on the existing order. Changing a number is easy, and that is why it is weak; changing the goal an organisation optimises for—or the paradigm from which it decides what even counts as a problem—is hard precisely because it would change many things at once.

And there is one more twist, perhaps the most useful of all. Meadows observed, taking up an intuition of Forrester's, that people usually get the location of the leverage point right and the direction completely wrong: they find the correct lever and pull it toward the side that makes the problem worse. We subsidise the very thing causing the harm; we add more control to a system that is suffering, precisely, from an excess of control. Anyone who has watched an organisation respond to a coordination problem with another layer of oversight will recognise the gesture. The lever was correctly identified. What was wrong was the direction in which it was pushed.

You can't optimise a part

There is a permanent temptation in any organisation: to improve the part in front of you. The team optimises its metric, the department defends its budget, each function tunes its stretch of the process. Meadows insisted that aggressively optimising a part almost always degrades the whole, because the parts of a system are not independent: they are joined by flows and loops that sooner or later return the bill for the local optimisation.

On top of that difficulty comes another, more treacherous still: delays. Between an intervention and its effect there is usually a lag, and that lag pushes us to overcorrect. We see the indicator not reacting, we insist, we double the dose, and when the effect finally arrives—added to that of all the corrections we piled up while we waited—the system overshoots and oscillates. It is the same pattern by which a shower with a badly calibrated hot tap makes us jump between ice and scalding. In digital product work, where any change can trigger unforeseen ramifications throughout the system, overreacting to a dip in a metric is one of the most common and most expensive forms of this error.

From here comes one of the reasons Meadows resonates so much with anyone who runs product: that material, software, behaves like a system of systems, with stocks, flows and loops of its own, and it punishes with particular harshness the illusion that the whole can be governed by improving one part at a time.

Paradigms, and learning to dance

If the highest leverage point is the paradigm—the assumptions from which a system understands itself—then the most powerful intervention there is, is also the quietest: to change the way a collective sees. Meadows knew this from her own experience; The Limits to Growth was, more than a forecast, an attempt to move the paradigm about growth on a finite planet. And she also knew that this rung is the one that resists most, because a paradigm is not argued, it is inhabited.

But her conclusion was not that of the engineer who, having found the supreme lever, sets about pulling it. It was exactly the opposite, and in it lies the most mature part of her thought. Above even changing the paradigm, she said, is the capacity not to cling to any: to keep the mind loose enough to recognise that every paradigm, including one's own, is a partial way of seeing. That humility did not lead her to quietism, but to an image that sums up her work better than any diagram:

"We can't control systems or figure them out. But we can dance with them!"

— Dancing With Systems (2001)

To dance with a system means to intervene without the fantasy of commanding it. To observe before acting. To listen to how it responds and let its response correct the next intervention. To start with small, reversible changes rather than large, irreversible plans. To pay attention to what the system does, not only to what we wish it would do. It is, curiously, a fairly faithful description of what good product teams do when they really work: they don't execute a closed plan, they iterate; they don't control the outcome, they probe for it.

Where she falls short

It would be unfaithful to Meadows to turn her into an oracle, not least because she would have distrusted the gesture. Her thought has real tensions, and they are worth naming.

The most serious is that her framework is magnificent for diagnosis and rather weaker for action. Knowing that a certain structure produces a certain behaviour does not tell you which leverage point is accessible, at what cost, or on what timeline. And there is an irony at the heart of her hierarchy: the highest-leverage points—changing rules, goals, paradigms—are precisely the ones that demand a political and organisational power her analysis almost always leaves out of frame. The theory points to where you would have to push and, in the same movement, shows that pushing there is the hardest thing in the world. The practitioner is left with the diagnosis and much of the problem intact.

There is also a blind spot in her way of looking. Meadows tends to treat systems as objects to be understood rather than as terrain under dispute. But inside almost every system that matters there are actors with interests, and those actors actively resist a structural analysis when it implicates them. It is not just that the system "resists" through inertia; it is that some benefit from its not being understood. The vocabulary of stocks and loops, so clean, can turn curiously innocent in the face of that grubby, human part of organisations. Not everything a system hides, it hides through complexity. Sometimes it hides it because it pays someone to.

None of this invalidates her contribution; it situates it. Meadows describes as few can why persistent problems live in the structure and not in the people, and why our interventions fail so often. What she does not quite resolve is how to gather the power to intervene where it truly matters. That remains, a quarter of a century after her death, an open tension.

Back to the panel

Even so, it is hard to think of a more relevant voice for this moment. We have built, with a fidelity that would have both fascinated and appalled her in equal measure, the information-saturated, instrument-heavy world her models anticipated. And artificial intelligence is not suspending Meadows's lesson: it is testing it at a larger scale. It multiplies dashboards, makes the production of metrics and summaries absurdly cheap, and in doing so reinforces exactly the gesture she distrusted: the belief that a complex system is governed by adding instruments of control. More panels is, in her hierarchy, touching the numbers. It is the weakest lever there is, dressed up as progress.

Her work is no stranger, either, to the way the companies that make digital product organise themselves. Changing the rituals, the tools or the org chart are parameter moves: visible, comfortable, of little reach. Changing the incentives that govern a team—the rules—is of another order, and that is why it endures when any ceremony evaporates. Telling one from the other is the difference between the reform that takes hold and the one that decorates.

Perhaps that is why it is worth returning to the scene we began with, to that person in front of a panel that won't move. The answer Meadows would offer is not a better panel. It is a different relationship with the system behind the panel: less effort spent commanding it, more attention paid to how it responds; less faith in the single lever, more willingness to probe and correct. Not to control, but to dance. And dancing, she reminded us, begins with the hardest thing for anyone trained to control: listening to the music before deciding the step.