Learning Systems Thinking: Final Thoughts on the Book
So here we are. Sixteen posts later and I’m done retelling “Learning Systems Thinking” by Diana Montalion. Time to wrap it up with what actually stuck with me.
What This Book Is Really About
On the surface, it’s a book about systems thinking for software people. But it’s actually about something bigger. It’s about how we think. How we make decisions. How we work with other humans to build things that are way too complex for any one person to understand.
Diana doesn’t just explain systems thinking as a concept. She walks you through it as a practice. Something you do every day, not something you read about once and forget.
What Stuck With Me
A few things hit different after going through all 12 chapters:
Linear thinking is comfortable but wrong. We all default to “if I do X, then Y happens.” But real systems don’t work that way. Effects are delayed, side effects show up in weird places, and fixing one thing breaks two others. Once you see this pattern, you can’t unsee it.
Self-awareness comes first. Before you can think about systems, you need to understand your own biases and reactions. Chapter 4 and 5 were surprisingly personal for a tech book. But that’s the point. You are part of the system too.
Thinking together is harder than thinking alone. The book’s Part III about collective reasoning, feedback loops, and pattern thinking showed me why so many team decisions go sideways. It’s not that people are stupid. It’s that group thinking has its own dynamics that nobody talks about.
Models are tools, not truth. Chapter 10 on modeling together was practical and honest. Every model is wrong. Some models are useful. The goal isn’t to create a perfect diagram. It’s to build shared understanding.
Success needs redefining. The last chapter challenged how we measure whether things are working. Velocity, story points, lines of code, none of these tell you if your system is actually healthy.
What I Wish Was Different
The MAGO case study that runs through the book is helpful but sometimes it felt a bit forced. Real-world examples from actual companies (even anonymized) would have landed harder for me.
Some chapters feel dense. If you’re new to these ideas, chapters 7-9 might need a second read. That’s not necessarily bad though. Good ideas take time to process.
Should You Read It?
If you build software and you’ve ever wondered why things keep going wrong despite everyone doing their best, yes. Read this book.
If you’re a team lead or architect trying to make better decisions about complex systems, definitely yes.
If you’re just starting out in tech, this might be a bit abstract. Maybe save it for when you’ve been burned by a few “simple” projects that turned into nightmares. Then it’ll click perfectly.
The book is published by O’Reilly (ISBN: 978-1-098-15133-1). You can find it on their platform or wherever you buy technical books.
One Last Thing
Systems thinking isn’t something you learn once. It’s a practice. Diana makes that clear from the start and proves it through 12 chapters. The real work starts after you close the book and start noticing the systems around you. In your code, your team, your organization.
And that’s maybe the best thing about this book. It doesn’t give you answers. It teaches you to ask better questions.
Thanks for reading along. I hope these posts gave you a taste of what the book offers. But honestly, go read the real thing. Diana writes better than I do.
This was the final post in my retelling of “Learning Systems Thinking” by Diana Montalion. You can find all posts in this series under the learning-systems-thinking tag.
Previous: Chapter 12: Redefining Success - Part 2 | Series Start: Introduction