Systems Thinking Chapter 1: What Even Is Systems Thinking?
Diana starts Chapter 1 with a warning. Reading a book about systems thinking will not teach you systems thinking. Just like reading a book about tennis will not teach you tennis. You have to go outside and play. Fair enough. But you still need to know the rules before you step on the court.
Linear Thinking Is Our Default
Here’s the thing. We were all trained to think in straight lines. Input goes in, output comes out. If this, then that. Break the problem into pieces, solve each piece, done. This is linear thinking, and it works great for a lot of things.
Object-oriented programming? Linear thinking. Decomposing a monolith into services? Linear thinking. Finding a bug by tracing cause and effect? Linear thinking. We use it every day and it keeps the lights on.
Diana is very clear that she’s not against linear thinking. It’s not the evil witch from Wizard of Oz. Linear thinking helps us break down problems, learn new languages, test ideas, improve efficiency. We literally cannot do our jobs without it.
But here’s the problem. Linear thinking assumes you can break a system into parts, understand each part, and then understand the whole. That works when your system is simple. When your system is a mess of interconnected software, people, processes, and organizational politics, breaking it into parts loses the most important information. The relationships between the parts.
Systems Are Not Machines
Diana uses a garden example that really stuck with me. In a linear world, you plant seven kale seeds and get seven kale plants. A rabbit eats one, you put up a fence, problem solved.
In a real garden? You might get nine plants because some survived from last year. Or you might get zero. Maybe rabbits jumped the fence because their usual food is gone. Maybe too much rain, not enough sun, bad soil, cabbage worms, or slugs. Most likely it’s some combination of all of these, affecting each other in ways you can’t predict.
This is what nonlinear means. The parts interact. The relationships between parts create behaviors you didn’t design and can’t fully control. And modern software is exactly like this garden. Except the garden has maybe 20 variables. A modern software system has thousands.
I spent years building software that operated in relatively controlled environments. Push a change, mostly know what will happen. Those days are gone for most of us. Software now runs on top of other software, talks to dozens of APIs, gets used in ways nobody intended, and becomes “legacy” about three minutes after launch. Diana’s words, not mine. But she’s right.
So What IS a System?
Diana collects several definitions from smart people (Ackoff, Donella Meadows, INCOSE) and they all say roughly the same thing. A system is a bunch of parts that work together and produce behaviors that no single part produces alone.
For software specifically, she defines it as: a group of interrelated hardware, software, people, organizations, and other elements that interact to serve a shared purpose.
Two things I noticed here. First, people are part of the system. Not separate from it. The organizational structure, the communication patterns, the decision-making processes. All of it. Systems are sociotechnical. This is something many engineers still don’t want to hear, but it’s true.
Second, “purpose” is tricky. WordPress is a publishing tool, that’s its function. But the purpose of a system using WordPress might be “tell the world about plant-based cooking.” Without the writers creating content and readers consuming it, the software serves no purpose. Purpose belongs to the whole, not to any single component.
The MAGO Case Study
Throughout the book, Diana uses a fictional organization called MAGO to illustrate systems challenges. MAGO was a massively popular print magazine. In 2010 they launched a website. Like most organizations, they built it around the concept of a “page” because that’s what they knew. HTML was invented to structure pages. Made sense at the time.
Then the world changed. Content needed to be everywhere, not just on a website. Social media, search engines, apps, podcasts, video platforms. People expected information to adapt to their device, location, context. Publishing wasn’t weekly anymore, it was continuous.
MAGO kept building. New features, new apps, new tools. Product teams went rogue and built separate websites. Over time, the whole thing turned into what Diana calls a Rube Goldberg machine, with production people manually moving data between systems. Nobody could name all the parts or explain how they worked together.
Then the pandemic hit, and the company maintaining their core software went out of business. MAGO’s first reaction was “replace the software!” But you can’t just replace one piece when the whole system is interconnected. The real question became: how do we design a system for the modern age?
If you’ve worked in any medium-to-large organization, this story probably sounds familiar. I’ve seen this exact pattern at least four or five times in my career. Different company, different industry, same mess.
Qualities of a Systems Thinker
Diana lists about 14 qualities of people who think in systems. I won’t repeat them all, but the ones that hit hardest for me:
They know that people systems and technical systems are inseparable. They shift perspective easily. They seek systemic structures behind recurring problems instead of blaming individuals. They demonstrate self-awareness about their own biases and reactive thinking. They accept uncertainty as natural.
And here’s the paradox she mentions that I really liked. The more you know about systems thinking, the more you realize you don’t know. The most valuable quality of a systems thinker is knowing they don’t know. And the worse you are at nonlinear thinking, the more certain you are that you’re good at it. Classic Dunning-Kruger, applied to thinking itself.
My Take
This chapter does a good job setting up the problem. We think linearly in a nonlinear world, and it’s causing real damage. The MAGO story is a solid illustration that will pay off in later chapters.
One thing Diana says that I want to highlight: nonlinear approaches are harder. Your life is not about to get easier. But you’ll become more effective, and the work won’t feel so much like work. After 20+ years in this industry, I can confirm. The teams that struggled the most were always the ones trying to force linear solutions onto nonlinear problems. They worked harder but got worse results.
Systems thinking is not a certification or a 12-step program. It’s a practice. You get better by doing it. This chapter opens the door. Next chapters show you what’s on the other side.
Previous: Introduction