Systems Thinking Chapter 10: Modeling Together - Part 1
Chapter 10 is a big one, so I’m splitting it into two parts. This is Part 1 of 2.
Diana opens with a Donella Meadows quote that sets the tone for everything that follows: get your model out where people can see it, invite others to challenge it. That’s the whole chapter in one sentence, really. But of course there’s much more to unpack.
Modeling Is Not Optional
Diana makes a strong statement right away. In an organization, systems thinking is not happening without modeling. If you and your team are not modeling together, you are not doing systems thinking. Period.
And this makes sense if you think about it. Systems thinking is about seeing relationships, seeing the whole. You can’t do that alone. You need multiple perspectives. You need people looking at the same thing from different angles. Modeling is the tool that makes this possible. It gets the thinking out of individual heads and into a shared space where everyone can see it, argue about it, and reshape it.
What Is Modeling, Really?
When Diana says “modeling,” she doesn’t mean what most of us picture. Most software people hear “model” and think UML diagrams, C4, ArchiMate, cloud architecture diagrams. Maybe TOGAF or SAFe if you work in enterprise.
She lists the usual artifacts: interaction diagrams, infrastructure models, ADRs, requirements docs, wireframes, ML models. These are all valuable. But making them is not what she means by modeling.
Here’s the key insight. How we model is more important than what we model.
In systems thinking, we are not trying to capture a static image. We are generating insight. Peter Senge said systems thinking is about seeing interrelationships rather than things. Seeing patterns of change rather than static snapshots. That’s what modeling should do.
Diana breaks it down into four principles:
Models are conversations. There is no right way to converse. A healthy modeling process matters more than which tools you pick.
Modeling is framing questions and exploring answers. We are not trying to model “reality.” We can only frame circumstances in helpful ways and explore what exists.
Models exist in relationship with other models. A component diagram shows structural relationships but not how those components are useful to people. You need other models for that.
Modeling helps us find leverage points. Those impactful places where a change actually matters.
A Model Doesn’t Unify, Modeling Does
Diana tells a story about a systems architect hired to modernize a legacy system. The organization asked for a “north star” model to show engineers what they will be building. The architect’s response: “If a systems architect says yes to that request, fire them.”
The real problem was not a missing diagram. People held conflicting views about the system’s purpose. Teams spent more time fighting change than delivering it.
Two classic mistakes. Trying to fix social relationships with a technology model. Trying to lead systems change top-down.
What was missing was not a model. What was missing was the willingness to model together.
Some people tried. But patterns of fighting for control and sabotage overwhelmed their efforts. As Deming said, “A bad system will beat a good person every time.”
I have seen this many times. You cannot fix people problems with technical artifacts. A pretty diagram on Confluence does not make hostile teams cooperate. The process of thinking together creates alignment. Not the output.
Design Thinking Is Systems Thinking
Diana shares an interesting story about working with Dawn Ahukanna, a design principal at IBM. They built a workshop together and discovered something surprising. Design thinking and systems architecture are basically the same process with different vocabulary.
They both wrote down how they make decisions, and their steps were almost identical. Understand context. Frame the problem. Seek diverse perspectives. Collaborate. Converge to a recommendation. Get feedback. Tell the story to your audience.
If you understand that designing is not just making wireframes, then you understand that modeling is not just making diagrams. Dawn calls it working in “EX spaces”: Exploration, Experimentation, Explanation, and Execution. Each needs different tools.
There Is No One Right Way
Diana is honest about her own biases here. She learned UML in Confluence once and wanted to use it everywhere after that. Even when it did not fit. Now she defaults to sticky notes in Miro for everything, which drives her visually skilled colleagues crazy.
Three things she learned through trial and error:
Personal preferences don’t help you figure out what helps other people. What works in one circumstance might fail in another. And every modeling approach was invented to solve a real problem, so there is something to learn from each one.
Organizations sometimes adopt a Big Framework as their first modeling step. TOGAF, SAFe, whatever. Diana says this is usually a mistake. Start small instead.
Start Small
You can use familiar tools with a systems thinking mindset. Diana gives a practical table showing how common artifacts can shift toward a systems perspective. A wireframe goes from “design definition” to “shared understanding of how parts interact.” A requirements document becomes “a model of where a change fits into the system.” An ADR becomes actual systemic reasoning. A backlog of tasks becomes a backlog of impactful changes understood holistically by the team.
She even uses Jira. Yes, Jira. Not because Jira enables systems thinking (it definitely does not), but because teams with a good process can use almost any tool. The question is not “do you use Jira?” The question is “how does a Jira ticket relate to the overall systems development process?”
She re-introduces the Top-Down Elaboration (TDE) from Chapter 7 as a modeling example. It is a one-page artifact that connects the problem with the solution. It answers Why, What, Who, How, When, and describes the circumstances. Simple but effective.
The key superpower? Interlinking models. Don’t squeeze everything into one model. Link them together.
Taking a Systems Perspective
Diana gives a real-world example. Her UX team asked for requirements to wireframe. But they didn’t understand the system well enough to define requirements yet.
Instead of jumping straight into requirements, they built a capabilities model first. High-level behaviors like “Access the Platform” and “Engage in the Platform.” Under each, specific activities. Create an Account. Log In. They reviewed it with the whole team and asked: can you think of any behavior that doesn’t fit?
Then they organized work into columns: Already Built, Early Release, MVP, Launch. The team could zoom in to details and zoom out to the big picture without getting lost. They linked each capability to Confluence pages with models, diagrams, stories, and code repos.
Less about which tool you use, more about how you connect the pieces.
What Do We Model?
Diana reminds us that systemic reasoning itself is modeling. The Iceberg Model from Chapter 3 remains her most valuable tool across all circumstances.
She also recommends domain modeling. FedEx’s domain is courier delivery. Everything they build serves that. Subdomains break it down: sending, moving, delivering packages. She recommends Vlad Khononov’s “Learning Domain-Driven Design” as a starting point.
She honestly admits she hasn’t found a way to use causal loop diagrams in software design yet. Refreshing.
Finally, she brings back the seven questions from Chapter 9 as areas worth modeling: How does information flow? What events happen? What are the boundaries? What are the building blocks? What is the delivery process? How are people organized? How is discourse structured?
That’s where I’ll stop for Part 1. In Part 2, we’ll get into the rest of Diana’s guidance on collaborative modeling.
Previous: Chapter 9: Pattern Thinking