I read a lot of technical books that I forget within a month. The good ones leave me with a trick or two. Now and then one rewires something, and Donella Meadows' Thinking in Systems is the only one in years that did that to me.
It is not a computing book. It is a slim primer on systems thinking, written by an environmental scientist, full of examples about fisheries and thermostats and national economies. And yet it described, better than any ops post-mortem I have ever read, exactly why the things I build behave the way they do once they are out in the world.
The central idea is stocks and flows, and the feedback loops that connect them. A stock is something that accumulates: water in a bath, messages in a queue, money in an account. A flow changes it. And the interesting behaviour, the behaviour that surprises you, almost always comes from loops, where a flow feeds back to affect itself.
Once you have that lens you cannot stop seeing it. A retry storm is a reinforcing loop: failures cause retries, retries cause load, load causes more failures. An autoscaler that flaps is two loops fighting. The reason a queue with unbounded growth eventually takes everything down is that there is no balancing loop strong enough to drain it faster than it fills, and no amount of staring at a single graph will tell you that. You have to see the loop.
The other idea that stuck is leverage points: the notion that there are places in a system where a small change produces a large effect, and that we have a strong instinct to push on exactly the wrong ones. We reach for the parameter, the threshold, the timeout value, when the real leverage is usually in the structure itself, or in the goal the system is optimising for. Tuning a retry backoff is pushing on a low-leverage point. Removing the need to retry at all is pushing on a high one.
What I took from it was not a technique I can put in a runbook. It was a habit of mind. When something misbehaves now, my first question is no longer "which component is broken" but "what loop is this, and what is it trying to settle towards". More often than I would like, the answer is that the system is doing exactly what its structure tells it to do, and the thing I want to change is not the broken part but the shape of the whole.
It is a short book and it does not pretend to be more than an introduction. But it is one of the few things I have read that genuinely changed the questions I ask, and the questions are the part that matters. Worth an afternoon of anyone's time, engineer or not.