People report mistakes promptly only when it's easy to do and doesn't invite punishment

What it is

Whether an error-reporting mechanism actually collects timely, truthful reports depends on two conditions that can be designed separately: the operational cost of reporting is low enough (the entry point is easy to find, filling it out isn't burdensome, it doesn't need to pass through several layers of approval), and the act of reporting itself doesn't expose the reporter to punishment. Miss either one, and timeliness suffers. Even if an organization has already committed not to discipline reporters, if the reporting process itself demands a lengthy form and several approval layers before it can be submitted, reporters will still tend to delay or give up entirely. And even if the reporting entry point is made effortless, if reporting can still lead to being held accountable afterward, reporters will just as readily choose silence, or wait to see whether it gets noticed before deciding whether to report at all.

Why it happens

Whether reporting happens "in time" comes down to whether the reporter is willing to act right in the window immediately after the error, while memory and detail are still complete. That window is short, and any friction — whether it's friction in the process itself or a psychological worry about consequences — pushes the report later, and delay itself produces a double loss: details blur with time, degrading the report's informational quality, and whatever chain of effects the error triggers during the delay has already run its course, cutting into the report's value as well. Low operational cost solves "can someone who's willing to report do it right away"; no punishment solves "does the reporter dare to report now rather than wait to see if it goes unnoticed." These correspond to two different kinds of resistance — process friction and psychological cost — and both have to be removed at once; solving only one doesn't make the other disappear.

Studying it

A typical way to compare reporting timeliness before and after a change is to log the time interval between an error occurring and a report being filed, sampling separately before and after a process simplification (fewer required fields, more entry channels) or a policy change (an explicit no-discipline commitment), and observing how the average interval and its distribution shift. Methodological caveat: process simplification and policy change often happen together, making it hard to run a strict controlled comparison inside a real organization that separates their individual contributions. A more reliable approach is to compare submission-time differences across reporting channels of different friction (one simple, one cumbersome) under the same policy commitment, which isolates the effect of process friction on its own.

Where it stops holding

A low reporting rate can't be read straightforwardly as "few errors are happening," nor can it be read straightforwardly as "people are afraid to report" — both possibilities exist, and telling them apart needs additional evidence. If independent signals of error from the same period — rework rates, customer complaints, anomalous-operation traces in system logs — are also low, the low reporting rate genuinely reflects a low error rate. If those independent channels show an error level clearly higher than what's being reported, the low reporting rate is an illusion created by underreporting. Report volume on its own can't distinguish between the two.

Applying it

Make the reporting entry point as low-friction as possible — directly reachable from the interface where the error just occurred, with no need to jump to a separate system, required fields trimmed to a minimum, and the option to submit a brief description first and add detail later. At the same time, write the "no discipline for honest error" commitment as explicit written policy and display it right next to the reporting entry point, so the reporter sees it the moment they start reporting rather than being expected to already know it or go look it up elsewhere. To check whether the reporting rate is affected by underreporting, build at least one independent observation channel that doesn't rely on voluntary reporting — anomaly detection in system logs, rework records, complaint statistics — and regularly cross-check its trend against the reporting trend. Verification: track the distribution of time intervals between an error occurring and a report being filed, and compute the ratio between report volume and the error signal from the independent observation channel. If that ratio stays persistently low and the reporting interval stays long, at least one of the two barriers — friction or fear of punishment — hasn't actually been resolved in the current reporting mechanism.

Related

• Same group: A10.16.1 hindsight bias in accident investigation · A10.16.2 a single root-cause conclusion usually masks several contributing factors · A10.16.4 the point of an investigation is to find improvable system conditions, not to pin down who to blame
• Nearby: A10.09 human reliability and blame culture · Y7.02 error reporting
• Search terms: incident reporting · just culture · reporting friction