Systems Thinking Chapter 4: Self-Awareness as a Foundational Skill
Chapter 4 starts Part II of the book. And Part II hits different. Part I was about systems out there, in the world, in software. Part II turns the mirror around. Now we’re looking at ourselves.
Diana’s main point is simple. You cannot improve your thinking if you are not aware of your thinking. Your most intimate system is you. Start there.
Metacognition, the Fancy Word
Systems thinking is grounded in metacognition. That’s basically thinking about your own thinking. Not just what you think, but how you think, why you think it, and where those thoughts come from.
There is a nice distinction Diana makes here. The difference between having an opinion and reaching a conclusion. When you reach a conclusion, you know how you got there. And you can show the path to others. Opinions just appear. Conclusions have a trail.
You are not just thoughts. You are a whole system of cognitive patterns, feelings, beliefs, habits, and experiences. All of this runs together. All of it shapes your decisions. Most of the time you don’t even notice.
If you ever did Retrospectives in Agile, you already practiced metacognition. Same idea, just applied to your own head.
The Hard Parts
Here is what surprised me. Diana says the hardest part of systems thinking is not building event-driven architectures or managing infrastructure as code. Those are hard, sure. But harder still is developing tolerance for ambiguity and uncertainty.
We love concrete answers. One right solution. This or that. But systems don’t work like that. The more complex a system is, the more ambiguity there is. There is rarely one correct point of view.
She gives this example about tradeoffs. Maybe your service is not as fast as you wanted. But it is reliable. And in this case, reliability matters more. Systems thinking is about accepting that you can’t have everything. You pick what matters most for the situation.
Linear thinking wants certainty. Systems thinking says, sorry, you can’t be certain about anything. Every decision is, to some extent, a guess. Every change is an experiment. And that gap between what we intend and what actually happens, that’s where innovation lives.
Your mind is your instrument. Mastering it is harder than any cloud architecture you will ever encounter. I felt that one.
Signal vs Noise
This section is gold. Diana talks about how your mind gives you an endless stream of thoughts. Some are useful. Most are noise.
She tells a story about coding. When she hits a hard problem, her mind says “I’m hungry, let me go to the grocery store.” Sounds reasonable. But the real goal is avoiding discomfort. The secondary goal is chocolate. Solving the actual problem is a distant third.
Then she flips it. Sometimes when she is deep in a problem for hours, the thought “go eat something” would actually be helpful. But she ignores it. She keeps grinding. Then finally gets up, makes a snack, walks the dog, comes back, and immediately sees the solution.
The loud thoughts are not always the important ones. The quiet ones sometimes carry the real signal.
She introduces the Cupholder Dilemma. When designing a car, the architect wants to talk about the engine. The stakeholders want to talk about cupholders. In tech we call this bikeshedding. But the stakeholders are not entirely wrong. Cupholders matter to daily life. The key is timing. Know when to talk about the engine and when to talk about the cupholders.
Discernment is the superpower here. Not generating new thoughts. Just knowing which ones matter right now.
Observe, Don’t Fix
Diana says don’t start by trying to fix your thinking. Start by watching it. This is the same approach you’d use with any system. First, understand how it actually works. Then consider changes.
She compares it to the new boss who wants to transform the software without knowing anything about it. Or the team that adopts Kubernetes as a silver bullet and creates more problems than it solves. Without awareness, your fixes are New Year’s resolutions abandoned by February.
Just observe. Notice your patterns. What triggers you? What drags you away from focus? Watch your thinking like you’d watch a new codebase before refactoring.
The Practice: Just Write
Diana recommends a specific exercise. Wake up every morning, grab pen and paper, set a timer for 10 to 20 minutes, and write whatever comes to mind.
That’s it. No rules about content. If you get stuck, write “I don’t know what to write” until more thoughts come. If you think the exercise is stupid, write about why it’s stupid. The only rule is keep your hand moving.
She says you will come up with 17,659 reasons not to do it. If 20 minutes is too much, do 10. If 10 is too much, do 5.
She shares a personal story. At one job, everything was chaos. Leadership changes, endless disagreements, bad strategies, hostile meetings. She couldn’t tell what mattered anymore. During morning writing, she asked herself: “What if I were in charge? What would I do?” She wrote it all out. And through that exercise, she found clarity. She didn’t show anyone. She didn’t need to. She knew what to do. Eventually she left that organization, not as a reaction, but as a solid choice.
Other practices work too. Walking, running, meditation, making art. The practice itself doesn’t matter as much as showing up for it consistently.
Blind Spots and MAGO
Diana returns to MAGO, the fictional organization from earlier chapters. We all live in binary mental models. Manager vs contributor. Frontend vs backend. Systems thinking is nonbinary. It’s about the nuance between and beneath those categories.
We all have blind spots. The problem is when we forget that everything we’ve been conditioned to think may not be true.
For MAGO, she suggests five activities: model the current system, research similar systems, listen to the pain, make prototypes, and ask “what if we do nothing?” That last one is interesting. Follow the path of doing nothing all the way to the end. The things organizations fear most are usually not the things they should fear.
12 Things Self-Awareness Taught Me
Diana closes with a personal list. A few that stuck with me:
- The quality of my deliverables equals how well I can tell good thinking from habitual thinking.
- Fighting other people’s thinking is usually a waste of energy. Demonstrating sound thinking works better.
- My thoughts are not always truthful, reasonable, or in my best interest.
- The quality of my thinking improves when I’m focused. It degrades when I get busy.
- I make bad decisions when emotions lead the way. I make even worse decisions when emotions are ignored.
That last one is something I keep thinking about. Not too much emotion, not too little. The balance matters.
My Take
This chapter is where the book gets personal. Diana is basically saying: before you try to fix any system out there, fix how you observe your own system. Not fix in a forceful way. Just notice. Watch. Learn how your mind actually works instead of how you think it should work.
As someone who spent 20+ years building software, I can confirm. The hardest bugs I ever dealt with were not in the code. They were in the thinking that produced the code. Wrong assumptions. Unexamined habits.
The morning writing practice is something I want to try. Diana’s story about finding clarity in chaos is convincing. Sometimes you need to listen to yourself before you can listen to anything else.
Previous: Chapter 3: Shifting Your Perspective