Systems Thinking Chapter 5: Replace Reacting with Responding
This chapter hit close to home. If you ever rage-typed a Slack message, hit send, and then immediately wished you could unsend it, this one is for you.
Diana Montalion starts Chapter 5 with a simple idea. Systems thinking means moving from reacting to events to responding with thought-out patterns. Sounds easy. It is not.
We Are All Reacting, All the Time
Think about your last meeting. Someone said something you disagreed with. What happened inside your head? Probably a mix of thoughts, emotions, maybe your jaw tightened. That is a reaction. It just happens. You don’t choose it.
Diana shares her own example. During a Slack discussion, she said something she thought was respectful. The other person took it badly. What followed in Diana’s mind was a parade. Sorry for hurting feelings. Wanting to push back. Embarrassment. Anger. Quitting Slack and reopening it. Multiple times. Deciding “this is what they always do.”
She did not respond. Wrote down reactions instead. Took a break. Came back. Situation had resolved itself. And she realized three things worth taping to your monitor:
- None of her reactions had anything to do with the actual problem they were solving.
- If she had reacted, she would have damaged the relationship. Instead, next day they had a friendly conversation and built more trust.
- Her reactive patterns were so predictable, half the list would be the same in any situation. Yet she always trusted them in the moment.
That third point is brutal. We keep trusting the same reactions that keep failing us.
The Opinion Problem
Diana talks about something I see in tech every day. We are an opinion-driven culture. We treat opinions like facts.
We debate everything as binary. Agile vs Waterfall. Monolith vs microservices. Cloud vs on-prem. Nobody says “it depends on context.” Even though it always does. We want to be right. We focus on what the other person said wrong. We ignore context. We form tribes around shared opinions.
The definition of opinion is “a view or judgment not necessarily based on fact or knowledge.” As knowledge workers, our real expertise is not having correct opinions. It is the ability to change and update them as we learn.
I spent years defending positions just because they were mine. Changing your mind is not weakness. It is literally the job.
Empathy Is Not a Soft Skill
This section surprised me. Diana says empathy is a core systems thinking skill. Not a nice-to-have. Not a “soft skill” for HR workshops. A core technical skill.
She gives a great code review example. You can review code by analyzing quality, checking tests pass, and requesting changes to inefficient parts. Or you can review code by understanding what the developer is trying to accomplish and recommending changes that help them do it better. In both cases, you leave the same comments. But in the second case, you also left understanding.
That word, understanding, is the difference between a review that makes someone defensive and a review that makes someone better.
Important distinction though. Empathy does not mean agreeing. You can empathize with someone who writes nasty code review comments and still ask them to change behavior. Understanding is not enabling. Respect is acknowledgment, not tolerance.
Many teams confuse “being empathetic” with “avoiding accountability.” Diana calls this out directly. If organizational culture is causing systemic problems, tolerating it without changing it will change nothing.
Create Space for Reactions
Our reactions are messy. That is fine. The goal is not to eliminate them. The goal is to hold them without acting on them immediately. Diana gives four guidelines:
- Notice them without judging them.
- Look for useful information in them.
- Don’t suppress them.
- Manage your own reactions and let others manage theirs.
She tells a story about a new architect in a meeting. During a screen share, a Slack notification pops up from the team’s boss, who is also in the meeting. It says “I don’t think we should trust what she says, she’s not technical enough.” Everyone sees it.
The architect did not react. Kept focusing on the actual problem. A month later, the boss was happy with her. But the point is that reacting would have derailed the real work. The boss was wrong. Time proved it. Only because the architect did not let the reaction take over.
Reactions contain useful information though. That architect feeling insulted was valid. The pattern of people assuming she is not technical enough is a real systemic issue. Reactions are not bad. They are just tangled. You need to sort through them before responding.
Practical Stuff That Actually Works
Diana recommends some surprisingly non-technical practices:
“Yes, and…” This is from improv comedy. Instead of shutting down ideas with “no, that’s wrong,” you acknowledge what was said and add to it. This does not mean agreeing. It means not contracting into defensive mode the second you hear something you disagree with.
Compare these two responses to “We need the API response times to be faster because connections are dropping”:
- “The response times are fast enough. That’s not the problem.”
- “Thanks for describing the impact. I wasn’t aware of slow response experiences. What alerted you to this?”
Same technical disagreement. Totally different outcome.
The 24-hour rule. Wait 24 hours before responding to something that triggered you. Diana says this changed her life. When she waited and re-read emails the next day, at least half the time she had simply misunderstood.
Breathe. Yes, breathing exercises. She taught them to software engineers expecting them to walk out. Instead they asked for more. Stress is constant in our work. Box breathing actually helps. Four counts in, hold four, four counts out. Five minutes.
Walk, eat, nap. There is an acronym, HALT. Hungry, Angry, Lonely, Tired. You are more likely to overreact when any of these apply. Fix the basics before you try to fix the code.
Write it down. Set a timer and write everything in your head. Do not edit. This is not for sharing. It is for sorting your reactions from your actual thoughts.
The Rain Story
Diana ends with a personal story. She is standing in the rain waiting for her husband. He is late. She is soaked, angry, sending texts. Then scared because he is not answering. Then angry again when he shows up.
In the past, they would spiral into blame. This time, he acknowledged her experience first. “You’re so wet, I’m so sorry, that must have sucked.” Then told his story. Lost phone. Blocked car in parking lot. The blocking car’s driver had chest pains and was taken by ambulance.
Her anger was valid. His delay was valid. Nobody was wrong. The stories did not have to be the same.
That is systems thinking. Your point of view, real as it is, is not the whole story. When we react, we are almost always blaming. We project our story onto others. Blame rarely helps solve the actual problem.
Sometimes the right move is to just dry off and go home.
This is part of a series retelling “Learning Systems Thinking” by Diana Montalion (O’Reilly, 2024). See the intro post for the full series outline.