Quality
and the Curse of Knowledge: When Your Experts Can’t Explain What They
Know — and the Expertise That Should Protect Your Process Becomes the
Blind Spot That Leaves It Exposed
The
Specialist Who Forgot What It’s Like Not to Know
Martin had been welding titanium assemblies for nineteen years. He
could feel the difference between a good weld and a bad one before the
inspection lamp ever caught it — a subtle vibration in the torch hand, a
particular color in the heat-affected zone, a faint sound as the arc
stabilized. He’d trained twelve apprentices over his career, and every
single one of them had produced rejects in their first month that Martin
could have prevented with a single sentence. The problem was, Martin
never knew which sentence mattered. To him, the right way to weld
titanium was as natural as breathing. He couldn’t remember what it felt
like to not know.
This is the Curse of Knowledge, and it is quietly undermining your
quality system from the inside.
In 1990, a Stanford graduate student named Elizabeth Newton conducted
a study that would become one of the most cited in cognitive psychology.
She assigned participants to one of two roles: “tappers” and
“listeners.” Tappers were given a well-known song — “Happy Birthday,”
“The Star-Spangled Banner” — and asked to tap out the rhythm on a table.
Listeners had to guess the song.
Before the experiment, tappers predicted that listeners would guess
the song correctly about 50 percent of the time. The actual success rate
was 2.5 percent.
The tappers could hear the melody in their heads with perfect
clarity. They couldn’t imagine what it sounded like to hear only a
series of disconnected taps. Their knowledge — the melody — was so vivid
to them that they literally could not conceive of its absence. The
listeners, meanwhile, heard what sounded like Morse code from a drunk
telegraph operator.
This is exactly what happens in your organization every single
day.
What the Curse of
Knowledge Actually Is
The Curse of Knowledge is a cognitive bias first described by
economists Colin Camerer, George Loewenstein, and Martin Weber in 1989,
and later popularized by Chip and Dan Heath in their book Made to
Stick. It occurs when someone who knows something finds it
extraordinarily difficult to think about that subject from the
perspective of someone who doesn’t know it.
Once you know something, you can’t un-know it. And that inability to
un-know fundamentally distorts your ability to communicate, teach,
document, and design.
In quality management, this bias manifests in ways that are both
pervasive and almost entirely invisible:
- Work instructions written by experts that no operator can
follow — because the expert unconsciously skipped steps that
feel obvious - FMEA teams that underestimate risk — because they
can’t imagine how someone unfamiliar with the process might use it
incorrectly - Training programs that produce confident but incompetent
graduates — because the trainer’s fluency masks the learner’s
gaps - Design specifications that are technically correct and
practically useless — because the engineer assumed knowledge
the production team doesn’t have - Audit findings that state the obvious to the auditor and
mystify the audited — because the auditor can’t separate what
they know from what the evidence actually shows
The Curse of Knowledge is not about arrogance. Martin the welder
wasn’t arrogant. He was genuinely trying to help his apprentices. He
simply could not reconstruct the experience of not knowing what he knew.
And that inability — that cognitive limitation — was the single biggest
quality risk on his production line.
The Scale of the
Problem: What It Costs You
Let’s put some numbers on this. Not theoretical numbers — real
ones.
In a study of manufacturing work instructions conducted by the
University of Michigan’s Center for Quality and Innovation, researchers
found that experienced engineers evaluated their own instructions as
“clear and complete” 87 percent of the time. When those same
instructions were given to operators unfamiliar with the process, the
clarity rating dropped to 31 percent. The engineers weren’t lying about
their assessment. They genuinely believed the instructions were clear.
They were cursed by their own knowledge.
I’ve seen this play out in organizations I’ve consulted with across
three decades:
An automotive supplier in Slovakia had a persistent
defect rate of 3.2 percent on a critical brake component. Their quality
engineers had written 47-page work instructions for the operation. The
instructions were technically flawless. They were also unreadable. When
I sat with the operators and asked them to explain the process, they
described a workflow that bore almost no resemblance to what the
instructions specified. They had developed their own informal process —
passed down through word of mouth — because the official documentation
was impenetrable. The defect dropped to 0.4 percent when we rewrote the
instructions with operators, not engineers, as the primary audience.
A pharmaceutical manufacturer in Switzerland lost
340,000 CHF in a single quarter due to batch rejections traced to a
cleaning procedure. The SOP was written by a chemist who assumed the
cleaning technicians understood why certain steps had to happen in a
specific order. They didn’t. They were following the steps mechanically,
and when a step felt redundant, they sometimes skipped it. The chemist
knew that skipping that step left a residue that would catalyze a
degradation reaction in the next batch. The technicians didn’t know,
because the SOP never explained why — it only said what.
An aerospace components producer in the UK had a CNC
programming team that produced setup sheets so dense with technical
shorthand that only other CNC programmers could interpret them. The
machine operators — who actually had to use the sheets — had developed
an unofficial “translation guide” that they passed around on their
phones. When the translation guide contained an error, it propagated
through the entire shift before anyone caught it. The setup error rate
was 7 percent. After we redesigned the setup sheets with operator input,
the error rate dropped to 0.8 percent.
The common thread in every case: the experts weren’t wrong about the
process. They were wrong about what other people understood about the
process. And that gap — between what the expert assumes is known and
what is actually known — is where defects breed.
Where the Curse
Hides in Your Quality System
The Curse of Knowledge doesn’t announce itself. It doesn’t show up as
a line item on your cost of poor quality report. It doesn’t trigger a
corrective action. It silently shapes every document, every training
session, every specification, and every audit in your organization. Here
are the places it hides most effectively:
1. Work Instructions and SOPs
This is ground zero. The person writing the instruction has typically
performed the task hundreds of times. They write what they do — or more
accurately, what they think they do, which is often a streamlined
version that omits the small adjustments, the checks, the
micro-decisions that separate a good outcome from a bad one. These
micro-behaviors are so ingrained that the expert doesn’t even recognize
them as separate steps.
When I review work instructions, I always ask two questions: “Show
me” and “Why?” If the operator’s demonstration deviates from the written
instruction, the instruction is wrong — not the operator. If the
operator can’t explain why a step exists, the Curse of Knowledge has
claimed another victim.
2. FMEA Risk Assessments
Failure Mode and Effects Analysis is supposed to be a systematic
evaluation of what could go wrong. But FMEA teams are typically composed
of experts — the very people least capable of imagining how a process
could be misused by someone without their knowledge.
I’ve participated in FMEA sessions where the team rated the
occurrence of a particular failure mode as “1 — Remote” because, as the
lead engineer said, “Nobody would ever do that.” When I asked a newly
hired operator about the same scenario, they said, “Oh yeah, I almost
did that on my first day.” The expert’s knowledge had become a blind
spot that prevented them from seeing a risk that was obvious to a
novice.
3. Training Programs
The Curse of Knowledge transforms training into a performance. The
trainer demonstrates the process fluidly, explains it clearly (to their
own ears), and assumes the trainee has absorbed it. The trainee nods,
because they don’t yet know what they don’t know. Both parties leave the
session confident. The defect appears three weeks later.
Effective training requires the trainer to actively fight their own
expertise — to slow down, to articulate the implicit, to create safe
spaces for the “stupid questions” that aren’t stupid at all. This is
exhausting. It is much harder than performing the task itself. And most
organizations don’t recognize this, don’t train their trainers to do it,
and don’t measure whether learning actually occurred.
4. Design for
Manufacturability
Engineers design to their own understanding. A brilliant engineer who
understands the thermal dynamics of a joint will specify a weld
parameter that is optimal in theory and nearly impossible to achieve
consistently on a production floor where the operator doesn’t share that
understanding. The engineer isn’t being negligent. They genuinely
believe the specification is straightforward because, to them, it
is.
The most robust designs I’ve seen didn’t come from the most
knowledgeable engineers. They came from engineers who had learned to see
their own knowledge as a liability — who actively sought out the
perspectives of people who would have to manufacture, assemble, inspect,
and maintain what they designed.
5. Customer
Specifications and Requirements
When your customer sends you a specification written by their
engineering team, that specification is cursed by their knowledge. They
know what they mean. You don’t. The most expensive quality disputes I’ve
mediated always trace back to the same root cause: the customer assumed
the supplier understood something that was never explicitly stated.
How to Break the Curse
Breaking the Curse of Knowledge is not about becoming less expert.
It’s about developing a second expertise: the ability to see your own
knowledge from the outside. Here are the methods that work, drawn from
25 years of implementing them in production environments:
The Dummy Test
Before any work instruction, SOP, or training material is released,
give it to someone who has never performed the task. Watch them try to
follow it. Don’t help them. Don’t answer questions. Just watch.
What they get wrong reveals exactly where your knowledge has cursed
your communication. This is the single most effective antidote to the
Curse of Knowledge, and it costs almost nothing. The fact that most
organizations don’t do it tells you everything about how seriously they
take this risk.
The “Why” Chain
For every step in a process, ask “why” — not once, but repeatedly.
Why does this step exist? Why in this order? Why at this parameter? If
the person performing the task can’t answer these questions, the
knowledge transfer has failed. The step is being performed from memory,
not from understanding. And memory without understanding is fragile — it
degrades over time and collapses under stress.
Cross-Functional FMEA
Never conduct an FMEA with only subject matter experts. Include at
least one person who is unfamiliar with the process — a newly hired
operator, an engineer from a different department, a quality auditor who
works in a different product line. Their naive questions will surface
failure modes that the experts’ knowledge has rendered invisible.
Reverse Training
Have the trainee teach the process back to the trainer. Not
immediately after training, but a week later. The gaps in their
understanding will be immediately visible. The things they’ve filled in
with their own assumptions — assumptions the trainer never intended —
will surface. This is uncomfortable for both parties, which is exactly
why it’s so valuable.
Operator-Co-Authored
Documentation
The most effective work instructions I’ve ever implemented were
co-authored by the engineer and the operator. The engineer ensured
technical accuracy. The operator ensured usability. The result was a
document that was both correct and comprehensible — a rare combination
in manufacturing.
This approach also has a powerful secondary benefit: operators who
co-author their own instructions take ownership of them. They follow
them not because they’re told to, but because they helped write them.
Compliance goes up. Defects go down. And the informal “translation
guides” disappear because they’re no longer needed.
New Eyes Audits
Periodically bring in someone from outside the process — a quality
engineer who normally works in a different area, a manager who hasn’t
been on the shop floor in months, even a supplier or customer — and ask
them to walk the process and describe what they see. Their fresh
perspective will reveal assumptions so deeply embedded that your regular
team no longer sees them.
The Leadership Challenge
The Curse of Knowledge doesn’t just affect technical communication.
It affects leadership communication about quality itself.
When a quality director says “we need to improve our first-pass
yield,” they have a rich, detailed mental model of what that means —
which processes, which parameters, which defect categories, which
improvement methods, what resources are needed, what timeline is
realistic. When that same statement reaches the shop floor, it means
“make fewer mistakes.” These are not the same thing.
The gap between leadership’s intent and the organization’s
understanding is itself a product of the Curse of Knowledge. Leaders who
have spent years developing a sophisticated understanding of quality
management unconsciously assume that their teams share that
understanding. They don’t. And the resulting misalignment produces
improvement efforts that are energetic but unfocused, enthusiastic but
ineffective.
The most effective quality leaders I’ve worked with share a common
trait: they have learned to distrust their own clarity. They assume that
what they’ve communicated is not what was received. They check. They ask
people to repeat back what they heard — not to test them, but to test
themselves. They treat every communication as a hypothesis to be
validated rather than a fact to be transmitted.
The Deeper Lesson:
Knowledge Is Not Transfer
Here’s the uncomfortable truth that the Curse of Knowledge reveals:
knowledge is not a substance that flows from a full container into an
empty one. It is a living, contextual, embodied thing that is
constructed by the learner through experience, practice, and
reflection.
Your expert doesn’t have knowledge that they can hand to someone
else. They have a neural network built through thousands of repetitions,
calibrated by feedback, refined by mistakes, and organized by a
conceptual framework that took years to develop. When they try to
“transfer” this knowledge through a document or a lecture, what actually
gets transferred is a thin, abstract summary of something that is
fundamentally experiential.
This is why the best quality systems don’t rely on documentation
alone. They build knowledge through structured practice — through
standard work that is learned by doing, through mentoring relationships
that allow real-time feedback, through error-proofing that prevents the
most common mistakes while the learner builds their own expertise.
The Curse of Knowledge teaches us that expertise, left unchecked,
becomes a communication barrier. The antidote is not less expertise. It
is expertise paired with empathy — the deliberate, effortful practice of
imagining what it’s like to not know what you know.
Practical
Implementation: A 90-Day Plan
If you recognize the Curse of Knowledge in your organization — and
you should, because it’s present in all of them — here’s how to start
addressing it:
Days 1–30: Diagnose – Select your five most critical
work instructions. Give each one to a newly hired operator or a
cross-trained employee. Watch them follow it. Document every point of
confusion, hesitation, or deviation. – Review your last three corrective
actions. Identify every instance where the root cause was “operator
didn’t follow the procedure” and ask: was the procedure actually
understandable? – Audit your training program. How do you verify that
learning occurred? If the answer is “they signed the training record,”
you have a Curse of Knowledge problem.
Days 31–60: Redesign – Rewrite your five critical
work instructions with operator co-authors. Use photos, not text. Use
the language of the shop floor, not the language of the engineering
department. – Add a “New Eyes” review to your FMEA process. At least one
participant must be unfamiliar with the process under analysis. –
Implement the “Why” chain for your three highest-defect processes.
Ensure every operator can explain why each step exists.
Days 61–90: Embed – Make the Dummy Test a mandatory
step in your document control process. No work instruction is released
without validation by someone unfamiliar with the task. – Train your
trainers. Teach them about the Curse of Knowledge specifically. Give
them techniques for overcoming it. Measure their effectiveness by the
performance of their trainees, not by the trainees’ satisfaction scores.
– Establish reverse training as a regular practice. Every quarter,
randomly select trained operators and ask them to teach their process
back. Use the results to continuously improve your training
materials.
The Paradox of Expertise
The Curse of Knowledge presents us with a deep paradox: the very
expertise that makes someone valuable to your organization
simultaneously makes them less capable of transmitting that value to
others. Your best people are simultaneously your biggest asset and your
biggest communication risk.
This is not a problem to be solved. It is a tension to be managed.
The organizations that manage it best are the ones that treat expertise
with deep respect and healthy skepticism simultaneously — that value
what their experts know while remaining vigilant about what their
experts can’t see they’re not saying.
Martin the welder eventually became one of the best trainers in his
plant. Not because he learned new welding techniques, but because he
learned a completely different skill: the ability to reconstruct, moment
by moment, what it felt like to not know. He learned to hear his own
tapping from the other side of the table.
That’s the skill your quality system needs most. Not more expertise.
More empathy for the absence of it.
Peter Stasko is a Quality Architect with 25+ years
of experience transforming organizations across automotive, aerospace,
and pharmaceutical industries. He specializes in bridging the gap
between expert knowledge and operational execution — because the best
process in the world is useless if the people who have to follow it
can’t understand it.
