Donella Meadows's Thinking in Systems: the book that helps FDEs untangle a client's vague problem

Clients rarely bring an FDE a problem that is already defined. Most simply describe a feeling: the ticket backlog keeps growing, their own customers complain more, the team is exhausted.

To untangle this kind of problem, read Thinking in Systems: A Primer by Donella H. Meadows, lead author of the 1972 report The Limits to Growth.

You will not learn an API or a framework from this book, but you will learn how to ask questions so that your next discovery session does not stop at the symptoms.

A book its author did not live to publish

The manuscript had been circulating since 1993. Meadows died in 2001, and the book was completed after her death: Diana Wright edited it, and Chelsea Green Publishing of White River Junction, Vermont, published it in 2008.

The Donella Meadows Project, the organisation that looks after her legacy, calls it a primer, an introductory book. In that spirit, Meadows’s most memorable advice is very simple: before you disturb the system in any way, watch how it behaves.

For an FDE, this changes the direction of a client interview. Instead of rushing to ask “what do you want the tool to do?”, you ask “what in this process is feeding the problem?”

The first idea: find the loop that reinforces itself

Meadows wrote that positive feedback loops are sources of growth, explosion, erosion and collapse in systems. These reinforcing loops grow exponentially, and if nobody stops them they can do serious, irreversible damage.

Picture the support team above, and suppose its agents are rewarded for the number of tickets they close each week. A big backlog means agents have to answer in a hurry. Hurried answers are poor answers, customers reopen their tickets, and the backlog grows again.

This is a reinforcing loop, and it explains why “everything is getting worse” rather than merely “bad”. Once you can name the loop, you have a hypothesis to test with data: does the ticket reopen rate rise along with the backlog?

The second idea: ask about delays

Meadows wrote that a system cannot respond to short-term changes when it has long-term delays. In a support team, reopened tickets usually come back late, days after the hurried answer.

Imagine that team only looks at a quality report once a quarter: by the time they see the figures the situation has already changed, so they are prone to reacting late or overcorrecting.

In a deployment, delays also determine how you prove value. A change that takes six weeks to show results cannot be judged within a four-week pilot. So ask the client at the outset: when they change something, how long before they know whether it worked?

The third idea: adjusting numbers is the weakest lever

This idea comes from Meadows’s essay Leverage Points: Places to Intervene in a System, in which she ranks the places where one can intervene in a system as a list. At number 12, the lowest and weakest, are constants, parameters and numbers such as subsidies, taxes and standards.

She states plainly that parameters rank “dead last” among powerful interventions, and that numbers rarely change behaviour. The higher rungs of the list are therefore the stronger places to intervene.

Meadows did not write about support teams, so the table below is only a trial application. The first row maps directly onto her number 12; the other two are approaches that go beyond the numbers and have not been assigned to any particular rung of the list.

Trial intervention	Just adjusting a number?	What might happen to the loop
Add staff, raise the SLA	Yes, exactly the number-12 kind	The loop runs more slowly, but it is still there
Show agents which tickets get reopened	No, it changes the information the person answering receives	Agents know straight away whether their answer failed
Stop rewarding the number of tickets closed	No, it changes how the team is evaluated	Removes the reason people have to answer in a hurry

Now imagine you are asked to build an agent that drafts replies for this same support team. If the agent only helps people answer faster, it is in essence adjusting a number: speed, inside a loop that is still broken.

The same agent could do more, for example by routing the reopen signal back to the person who wrote the answer. Then it touches the structure of the loop, rather than just making the loop spin faster.

One caveat. The order of the list should be read only as a guide, and critics argue that it oversimplifies the complexity of social systems. Use it to widen the range of options you consider, not as a checklist.

What order should you read in?

Start with the Leverage Points essay, published on the Donella Meadows Project website and once republished by Nonprofit Quarterly. It is short and gives you the scale to use straight away. Then read the whole book to get a firm grip on feedback loops and delays.

Finish with Dancing With Systems, published on the Donella Meadows Project website in 2012, which carries the advice to watch a system before you touch it. Any FDE who has seen a deployment that was perfect on paper bent out of shape by a client’s real processes will understand why this one is worth reading before every site visit.

How do you put feedback loops on your CV?

The support-team example above also makes a good CV line. Instead of writing “deployed an agent for the support team”, try: “Identified a reinforcing loop between ticket backlog and reopen rate; routed the reopen signal back to the person who answered; set the reopen-rate checkpoint at six weeks because of the loop’s delay.”

That line covers all three ideas in the book: the feedback loop you found, the intervention point you chose, and the delay you accounted for when setting the checkpoint. In a case-study interview, tell the story in exactly those three steps.

The next time a client says “everything is getting worse”, that sentence is already the first clue: there is very likely a reinforcing loop running somewhere, and your job is to find it.