“Be more careful” is the most useless instruction in management. It feels like accountability. It sounds like a standard. It does nothing. The person you said it to was already trying to be careful when they made the mistake, and asking for more of the thing that already failed is not a plan. It is a wish.
The managers who actually stop repeat errors do something that feels counterintuitive at first: they stop relying on people paying attention, and they start redesigning the work so the attention isn’t required. The mistake gets engineered out. Once you see management through that lens, a whole category of recurring problems becomes solvable instead of chronic.
That lens has a name, borrowed from manufacturing, and it is worth stealing.
The instruction that never works
Every team has a mistake it keeps making. The report goes out with last quarter’s numbers. The client gets CC’d on the wrong thread. The deploy skips a step. The invoice ships without the PO number. You address it the obvious way: you flag it, you remind everyone, maybe you add a line to a document nobody reads. For a few weeks it holds. Then it comes back, because the underlying conditions never changed. You just spent some of your team’s goodwill on vigilance, and vigilance has a short shelf life.
The reason “be careful” fails is that it treats human attention as a renewable, reliable resource. It is neither. Attention fades across a shift, drops under load, and collapses when someone is interrupted mid-task. Inspection-based quality has the same flaw baked in: a tired reviewer at the end of the day misses the defect a fresh one would catch, which is exactly why prevention beats after-the-fact checking (a point human-factors engineers have made for decades, as summarized in this review of error prevention in complex systems). If your quality plan depends on everyone being sharp all the time, you do not have a quality plan. You have a streak, and streaks end.
The insight that changed how Toyota built cars
In the 1960s, an industrial engineer named Shigeo Shingo was watching an assembly process where workers kept forgetting to install a small part. The conventional response would have been training, warnings, and discipline. Shingo did something different. He redesigned the step so the part could not be omitted without the error being caught immediately. He called the approach poka-yoke, Japanese for mistake-proofing, and he built it into what became the Toyota Production System. You can read the full origin in the standard reference on poka-yoke.
The name itself carries the whole management lesson. Shingo originally called it baka-yoke, which translates closer to “idiot-proofing” or “fool-proofing.” The term got softened after an incident at a parts supplier in 1963, when an employee reportedly broke down in tears on being told her station now had a “fool-proofing” device, as lean practitioners tell the story. The rename was not just politeness. It marked the real shift: the error is not evidence that the worker is a fool. The error is evidence that the system permitted it. Blame the design, fix the design.
You already live inside hundreds of these designs and never notice them, which is the point. Your car will not start in gear. The microwave will not run with the door open. HDMI and USB-C plugs are shaped so they cannot go in wrong. None of those rely on you being attentive. They make the wrong action physically unavailable, so the “mistake” simply cannot happen. That is the bar. Not a reminder to be careful. An arrangement in which carelessness has no opening.
Three ways to make a mistake impossible
Shingo described three mechanisms, and every one of them translates directly out of the factory and into knowledge work.
The contact or design method catches an error by physical fit. The part only goes in one way. In an office, the equivalent is a form field that only accepts a valid value: a dropdown instead of free text, a date picker instead of a typed date, a required field the form will not submit without. If someone cannot enter the wrong thing, they will not enter the wrong thing.
The fixed-value method confirms that the right number of somethings happened. On the line, it alerts when a set count of movements is missed. On your team, it is the expense report that will not route until all three receipts are attached, or the change request that cannot close until the required approvals are logged. You are not asking anyone to remember the count. The process counts.
The motion-step or sequence method confirms that steps happened in the right order. It is the deployment pipeline that refuses to advance to production until the test stage passes, or the checklist gate that blocks the next action until the prior one is confirmed done. The sequence enforces itself, so “I forgot to run the check first” stops being a possible sentence.
Notice what all three share. None of them ask a human to try harder. Each one moves the burden off memory and attention and onto the structure of the work. That is the entire move.
Where I learned to stop trusting “careful”
I spent 20+ years in IT operations at a large enterprise telecom, and the most expensive lessons I ever absorbed were about maintenance windows. Early on, our change process leaned heavily on competent people remembering to do the right things in the right order. Verify the backup. Confirm the rollback path. Check that the standby was actually healthy before you touched the primary. Everyone knew the steps. Everyone was skilled. And every so often, at two in the morning near the end of a long window, a skilled person under pressure would skip the verification because they were sure it was fine, and it was not fine, and we would spend the rest of the night proving it.
The fix that finally worked was not another reminder or a sterner post-incident meeting. It was making the skip impossible. The change tooling would not let you proceed to the risky step until the backup verification returned a green result the system itself confirmed. The step stopped depending on a tired engineer’s judgment about whether it mattered tonight. It became a gate. Incidents from that specific class of error effectively went to zero, not because the engineers got more careful, but because we stopped requiring them to be.
The broader industry has put numbers on why this matters. Software delivery research from DORA tracks change failure rate as a core signal of team health: the share of changes that end in a rollback, a hotfix, or degraded service. Every one of those failures is rework, capacity your team already spent that now has to be spent again. Mistake-proofing is one of the most direct ways to move that number, because you are attacking the errors at the point where they enter, not cleaning them up downstream. If you have watched errors quietly generate a second wave of unplanned work that eats your team’s week, this is where a lot of that volume actually starts.
A hierarchy to run your own processes through
When you find a recurring error, resist the reflex to jump straight to “add a check.” Checks are the weakest tool, and most teams reach for them first. Work down this order instead.
Eliminate. Can the step that produces the error just not exist? The mistake you cannot make is the one where the opportunity was removed. If people keep pulling the wrong version of a file, the fix might be deleting the old versions, not labeling them more clearly. Fewer steps, fewer openings.
Prevent at the source. If the step has to exist, can you make the wrong version of it impossible? This is Shingo’s design method: constrain the input so only the correct action fits. A template that pre-fills the required structure. A permission that stops the wrong person from touching the wrong system. The error is not caught here, it is precluded.
Force the correct sequence. If the work has an order that matters, make each step gate the next. The process will not advance until the prior condition is genuinely met, so “out of order” and “skipped” both become unavailable.
Detect immediately. Only when you cannot eliminate, prevent, or gate should you fall back to catching the error fast, at the moment it happens, while it is cheap to fix and obvious who and what caused it. A well-built checklist lives at this layer, which is why checklists earn their keep on exactly the work your team knows too well to think about.
Notice that “remind people to be careful” does not appear anywhere on this list. It is not a control. It is the absence of one.
Start with the mistake you have already made twice
You do not need a Lean certification or a factory to use any of this. You need to pick one error your team has made more than once, the one you have already reminded people about and watched recur, and ask a single question about it: what would make this mistake impossible to make, rather than merely discouraged?
Sometimes the answer is a five-minute change to a form. Sometimes it is deleting an option that should never have existed. Sometimes it is a gate in a workflow that costs a day to build and pays for itself the first time it stops a bad release. What matters is the shift in where you are looking. You stop auditing your people’s attention and start auditing your process’s design, because the recurring error was never really theirs. It was yours, sitting in a system that left the door open. Close the door, and you will not have to keep asking anyone to remember not to walk through it.