Your most experienced engineer is quietly undermining your ISO 9001 or IATF 16949 quality system. Not through negligence, but through a cognitive bias that makes their expertise invisible to the people who must execute it. Experts cannot remember what it feels like to not know something, so they unconsciously skip critical context when writing documentation, assessing risk, or training operators. This phenomenon undermines compliance and drives scrap.

I have implemented and transitioned quality management systems at a major aerospace manufacturer, SNOP, and WITTE Automotive. Across every plant, the most persistent defect sources were never advanced technical failures. They were communication failures between experts and operators. The engineers designed technically flawless processes that production teams could not consistently execute, because the documentation omitted the micro-behaviours and tacit decisions that separate a compliant part from a reject.

This is the Curse of Knowledge. Once you understand a process intimately, you literally cannot conceive of its absence. You write standard operating procedures for yourself, not for the newly hired operator on the night shift. The result is a documented quality system that audits well but fails on the shop floor.

The True Cost of Tacit Knowledge in Manufacturing

The Curse of Knowledge does not appear as a line item on your cost of poor quality report. It hides inside scrap rates, 8D corrective actions, and customer complaints. When an operator misunderstands a specification because the engineer assumed prior knowledge, the resulting defect is categorized as operator error. The root cause is actually a documentation failure driven by expert bias.

I have audited plants where experienced engineers rated their own work instructions as highly clear, only to have operators unfamiliar with the specific process rate those exact same documents as practically unreadable. The engineers were not falsifying their assessments. They genuinely experienced the documents as clear because their brains automatically filled in the missing steps. The operators were left reading what amounted to disconnected Morse code.

This gap between perceived clarity and actual comprehension is where defects breed. An automotive supplier might publish a forty-page PFMEA and comprehensive control plan that auditors praise, yet still maintain a high reject rate on critical components. The system is technically correct but practically useless, because the knowledge never successfully transferred from the engineer's mind to the operator's hands.

Quality decisions are made at the process, not in the report that describes it afterwards. When documentation fails, the process drifts.
Quality decisions are made at the process, not in the report that describes it afterwards. When documentation fails, the process drifts.

Where the Curse of Knowledge Hides in Your QMS

Work instructions and SOPs are ground zero for this cognitive bias. The author has typically performed the task hundreds of times. They write a streamlined version of the process that omits the small adjustments, the visual checks, and the micro-decisions that ensure conformity. These tacit behaviours are so deeply ingrained that the expert does not even recognize them as separate steps requiring documentation.

When I audit work instructions against actual shop-floor practice, I ask operators two questions: show me, and why. If the physical demonstration deviates from the written standard, the standard is wrong. If the operator cannot explain why a specific parameter or sequence exists, the knowledge transfer has failed. The operator is executing from rote memory rather than understanding, and rote memory collapses under stress or personnel changes.

The same bias distorts your risk assessments. FMEA teams are typically composed of senior subject matter experts. These are the very people least capable of imagining how a process could be misused by a novice. I have sat in PFMEA reviews where the engineering team rated a failure mode's occurrence as remote, claiming nobody would ever make that mistake. When I later asked a newly hired operator, they casually mentioned they almost made that exact error on their first day. The expert's knowledge had become a dangerous blind spot.

The Practical Mechanisms of Expert Bias in Production

Consider a CNC machining cell producing aerospace components. The programming team generates setup sheets so dense with technical shorthand that only other programmers can interpret them. The machine operators, who actually need to execute the setup, are forced to rely on an unofficial translation guide passed around informally. When that unofficial guide contains an error, the defect propagates across the entire shift before anyone catches it.

The programmers were not acting maliciously. They used the shorthand because it was efficient for their own workflow. They genuinely believed the setup sheets were straightforward. The operators were afraid to ask for clarification because admitting ignorance challenges the perception of competence. The structural gap between the engineering office and the shop floor goes unaddressed, and the setup error rate stays artificially high.

This mechanism repeats across assembly lines, painting cells, and inspection stations. A chemist writes a cleaning SOP that dictates steps without explaining the chemical necessity behind the sequence. Technicians follow the steps mechanically until a step feels redundant, at which point they quietly skip it. The residue left behind catalyses a degradation reaction in the next batch. The chemist knew the risk was catastrophic; the technicians did not, because the SOP never bridged that knowledge gap.

Fixing the Documentation Transfer Gap

Breaking this bias requires developing a second expertise: the ability to see your own knowledge from the outside. You do not need less expertise from your engineering team. You need structural mechanisms that force them to translate their deep knowledge into explicit, verifiable language. The most effective systems treat every document as a hypothesis to be tested against operator comprehension, not a fact to be filed.

The Dummy Test Protocol

  1. 01Draft the documentEngineer writes the SOP or work instruction based on their technical knowledge of the process.
  2. 02Select a naive userChoose a cross-trained employee or new hire who has never performed this specific task.
  3. 03Observe execution silentlyHand them the document. Watch them attempt the task. Do not answer questions or offer help.
  4. 04Identify failure pointsDocument every instance of hesitation, confusion, or deviation from the intended method.
  5. 05Rewrite with the operatorCo-author the revision. The engineer ensures technical accuracy; the operator ensures usability.
A five-step validation loop for ensuring work instructions survive contact with the shop floor.

The Dummy Test is the single most effective antidote to expert blind spots, and it costs practically nothing to implement. Before any work instruction, SOP, or training material is released into your document control system, give it to someone who has never performed the task. Watch them try to follow it without interfering. What they get wrong reveals exactly where your expert's knowledge has cursed the communication.

This approach must be embedded in your document control procedure, not treated as an optional review. No work instruction should be approved without validated comprehension by an unfamiliar user. This immediately exposes the hidden assumptions your engineers have baked into the text. It forces them to articulate the micro-decisions they normally skip, and it dramatically reduces the translation lag between the engineering office and the production line.

The gap between what an expert assumes is known and what is actually known is where defects breed.

Strengthening FMEA and Training Programs

Your failure mode and effects analysis process is structurally vulnerable to the Curse of Knowledge. Never conduct an FMEA with only subject matter experts in the room. You must include at least one person who is entirely unfamiliar with the specific process. A newly hired operator, an engineer from a different product line, or a cross-departmental quality auditor will surface critical risks. Their naive questions expose failure modes that the expert panel's shared experience has rendered invisible.

The same principle applies to your training programs. The Curse of Knowledge transforms training into a performance rather than a knowledge transfer event. The trainer demonstrates the process fluidly, explains it clearly to their own ears, and assumes absorption. The trainee nods passively because they do not yet know what they do not know. The defect or nonconformance appears three weeks later, triggering a costly 8D investigation.

Implement reverse training to break this cycle. Have the trainee teach the process back to the trainer one week after the initial session. The gaps in their understanding will surface immediately. You will hear the assumptions the trainee has filled in themselves — assumptions the trainer never intended to communicate. This is an uncomfortable exercise for both parties, which is precisely why it is so valuable for long-term process stability.

Measuring and Embedding Comprehension

If your verification of training consists of checking a signature on a training record, you have a Curse of Knowledge problem. You are measuring attendance, not comprehension. To satisfy IATF 16949 and AS9100 requirements effectively, you must measure whether the operator actually understands the process parameters, the critical-to-quality features, and the specific reactions required when things go wrong.

Key Indicators of Knowledge Transfer

0Dummy test deviationsTarget zero unexplained hesitations from a naive user following the SOP.
1.33Process CpkCapability improves when operators understand the why, not just the what.
100%Why-chain comprehensionTarget full operator ability to explain why a step exists in the sequence.
<1%First-month defect rateTarget for new hires, proving the training and instructions are robust.
Metrics that reveal whether your documentation is understood or just filed away.

You must establish a 90-day implementation plan to embed these practices. Start by diagnosing your five most critical work instructions using the Dummy Test. Review your last three corrective actions where the stated root cause was operator error, and ask whether the procedure was actually comprehensible. Train your trainers specifically on the mechanics of the Curse of Knowledge, and measure their effectiveness by the first-pass yield of their trainees, not by satisfaction survey scores.

The ultimate goal is standard work that operators follow because they helped create it, and because they genuinely understand it. Operators who co-author their own instructions take ownership of the process. Compliance goes up, defects drop, and the unofficial translation guides disappear because they are no longer necessary. Expertise paired with empathy is the most robust foundation a quality system can have.