Teams that report more mistakes fail less

A Brazilian logistics operation with three distribution centers, 420 people. The dashboard showed the inland DC had eight damage incidents that month; the capital's DC, one. The conclusion seemed obvious, and for two quarters the capital's manager was cited in meetings as the benchmark.

Then a major client returned an entire shipment out of the capital DC. The investigation turned up fourteen problems nobody had logged. There was no fraud: there was a team that had learned that opening an incident report was extra work and invited uncomfortable questions. The dashboard was measuring willingness to report, not quality.

01The idea: the finding that came out backward #

Amy Edmondson stumbled onto this topic by accident. Studying nursing teams in American hospitals, she expected higher-performing teams to log fewer medication errors. The data pointed the other way: the better-rated teams showed up with more documented errors.

Follow-up investigation showed the difference wasn't in the error rate, but in the willingness to talk about it. In some teams, reporting was routine work; in others, it was personal exposure. The paper that formalized the concept came out in 1999 in Administrative Science Quarterly, titled Psychological Safety and Learning Behavior in Work Teams.

Three clarifications the author makes that tend to get lost in corporate translation. Psychological safety is not niceness: polite, conflict-avoidant teams often have little of it. It is not the absence of high standards: in The Fearless Organization (2018), Edmondson describes the combination of high standards with high safety as the only zone where learning happens. And it is not an individual trait: it's a property of the group, and it varies between teams in the same company.

02Why this matters in a mid-size company #

In a hospital, the cost of not reporting is obvious. In a company of 200 to 500 people, it's the same mechanism with a more mundane look: the deviation that surfaces on Friday instead of Tuesday, the wrong order that moves on to production, the client who flags it before the team does.

The point that matters to an operations manager is measurable: the difference between learning about a problem on day 2 versus day 12 is the cost of the fix. Almost every process has that curve. Psychological safety, in this framing, stops being a culture topic and becomes an operational variable — the average time between a problem happening and someone saying it happened.

There's also a compounding effect that tends to go unnoticed. When a deviation takes a while to surface, it doesn't sit still: it becomes the basis for the next decision. The wrong order generates a purchase, the purchase generates a production schedule, the schedule generates a delivery promise to the client. Fixing it on day 2 means redoing one document; fixing it on day 12 means undoing four decisions other people made in good faith on top of it.

That's why the useful indicator here isn't the number of mistakes — which is almost always underreported and says more about the team's fear than about the operation — but the interval between occurrence and record. Teams with a short interval look worse in reports and are better in practice. Teams with reports that look too clean usually don't have fewer problems: they have fewer people willing to write the problem down somewhere the boss reads it.

It's also worth separating two things that tend to get treated as one: execution error, which is the fault of whoever did it, and system error, which is a failure of how the work is designed — missing information, an ambiguous rule, an impossible deadline. Most of what shows up as individual carelessness, when investigated without hunting for someone to blame, falls into the second category. Responding to the first type with sanction and to the second with a process fix is what keeps the reporting channel open.

03The cost of a late warning #

Scale of the 420-person operation — a mid-size Brazilian company (figures in Brazilian reais), with stated assumptions for you to redo with your own numbers:

Want to see how this looks inside a real operation? Explore the platform.

The math: 14 incidents a quarter add up to 56 a year; at R$ 4 thousand each, fixed in-house, that would cost R$ 224 thousand; multiplied by six once they reach the client — return freight, replacement, trade credit, senior staff time — it tops R$ 1.3 million. The difference between the two scenarios is what the company pays for a system where speaking up early is a disadvantage for whoever does it.

04Where this breaks down in practice #

1. The metric is a raw incident count. If the number that shows up in the meeting is 'how many mistakes did your team make,' the system is paying people to hide them.
2. Reporting is expensive. A long form, a useless mandatory field, and three approvals make the cost of reporting higher than the cost of staying quiet.
3. The first question is who. Asking who did it before asking what happened shuts down the investigation at the first answer.
4. Only the big problem has a channel. Near-misses and small deviations have nowhere to go, and they're exactly the ones that teach a lesson before there's real damage.
5. The manager never makes a mistake in public. Safety gets established by the nearest example, not by a memo.

05What data-driven management answers #

There's a real risk in instrumenting this: a logging system can turn into a blame file, and then it produces the opposite effect. The difference lies in what's done with the data. If the record feeds process correction, it's a learning tool; if it feeds individual evaluation, it's the mechanism Edmondson describes as a suppressor of reporting.

It's the same reading as Deming on variation: most deviation comes from the system, not the person. And it echoes the warning in automating a bad process — instrumenting a workflow that punishes whoever speaks up just makes the punishment faster. The concrete manager behavior that supports this shows up in what makes a good manager, in data.

On the platform, that's the processes, operations, and intelligence modules, with deviation, decision, and fix in the same record, and a history of what changed afterward. The solutions by area show how this fits each operation, and a conversation can clarify what makes sense for your case.

If your quality dashboard improved without anything in the process changing, the uncomfortable question is worth asking: did the operation improve, or did the silence?