The Signal Is Always There
your system is knocking, but there's nobody home
I’ve been thinking about feedback loops lately - because I’ve been paying attention to what it actually feels like when someone’s really listening to you, and how rare that is, and what it costs when it doesn’t happen.
We’ll get to that.
First, let’s talk about your bug backlog.
The Reception Problem
Most teams I’ve worked with don’t have a broken feedback loop. They have a reception problem. The signal is coming in fine, but the listening is failing.
The plot is always the same. Someone files a bug. It gets triaged, assigned a priority, dropped into the backlog. Work continues, and features ship. Everyone feels like the system is working, but the bug is still there three or more cycles later sitting around waiting for someone to make a decision.
The first time a team hears “deployment is always rough,” it registers as a warning. The tenth time, it’s just a fact about the world. The signal didn’t change, their relationship to it changed. That’s the trap, and it’s a gradual one, which means there’s no single moment where someone made a bad call. It’s a slow drift that looks like normal operations from the inside.
Daniel Kahneman and his co-authors call this kind of thing “noise neglect” in their book Noise: A Flaw in Human Judgment. There’s a tendency for organizations to be completely unaware of the variability and dysfunction already present in their own decision-making. The signal is there, but nobody is listening to it.
The Backlog Is Not a System
What makes this particularly costly is that a bug backlog isn’t free. Teams treat it like a neutral holding pen, but it’s not neutral at all. Every cycle, engineers spend time re-reading the same reports, re-contextualizing the same issues, re-triaging the same decisions. None of that work moves anything forward. It’s the overhead of a decision that hasn’t been made yet, paid over and over again.
I wrote about this a while back in a post called Clean, and the core idea remains correct. Teams should aim for zero bugs in the backlog, not because software doesn’t have bugs, but because every bug should be dealt with, either by fixing now or consciously closed. Triage feels like listening, but it isn’t. Process without reception isn’t a feedback loop. It’s just a paper trail.
Features Have Advocates. Bugs Have a Backlog.
The reason decisions don’t get made is almost always structural. Features arrive with built-in urgency in the form of a deadline, a commitment, or a demo that’s already on the calendar. Bugs arrive with a ticket number. The system isn’t designed to weigh them against each other honestly, so it doesn’t. Features usually win by default. The prioritization process was never really built to surface that tradeoff honestly.
What people miss is that shipping features into a system with unaddressed quality signals isn’t a neutral act. When you do this, you’re not just deferring the fix, you’re building on top of a foundation you already know is unstable, and the feedback was telling you that.
Again, you just weren’t listening.
Won’t Fix Is An Honest Act
Choosing to not fix a bug and close it can feel weird. It can feel like giving up, but it isn’t. Closing a bug as won’t fix is one of the most honest things a team can do. It means you heard the signal, you evaluated it, and you made a real decision. That’s what a functioning feedback loop looks like. Leaving it to rot in the backlog is neither fixing it nor deciding. It’s noise accumulation dressed up as process.
The question every team should be asking about their old bug reports is simple. Did this problem go away, or did we just get used to it? Most teams never ask it, even though most of the time, the answer is the second one.
What Normalization Does to People
There’s a human cost to all of this that doesn’t show up in the metrics. Someone filed that bug report. Someone raised that same issue in the retro, and then again the next cycle. At some point, they stopped doing it. Not because things got better, but because they learned it didn’t matter. Normalization doesn’t just degrade your system. It degrades the people in it. It teaches them that their signal isn’t worth sending.
I’ve been having a lot of conversations lately that have re-emphasized how I think about this. There’s something that happens when you’re genuinely heard, when someone receives what you’re actually saying instead of routing it into their existing model of the world, that’s hard to describe if you haven’t felt it. It’s grounding in a way not much else is. And it makes you realize how often the opposite is happening, how often the people around us are processing our words without really taking them in.
A team that’s normalized its bug backlog (or normalized anything else in their feedback loop) has done the same thing. The signal is still coming. The reports are getting filed. The signal is there, but nobody’s actually receiving it anymore.
The fix isn’t process, it’s attention. Pay attention to what your system is already telling you, be honest about what you’ve been ignoring, and then do something about it.
That’s harder than it sounds, but it’s the only thing that actually works.
If this resonates with a problem you’re facing, I have a few consulting slots open. Book some time with me here.