Hey Reader
“I don’t know what answer to give you, Mike. It was human error. He just didn’t do his job, and that’s why the part’s not good.”
This was an argument I recently encountered at a heavy manufacturing facility with hard-working individuals. They had shipped a bad part, missed one step, and the customer required a corrective action.
So what do you do? It’s one part from a manual process where somebody forgot to attach one component. 14 of the 15 were good, but one was missing the component, making the part unusable.
The floor supervisor’s argument was straightforward: “It’s annoying to do this corrective action thing for one part.”
My response: “We owe our customers good parts. We need to fix our problems because this doesn’t apply to only this part.”
Here’s what I told him:
Yes, it’s annoying to do a corrective action for one bad part. Yes, it’s time-consuming to spend extra effort on this issue. But it’s also really frustrating for our customer to tear down their assembly because they received one bad part.
Our customers pay for good parts—not half-made parts, not broken parts. Good parts that meet specifications and arrive at their dock on time.
However, we aren’t doing a corrective action because the customer complained. We’re doing it because something went wrong in our process, and we care enough about our customers to not want to make the same mistake twice.
It’s worth fixing because this complaint is a symptom of a broken process.
Let me share a story:
How many of you watch Dr. Who?
In the Dr. Who episode “Kerblam!” an automated delivery service sends the Doctor a package with a message: “Help Me.”
Worried someone is in trouble, the Doctor immediately jumps to help. After twists, turns, excitement, daring adventure, and suspense (it's Dr. Who), we discover the automated delivery system itself sent the message—it was crying out for help (I'm not going to spoil the entire episode, you'll have to watch it for the ending).
A customer complaint is just a red flag. It’s your process raising its hand saying, “Hey, look at me—I’m broken. Please come and fix me.”
Don’t ignore symptoms. Don’t sweep them under the rug. Address your problems head-on in a risk-prioritized way.
Back to the 1-off problem:
After reviewing the process data, we identified that the operator was interrupted mid-cycle. This caused him to stop, get distracted, return to his workstation, and simply move the half-completed part into the finished pile.
The fix: We worked with our operators to first prevent breaks mid-cycle. When that’s not possible, we implemented a verification step when returning to a workstation with a partially completed part still loaded.
Let’s be honest—one-off problems are tough to solve. There’s little evidence to test theories against, and the trail often goes cold quickly.
But here’s the thing: even single incidents can reveal systematic weaknesses that, if left unaddressed, will surface again.
(Put a pin in this thought, as not all problems are worth solving. There will be a future newsletter on prioritization. In the meantime, check out 4 Types of Problems by Art Smalley.)
How can we address 1 off problems?
1. Focus on the Problem, Not the Person This is obvious but important. When investigating issues, resist the urge to assign blame to individuals. Ask “What in our system allowed this to happen?” instead of “Who made the mistake?”
2. Be Relentless in Your Pursuit of Root Cause Start with theories, but test them against evidence. Don’t stop at the first plausible explanation—dig deeper until you find the systemic issue. This looks like what I did at the beginning of this story. Don't accept excuses. Don't let them sweep problems under the rug. Stay focused on the problem (not the person). You'll be walking directly into conflict and staying there until you can identify the issue. It's going to be uncomfortable. Be ready.
3. Ask the Right Solution-Focused Questions Once you understand the problem, shift to solutions by asking: “What does the team need to prevent this in the future?” and “How can we set up the process to succeed next time?” I use this line of questions a lot, especially with teams that struggle to identify the root cause. Sometimes asking these questions leads the team to realize they don't know something.
4. Evaluate if the Problem is Worth Solving Every issue is a warning that there's a broken system. BUT not every issue requires a full-scale investigation. Sometimes customers demand corrective action for one-off problems. Sometimes these are small issues that aren't the top priority (issues are always worth solving, but our resources are finite). While this is not the "right" answer, we can consider addressing an already identified issue that you were already planning to fix. If it's an adjacent issue, where the solution will plausibly fix this, it's a possible shortcut. Just understand you aren't solving the real problem.
Remember: Quality isn’t about perfection—it’s about building systems robust enough to prevent problems. One bad part might seem insignificant, but it often reveals the exact weakness that could cause much bigger problems down the line.
Quality isn't for people who want an easy answer.
This is for people who want to take the extra step to make quality central to their organization.
Reply with "SIMPLIFY" if you're ready to build a quality system that actually works.
