I came to Thinking in Systems by Donella Meadows late, and slightly by accident. Someone mentioned it in passing during a conversation about why our alerting kept overshooting, and I bought it expecting a dry management text. It is not that. It is one of the most quietly useful things I have read, and it has changed how I look at almost everything I build.
The core idea is simple enough to feel obvious once you have it: a system is not its parts, it is the relationships between them. Stocks accumulate, flows move things in and out, and feedback loops either stabilise the whole thing or send it spiralling. That is it. But the consequences run deep, and the book spends its length pulling on that thread until you cannot stop seeing it everywhere.
Delays are where the trouble lives
The part that stuck with me hardest was about delays. A feedback loop with a delay in it behaves nothing like one without. You push, nothing happens, you push harder, and then everything you did arrives at once and overshoots. Meadows uses a shower with a slow boiler as the example, and I have never thought about a thermostat the same way since.
It mapped almost too neatly onto the alerting problem that sent me to the book in the first place. We were averaging over too long a window, reacting to numbers that were already stale, then over-correcting and oscillating. The fix was not a cleverer threshold. It was shortening the delay between the signal and the response. Once I saw it as a control loop rather than a tuning problem, it became obvious.
Leverage points, and where not to push
The other idea I keep returning to is leverage points: the places in a system where a small change produces a large effect. Meadows ranks them, and the punchline is that the obvious levers (the numbers, the parameters, the thresholds we love to fiddle with) are the weakest ones. The real leverage is in the structure of the loops, the rules, the goals, and ultimately the mindset that created the system in the first place.
That is humbling for an engineer, because we spend a lot of time adjusting parameters and very little questioning the goal. It is far easier to tune a retry count than to ask whether the thing should be retrying at all.
I am wary of books that promise to change how you think, because most of them change how you think for about a week. This one is different, mostly because it gives you a vocabulary rather than a doctrine. Stocks, flows, delays, balancing and reinforcing loops, leverage points. Once those words are in your head you reach for them without meaning to, in standups and postmortems and the odd argument about the heating.
If you build systems for a living, software or otherwise, it is worth your time. It is short, it is clear, and it will quietly ruin your ability to look at a thermostat without thinking about feedback delay.