Systems Thinking Chapter 8: Designing Feedback Loops

When you hear “feedback loop” you probably think about monitoring dashboards. Or autoscaling. Or maybe that annoying annual performance review your manager gives you. Diana Montalion says all of that is too narrow. Chapter 8 is about feedback loops for thinking. Not for servers.

Not the Feedback You Think

Most organizations have some kind of feedback process. RACI models, RFCs, manager reviews. Diana argues these are often not real feedback loops. They are sign-off processes dressed up as feedback.

RACI assumes people higher on the org chart are automatically good at giving feedback. That has not been my experience either. I’ve seen senior managers approve things they barely understood. And I’ve seen junior developers catch critical issues that nobody else noticed.

RFCs sound great in theory. Request for Comments. But comments are usually opinions, not well-reasoned propositions. It becomes a popularity contest. “I like it” or “I don’t like it” without explaining why. That is a survey, not systems thinking.

Manager feedback is often just about compliance. “You need to do X better.” OK, but does the manager actually understand the system better than the person working in it every day? Sometimes yes, sometimes no.

The feedback Diana talks about is different. You want feedback that makes your reasoning stronger. That helps you find holes in your thinking. That tells you if you are about to hit an iceberg.

Building Conceptual Bridges

Here is my favorite idea from this chapter. Our legacy systems reflect our old mental models. The code we wrote five years ago shows what we believed five years ago. If we want to change the system, we can’t just swap tools. We need to change how we think together.

Diana introduces this concept of “conceptual bridges.” When people in an organization can’t communicate well, they build software parts that don’t communicate well either. Conway’s Law in action, basically.

There are four big gaps that prevent bridge-building:

Point of view blindness. When people can’t agree on a solution, they are usually solving different problems without knowing it. An accountant and an engineer look at cloud costs from completely different mental models. Before jumping into solutions, make sure everyone agrees on what the actual problem is.

Language barriers. Not English vs Spanish. More like “product team language” vs “engineering language” vs “business language.” Diana gives a great example with the word “performance.” She used it meaning one thing, but her audience understood something completely different. Same word, opposite meanings. I’ve seen this many times. When someone says “scalable” in a meeting, half the room thinks about technical scalability and the other half thinks about business growth.

Resistance. This one is painful but real. Some people just don’t want to collaborate. They prefer command-and-control. They build conceptual moats around their teams. Diana is refreshingly honest here. She says not everyone becomes delightful when empowered and understood. Sometimes people are purposefully difficult. And toxic cultures often reward this behavior instead of fixing it.

Lack of transparency. When leadership makes decisions behind closed doors and hands them down as tasks, real change is unlikely. If the people who implement solutions never interact with the people who designed solutions, conceptual integrity is impossible. You can’t build good software if half the team doesn’t know why they are building it.

Ask for What You Need

Diana gives very practical advice about getting useful feedback. Don’t just say “what do you think?” Ask specific questions:

• Have I understood the situation correctly? What am I missing?
• Is this factually correct?
• What confused you?
• Can you repeat back what you think my main point is?

That last one is gold. Asking someone to repeat your conclusion back to you is humbling. You realize how often your “clear” message was actually mud.

Also, think carefully about who you ask. She lists several types: people who can edit your writing, subject matter experts, people with different viewpoints, people who will be impacted by your recommendation, and people who will pay for it. Each group gives you a different kind of feedback.

The Golden Rule of Feedback

Take what you need and leave the rest.

Simple, right? But most of us either take everything personally or ignore everything that hurts. Diana shares her experience with conference talk feedback. Someone writes “this sucked” with no explanation. Not helpful. Someone writes “I loved it.” Also not helpful. The useful feedback is specific. “Your third example was confusing” or “you might create a bottleneck with this approach.”

She also makes an important point about consent. You get to decide what feedback to accept. This doesn’t mean ignoring experts or science. It means thoughtful discernment. If someone only ever gives you negative feedback no matter what you improve, their feedback is unreliable. Find someone who can see the forest and the trees.

Don’t Forget to Learn

Here is something teams often skip. You design your feedback loop, get great input, make a decision, push to production. Three hours later, chaos. The feedback was wrong. Or the opposite, everyone said your idea was bad, but it worked perfectly.

Diana says extend your feedback loop past the decision point. Measure the impact. Learn from what actually happened. That is the core of systems thinking, really. Not just deciding well, but learning from the results.

Bugs in Your Thinking

The last part of the chapter is about logical fallacies. Diana calls them “bugs in our reasoning.” I love this framing because it makes them feel fixable, not shameful. We all have them.

She walks through common ones with tech examples:

Strawman. Someone recommends cloud-native tools. Response: “You hate open source!” That is attacking a fake version of the argument.

Anecdotal. “We tried microservices and it was a disaster.” Past experience alone doesn’t prove it will fail again. What changed since then?

Appeal to authority. “The CTO said it won’t work.” OK, but what were the CTO’s reasons?

Bandwagon. “Everyone is using Kubernetes.” Popularity is not validation.

Ad hominem. “Hollis overcomplicates everything!” Attack the argument, not the person.

Slippery slope. “If we use AWS, we’ll be locked in and bankrupt.” You can’t reject an idea by predicting catastrophe without showing the connection.

I’ve seen every single one of these in real meetings. Multiple times. Once you learn to spot them, you can’t unsee them. And that is kind of the point Diana is making. We are trained to use logical fallacies, not to spot them. Systems thinking is learning to spot them.

What I Take from This

Feedback loops are not just monitoring tools or annual reviews. They are how we think together. Design them badly and your team makes bad decisions. Design them well and even average teams produce great work.

The practical takeaway: next time you need feedback, don’t just ask “thoughts?” Write down three specific questions. Pick the right people to ask. And after the decision is made, keep watching. The learning doesn’t stop when the PR gets merged.

This is part of a series retelling “Learning Systems Thinking” by Diana Montalion (O’Reilly, 2024).