Why Your Team Stopped Reporting Problems

The near-miss reports stopped. The team has fewer escalations than last quarter. The aging items are lower on the board. None of these are signs the system improved.

They might be signs that the measurement system learned something — specifically, that reporting problems is risky and protecting the dashboard is safe. When that learning happens, the numbers get better while the delivery does not. The dashboard produces comfort. The system produces late releases.

The silence that looks like progress

When dashboards get cleaner without any obvious cause, leadership tends to interpret this as evidence that something is working. The pressure is having an effect. The new process is helping. The team is stepping up.

A less comfortable interpretation is that the reporting system was trained. When bad numbers triggered scrutiny, someone found a way to make the numbers less bad. Not through better delivery — through better number management. And because management's visibility into the system comes through those same numbers, the signal got quieter while the underlying problem persisted or grew.

This is not unique to software. Any measurement system attached to personal consequences teaches the same lesson: manage the measure, not the thing being measured.

Why rational people stop reporting honestly

When showing a problem triggers a performance conversation, engineers learn quickly that honesty has a cost. The cost is personal: scrutiny, extra meetings, questions about competence, the uncomfortable sense of having publicly revealed that something is wrong on your watch.

Nobody has to be told to protect themselves. The incentive is obvious and immediate. Escalate an aging item and the next meeting asks why it got that way. Leave it off the escalation and it disappears from the conversation until someone asks about the release date — at which point the problem is real, visible, and considerably harder to address.

Teams that stop reporting problems are not doing something wrong. They are doing something entirely rational given the structure they are operating in. The system produced the behaviour.

The aviation lesson

Airlines spent years treating near-miss reports as evidence of pilot error. When a pilot disclosed a close call, the disclosure became a liability. The number of near-miss reports declined steadily — and for a while, that looked like an improvement in air safety.

It wasn't. Incidents were not decreasing. Reporting was decreasing. The aviation industry eventually recognised this and reversed course, building confidential incident reporting systems that separated honest disclosure from individual accountability. The insight was uncomfortable: when disclosure is risky, you get fewer disclosures, not fewer events.

Delivery teams follow the same logic. Aging items, WIP creep, missed targets — these are not character flaws. They are system signals. Treating them as personal failures teaches people to make the signals disappear rather than to fix the underlying conditions.

How this plays out in delivery teams

The mechanics are familiar to anyone who has worked close to the board.

Aging items get split. A ticket that has been in progress for four weeks becomes two tickets — one closed, one new. The cycle time resets. The aging item disappears from the report.

Tickets get moved to Done before they are done. The testing is cursory. The acceptance criteria are interpreted generously. The sprint burns down cleanly. A follow-up ticket appears the next day describing something that turns out to be the same unfinished work.

Work that doesn't fit the workflow gets handled outside it — through informal channels, direct commits, undocumented hotfixes. The board looks calm. The system is noisier than it appears.

Each of these is a rational individual response to a measurement system that punishes honest reporting. None of them improve delivery. All of them degrade the signal that leadership depends on to understand what is actually happening.

The difference between system metrics and person metrics

Cycle time, WIP, and throughput measure system behaviour. They describe what happens to work as it moves through a set of policies, queues, and handoffs. They are not measures of individual performance, because the same person will produce different cycle times depending on which queue they enter, which dependencies they encounter, what review capacity is available, and what priority sequence they happen to be working through.

Using aggregate system metrics as individual scorecards is the mechanism of dysfunction. It is not just that it produces unfair assessments. It is that it destroys the signal. The data that was measuring the system starts measuring the countermeasures people deploy to protect themselves from the system.

The structural fix

Separate the use of metrics from the use of metrics against people.

Cycle time data belongs in diagnostic conversations about the system: where is work accumulating, what policies are producing queues, what interventions are worth testing. It does not belong in performance reviews, individual evaluations, or any context where it can be attributed to a person's effort or competence.

Performance conversations require different instruments — ones based on observed behaviours, decisions, and outcomes the person actually controls. Those conversations are valuable and necessary. They just require different data.

When teams see that flow data is used to understand the system and design interventions rather than to rank or judge individuals, the incentive to game it disappears. Honesty stops being expensive. The board starts showing what is actually happening.

The hardest part

Most leaders who created this problem did not do it cynically. They wanted accountability. They saw numbers and attached them to reviews because numbers feel objective. The intent was reasonable.

The problem is that accountability attached to a lagging system metric produces exactly the opposite of accountability. It produces metric protection. The numbers that were going to tell you the truth start telling you the story that keeps people safe.

The way to get better numbers is to stop using numbers to judge people. Honesty becomes rational the moment it stops being risky.

If you announced tomorrow that no cycle time data would ever appear in a performance review, ask yourself what your team's board would look like in a month. Would the numbers get worse — or would they become more honest?