Systems Thinking Chapter 7: Collective Systemic Reasoning
Chapter 7 is where Diana shifts from “you” to “we.” Previous chapters were about your own thinking, your own reactions, your own learning. Now it’s time to think together. Because in systems, your brain alone is not enough.
Stop Sharing Opinions, Start Building Propositions
Here’s the core idea. Most of us at work just share opinions. “We should use Kafka.” “This architecture won’t scale.” “Let’s rewrite it in Rust.” Strong feelings, zero reasoning behind them.
Diana says there’s a better way. She calls it creating a proposition. Not an opinion. Not a gut feeling. A structured idea with reasons attached to it. A proposition has three parts:
- Your idea, action, or theory (the premise)
- Three to five solid reasons that justify it
- Why this matters right now for the system
Sounds simple. It is not. Diana is very honest about this. She says your ideas feel strong and clear in your head. Then you try to write down the reasons that convinced you. And suddenly you realize you don’t actually know why you believe what you believe. You just kinda know. Or you think you do.
I’ve been in this exact situation many times. Sitting in a meeting, absolutely sure about something, then someone asks “why?” and I’m standing there like a deer in headlights. Twenty years of experience and I can’t explain my own reasoning. That’s the gap Diana wants us to close.
Why Your Thinking Alone Is Not Enough
Your propositions will always be limited by your own point of view. Diana makes this very clear. No matter how smart you are, you see the system from one angle. You need other people to see the full picture.
She gives a practical example. Five people are discussing a problem. They use the same words. They nod at each other. And they are solving five different problems. I’ve seen this happen so many times it’s almost funny. Almost. It’s actually expensive and painful.
Collective reasoning is not “kumbaya, everybody agrees.” It’s the opposite. You actively engage with people who disagree with you. On purpose. Not to fight them, but to understand what they see that you don’t. When someone raises a concern about your idea, that concern should make your idea stronger, not make you defensive.
Diana makes an important distinction here. Systemic reasoning is not changing hearts and minds. You cannot change other people’s minds. They change their own. All you can do is offer a well-reasoned point of view. The rest is up to them.
The Proposition Template
The practical part of this chapter is gold. Diana gives you a four-step process for building a proposition:
- Write down your idea clearly
- Write three to five reasons that support it
- Strengthen those reasons until they are clear, logical, and convincing
- Be honest about potential pitfalls and disagreements
Then she introduces something she calls the Top-Down Elaboration, or TDE. It’s a one-page document with six sections: Summary, WHY, WHAT, WHO, HOW, and WHEN. She’s seen teams reduce decision-making noise dramatically by using this simple format.
The WHY section is the hardest. Diana says most people confuse WHAT with WHY. “A world-class solution for our customers” is not a WHY. That’s a WHAT. Why does “world-class” matter? How would you measure it? Same action, different WHY, completely different meaning. She uses a great example. Throwing a ring into a river. Frodo destroying the One Ring. A woman ending a marriage. A thief ditching evidence. Same WHAT. Entirely different WHYs.
The WHAT section is not “install Kubernetes.” It’s “decrease downtime by 20% by rearchitecting the infrastructure to be more resilient.” See the difference? One is a tool. The other is a system improvement with a measurable goal.
Strengthen Your Reasons
Most of the chapter is about making your reasons better. Diana lists what first attempts usually look like, and honestly it reads like a description of every architecture decision document I’ve ever seen:
Wrong. Some assertions are just not true. “The latest update fixed this bug.” When it didn’t.
Weakly connected. Your reasons don’t relate to each other. “We need to fix the data structure. Our users prefer more white space.” What?
Biased. You included ideas you like and ignored the rest. “Companies with a heart and soul only use open source tools.”
Vague. The reasoning doesn’t follow. You’re mixing unrelated concerns and hoping nobody notices.
Disrespectful. Anytime you’re calling something stupid, directly or indirectly. “This workflow is a mess because marketing people got involved.”
Diana is not judging you for bad first attempts. She says they are perfectly normal and probably unavoidable. The whole point is to iterate. Write it down, see the gaps, fix them, repeat. She compares it to knitting. A well-reasoned proposition is like a warm sweater with tight stitches. A bad one is like a scarf that unravels when you pull one thread.
To strengthen your reasons, check four qualities. Are they reliable (actually true)? Are they relevant (connected to your context, not just “Netflix does it”)? Are they cohesive (working together as a whole)? Are they cogent (convincing when read together)?
My favorite example from Diana. “Netflix does it” is not a valid reason unless you are Netflix. Even a Netflix developer shouldn’t say “because this is how we do things.” Why do you do things that way? Why is it relevant now?
The Iceberg Model Returns
Diana brings back the Iceberg Model from Chapter 3. Remember? Events on top, patterns below, systemic structures deeper, mental models at the bottom.
She says your propositions will have more impact if you push your reasoning deeper. Don’t just react to what happened today. Look for patterns over time. Ask what structures keep those patterns in place. Question the assumptions and beliefs underneath.
Propositions that challenge mental models create more lasting change than ones that patch surface events. This is hard. It’s uncomfortable. But that’s where the leverage is.
My Take
This chapter changed how I write technical proposals. Before reading it, I would write something like “We should migrate to microservices because monolith is slow.” After? I realize that’s an opinion with zero reasoning. Who says it’s slow? Slow compared to what? Slow for whom? What would microservices actually solve? What new problems would they create?
The TDE format is deceptively simple. I tried it at work. Turns out, getting five people to agree on WHY before jumping to HOW saves enormous amounts of time. We spent two weeks arguing about implementation before someone said “wait, are we even solving the same problem?” We were not.
Diana says something that stuck with me. The quality of what we build is equal to the quality of our reasoning. Think of it like test coverage for ideas. When we leave gaps in our thinking and push them to production, we create technical debt. Not code debt. Thinking debt. And that’s the hardest debt to pay off.
Previous: Chapter 6: A System of Learning