The last piece was about the people outside the building — how a defect list records not what is broken but who still believed telling you would help. The filter is not a consumer phenomenon. It runs just as hard inside a company, between teams, and there it does something stranger than suppressing information. It inverts it.

Consider two internal services, each with an owning team. The first team triages within a day, replies in the thread, and ships a fix in the same sprint about half the time. The second team has a form that routes somewhere unclear, answers in two weeks when it answers, and closes issues as “cannot reproduce” more often than not. Now put yourself in the position of an engineer on a third team who has just hit a problem in each of them. You have an hour of slack and two write-ups you could produce. You will write the one that goes to the responsive team. The other problem does not stop existing; it becomes a comment in your own code, a retry wrapper, a note in your team’s runbook saying that service is flaky, work around it.

Six months later somebody pulls the numbers. The first service has four times the reported issues. Every dashboard agrees, and the reading is obvious and completely backwards: the responsive team has a quality problem. They get the audit, the process review, the uncomfortable questions about their testing practices. The second team, whose actual defects are distributed silently across a dozen other codebases in the form of workarounds nobody counted, looks stable. They are not stable. They have simply pushed the cost of their defects onto their consumers so effectively that the cost stopped being visible as defects at all — it turned into other teams’ code, other teams’ incidents, other teams’ on-call pages.

What makes this worse than the external version is that people learn it. The lesson available to any team watching this happen is not “be more responsive.” It is that answering is expensive and being hard to reach is free. Nobody says that out loud, and nobody has to decide it deliberately; the ticket count rewards it automatically. A team that lets its intake channel decay gets a quieter quarter and a better-looking dashboard, and the mechanism by which that happened is invisible to every metric anyone is watching.

The tell, if you’re looking for one, is in the workarounds rather than the tickets. Grep your own codebase for the retries, the sleeps, the special cases named after another team’s service, the comments that begin with “this is a hack because.” Every one of those is an unfiled bug report, complete with a reproduction case, sitting in the wrong repository. Count them by which dependency they defend against and you get something much closer to a real defect map — and it will not resemble the ticket counts, because the two are measuring opposite things. Tickets measure the belief that reporting works. Workarounds measure the belief that it doesn’t.

The correction is not to punish quiet teams either, since some of them genuinely are stable. It’s to stop treating report volume as a property of the system being reported on. It’s a property of the relationship between two teams, and it moves when either side changes. A rising ticket count on a service can mean it’s getting worse, or that its owners just got easier to talk to, and those two stories require opposite responses. If you can’t tell which one you’re looking at, the number isn’t telling you about your software. It’s telling you about your org chart.