Two pieces this week described the same mechanism from opposite sides. Outside the building, users stop filing bug reports when they stop believing a report goes anywhere, so a defect list surveys the patient and the hopeful rather than the broken. Inside it, engineers route their write-ups toward whichever team answers, so the responsive owner accumulates tickets and the unreachable one accumulates workarounds in other people’s code. Set side by side, those aren’t two observations. They’re one, and it’s simpler than either: the number of reported defects is not a property of the software. It’s a property of the relationship between whoever hit the problem and whoever owns it.

That reframing does real work, because it changes what the count can move in response to. If the number describes the software, it goes up when the software gets worse and down when it gets better, and those are the only two stories. If it describes a relationship, it also goes down when the relationship degrades — when the form gets one field longer, when a maintainer burns out, when three tickets in a row got closed as “working as intended,” when the person who used to shepherd reports moved teams. None of that touched the code. All of it moves the number, and it moves it in the direction that reads as good news.

It’s worth being precise about how this differs from the usual story about metrics going bad. The familiar failure is a target: name a number, tie it to someone’s review, and watch cheap ways of moving it get taken. This isn’t that. Nobody has to be gaming anything, and nobody has to have been told the ticket count matters. A team that becomes unresponsive by accident — because they’re underwater, or reorganized, or simply slow — gets the improved number anyway, on exactly the same schedule as a team that did it on purpose. The reward arrives with no decision behind it, which is what makes it so hard to notice. There’s no moment where someone chose wrong.

And the reward is real, because in most organizations “few bugs reported” is read as a quality result and quality results attract nothing. No audit, no process review, no staffing conversation. So a service degrades, its consumers give up on reporting, its ticket count falls, and the falling count is precisely the evidence used to justify not looking at it. The feedback loop closes cleanly and points the wrong way, and every number involved stays honest — each one is a correct count of things that were actually filed.

What follows is that a defect count is never interpretable alone. It needs a second, independent read on the same question, gathered through a channel that isn’t the reporting channel: client-side error rates from the population that never files, workarounds in your consumers’ repositories named after your service, or the answer to the question “what did you stop trying to do” asked directly of the accounts that went quiet. When those disagree with the ticket count, the ticket count is the one that’s wrong, and the size of the disagreement is the measurement you actually wanted.

The uncomfortable version: every organization has at least one component whose reputation for stability rests entirely on the fact that people gave up telling anyone about it. It won’t appear on a list of risks, because the list is built from reports. It’s the one nobody has mentioned in a while.