“Make no mistakes” is not a method

“Make no mistakes” sounds exacting. Ask what anyone should do differently and the sentence goes quiet.

Make no mistakes.

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: 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. The response needs an owned path from the first abnormal signal to a changed system.

The higher the consequence, the less any one person's perfect attention should stand between normal work and disaster. Protecting the reporting path and assigning the repair are part of the mechanism too. Without them, the sequence ends with a well-documented recurrence.

The red emergency-stop button at the top of this page sits on a CNC control panel. Its designers gave an abnormal moment a dedicated action the operator can take, then built the machine to stop when they do.