Systems Thinking Chapter 9: Pattern Thinking
We all see patterns. You get sick and you think back. Was I stressed? Did I sleep enough? Was someone around me sick? You compare symptoms to last time. You adjust your schedule.
Diana starts Chapter 9 with exactly this. She admits her own pattern of ignoring sickness and pushing through. One time she was brain-foggy sick on a Friday and pushed a JavaScript change to production that broke the entire e-commerce flow. We have all been there. That moment when you know you should stop and you don’t.
Viruses are a great metaphor for system patterns. What happens after exposure depends on your physical condition, diet, history. Not everyone exposed to Covid gets sick. Some people spread it to everyone, some to nobody. Same with software systems. The closer you look, the more complexity you find.
What Pattern Thinking Actually Is
Here is the simple version. Pattern thinking is not just asking “did this happen before?” That is a start, but if you only look at patterns along a timeline, you stay stuck in linear thinking.
Real pattern thinking means you spot a repeating pattern, understand what reinforces it, notice the forces behind it, and see how the pattern changes over time. All at once.
Diana gives a great example. Your team has bugs in production. Syntax errors that a linter would catch. The team is busy, pushing faster, skipping peer review. You add a linter to the merge process. Bugs go down. Problem solved?
Maybe. Maybe not.
The linter fixes the surface problem. But why is the team rushing? This is where it gets interesting. Diana walks through several scenarios.
Maybe the team was too cautious before. New manager encourages them to stretch. More bugs because they write more code, but over time they improve. Linter is a safety net. Good outcome.
Maybe they are in crunch time. Things get messy, but once it passes they clean up. Also fine.
But then there is the darker version. The organization runs on fear. “Deliver quickly or we die” is the mental model. Nobody thinks well when constantly on fire. Bugs happen, blame follows, more pressure. The linter is just a band-aid. The real problem is the culture.
This is the Iceberg Model in action. Events are on the surface. Patterns are underneath. Below patterns are structures. And at the bottom are mental models. If you don’t change the mental models, you won’t change the patterns for real.
Relationships Produce Effects
Diana quotes Donella Meadows here. We cannot impose our will on a system. But we can dance with it.
Patterns are the choreography of a system. Everything is connected to everything else. Behaviors come from relationships between parts and how those parts share information.
She uses a family analogy. You as a person have certain patterns. Get into a relationship and new patterns appear that neither of you had alone. Add kids, work, school, community. All of it influences how the family thinks and behaves.
Same with software. Pattern thinking is understanding how software, people building it, and organizations around them produce effects together.
This is messy. Each software system has unique patterns and shares common patterns with similar systems. At the intersection is systems architecture, the process of improving relational patterns in your particular system.
Diana makes a practical point. System patterns are usually not visible at the code level. You need modeling. Whiteboards. Diagrams. Frameworks like Spring Boot or Angular help by enforcing patterns, but they are not enough. You still need to understand your specific situation.
Where to Look for Patterns
Diana identifies four key relationships to examine when you find a pattern:
Time. Does the event repeat? Has it changed? Has the frequency changed? Best practices that helped yesterday might hurt today. Our past selves create challenges for our future selves.
Context. Think about Netflix. Their mission stayed the same, provide movies on demand. But the context shifted from mailing DVDs to streaming. What works for Netflix won’t work for your company. What works for Netflix today might not work for them next year.
Other parts. How do parts of the system relate to each other? Decoupling, microservices, domain-driven design, all about changing relationships between parts. But Diana notes she rarely sees project management that actually supports emergent design. We usually manage by breaking things down and adding control instead of supporting self-organizing activity.
Structures. Every pattern is held in place by structures. Hierarchies, delivery methods, test practices, infrastructure. Developers want to write tests to reduce bugs. Product managers are pressured to ship features. The organizational structure leaves no room to resolve this conflict.
And the most important place to look: your own thinking. Diana says sometimes the hardest thing to change in a system is your own mind. Patterns that worked when you were pushing PHP into a CMS are different from what you need for event-driven microservices. The difference is not just in the code, it is in the entire structure.
Three Types of Patterns
Diana groups patterns into three categories:
External patterns. Forces from outside your system. Users change their expectations. What was acceptable UI ten years ago looks like a scam now. People used to wait two minutes for a page to load. Now they leave in seconds. Social forces affect hiring, leadership, conference culture, funding.
Technology system patterns. Where you put code. Layers. Services. How parts communicate. When they communicate. What they communicate. Data management. All of it follows patterns, and all of it is interconnected.
Process patterns. How delivery works. How decisions get made. How roles are defined. Follow the money, Diana says. If you model how money flows in your organization, you will learn a lot about why the system is the way it is.
Systems thinking is about how these three types of patterns intersect and interact. You cannot change all patterns at once. You look for small changes with big impact.
Seven Questions for Pattern Thinking
Diana gives us a practical tool. Seven questions to ask when you are trying to identify patterns in a system:
- How does information flow?
- What are the events that happen in the system?
- What are the boundaries?
- What are the building blocks?
- What is the delivery process?
- How are people organized?
- How is discourse structured?
She applies these to the MAGO case study from the book. MAGO went from weekly magazine publishing to 24/7 multi-channel content delivery in ten years. Nobody understood how system patterns worked together. Software parts were glued together by people moving information by hand. The seven questions revealed everything: information flows in an open system now, boundaries match tools rather than domain logic, people are organized by product not value stream, and discourse is more politics than collaboration.
My Take
This chapter made me think about how many times in my career I saw teams add linters, add tests, add monitoring, add processes, and nothing really changed. Because the underlying mental model was still “move fast, blame people when things break.”
Pattern thinking is not about memorizing design patterns from a book. It is detective work. Watching what happens, finding invisible connections, understanding what forces are at play.
The seven questions are actually useful. Next time you are stuck on a systemic problem, try running through them. You will probably see something you missed before.
Previous: Chapter 8: Designing Feedback Loops