I picked up Donella Meadows' Thinking in Systems expecting an environmental-science book, because that was her field, and I came away with the clearest mental model of software behaviour I've ever read. It is not about software at all. It's about stocks, flows, feedback loops and delays, drawn from ecology and economics. And yet every page felt like someone describing the production incidents I'd spent the year cleaning up.
The thing that lodged is the idea of a stock with a delayed feedback loop. A stock is just an accumulation: water in a bath, money in an account, messages in a queue. A flow fills or drains it. The trouble starts when the signal you act on lags behind the thing you're trying to control. You turn the tap, nothing happens for a while, so you turn it harder, and then it overshoots and you're scalding. That is autoscaling. That is a retry storm. That is every capacity decision made on a metric that's thirty seconds stale.
Meadows has this lovely, slightly subversive section on leverage points, the places where a small shift changes the whole system's behaviour. Her ranking is deliberately counterintuitive. Tweaking numbers (the parameters everyone fights over) is near the bottom. Changing the structure of the feedback loops is much higher. Changing the goal of the system, or the mindset that the goal sits inside, is higher still. I read that and thought about how many sprints I'd spent tuning a timeout when the actual problem was that two services were locked in a reinforcing loop nobody had drawn.
What it changed, practically, is how I read a graph. I used to look at a spike and ask what caused it. Now I ask what's accumulating, what's draining it, and how long the loop takes to notice. A slow oscillation that won't settle is almost never a bad value somewhere. It's a delay in a feedback path, and you fix it by shortening the delay or loosening the loop, not by hunting for a guilty constant.
She also warns, gently, against the engineer's instinct to optimise one thing hard. Push any single flow to its limit and the system finds a new bottleneck, usually somewhere you weren't watching. I've now seen that happen enough times that I treat "we made X faster" as a question rather than a victory: faster, and what's the new constraint?
It's a short book, and she died before finishing it, so it has a slightly unpolished, conversational feel that I rather love. It hasn't made my dashboards more honest. It's made me more suspicious of them in the right way, which on a bad night is the more useful skill.