“Make no mistakes” is not a method

Make no mistakes.

The sentence sounds exacting, and it costs the person saying it nothing. It names an outcome, hands every bit of uncertainty to whoever's listening, and says nothing about how anyone detects a problem or recovers from one. As an instruction, there's no work in it.

It does change one thing, though: the first mistake now comes with a second decision. You can expose it and become the person who broke the rule, or you can smooth the surface and keep looking compliant. Owning up starts to feel like confession.

The clean report is the dangerous one#

People stop producing the information you punish them for. Amy Edmondson's study of 51 work teams found that psychological safety went together with learning behavior — asking for help, admitting uncertainty, talking about failure — which in turn was linked to team performance. Asking for help, it turns out, is part of how a team gets good.

Aviation went ahead and built this into a channel. NASA's Aviation Safety Reporting System accepts voluntary reports from people who saw or took part in a safety incident, strips the identifying details, and protects the reports from ordinary enforcement use — the FAA can even waive penalties in qualifying cases where the violation was unintentional. The whole arrangement exists to get the evidence in hand before the same conditions produce something worse.

A threatening rule will probably lower the number of mistakes reported to you. Whether the work improved is a different question, and the rule can't answer it. A mistake you can see is an event; a mistake that has to be hidden becomes infrastructure.

Stop the line before defending the number#

Toyota doesn't wait for a finished car to reveal whether every earlier step behaved. Under jidoka, equipment stops automatically when it detects an abnormality, and an operator can stop the whole line when the work drifts from what they expect. The defect never moves downstream, and the stop opens a chance to keep it from happening again.

A manager obsessed with uninterrupted output sees a stopped line and asks who slowed production. But the interruption is the quality system doing its job, and the better question is which condition got caught before three more stations added cost to it.

“Make no mistakes” puts quality at the end of the process, where someone inspects the result and assigns fault. Jidoka puts it inside the process, next to the person and machine who can notice the first abnormal signal. A line run this way can look worse for a while, since its problems become visible — but the problems were there either way.

Turn error into a control signal#

Software teams meet the same temptation through availability, where one hundred percent sounds like the only serious goal. Google's site reliability guidance argues that extreme reliability can cost more than users get out of it and crowds out useful change, so teams set a service objective and make the remaining tolerance explicit as an error budget.

An error budget sounds like permission to be careless. In Google's example error-budget policy it works the other way around: when a service overspends its budget, nonessential releases freeze and the work turns toward reliability. Failing too much changes what the team is allowed to do next.

The response should also depend on what failed. A missing profile image and leaked private contacts both count as unsuccessful requests, and they are nowhere near the same problem. You have to decide which harms actually matter and build your detection and recovery around those; a single green percentage won't do that thinking for you.

After an incident, Google's postmortem guidance looks for contributing conditions and preventive actions rather than a culprit. The more detailed workbook case study rejects “train humans not to run unsafe commands” as a corrective action, on the grounds that changing the automated systems is more dependable than hoping the next operator never repeats the move. Hard to argue with — and I still catch myself writing “be more careful” into follow-ups anyway.

Accountability doesn't go anywhere in all this. The operator still has to stop, disclose what happened, and repair it, and the organization has to make those actions survivable — then remove the trap that required heroics in the first place. Asking who touched the system last tells you much less than asking why one ordinary action could travel so far.

Design the second action#

Before the work begins, decide what happens when reality departs from the plan. How does the deviation become visible? Who can stop the process, what rolls back, how is the impact contained, where does the report go, and who tracks the fix until it's done? The higher the consequence, the less any one person's perfect attention should stand between normal work and disaster.

The honest version of the instruction is longer and much less quotable: show uncertainty early, stop on abnormality, protect the reporting path, preserve the evidence, and change whatever made the mistake easy to repeat. It's more to ask for, and it's the part that actually moves you toward zero.

Keep perfection as the ambition if you want. Then replace “make no mistakes” with a process that can notice a mistake and contain it, and that leaves the work a little safer than it found it.