Quality
Translation: When the Distance Between What the Customer Said and What
the Factory Built Is Measured in Misunderstandings — and Your Quality
System Discovers That the Most Dangerous Defects Are Born in the Space
Between Words
The Conversation That
Costs Millions
Picture this scene. It plays out in manufacturing companies every
single day, across every industry, on every continent.
A customer tells your sales team what they need. The sales team tells
your engineering department. Engineering writes a specification. The
specification goes to purchasing, who interprets it for a supplier. The
supplier builds a component. The component arrives at your factory,
where a process engineer designs the production line. An operator runs
the line. A quality inspector checks the part. The part ships to the
customer.
And the customer rejects it.
Not because anyone was incompetent. Not because anyone cut corners.
Not because your quality system failed in any measurable way. The
rejection happens because somewhere in that chain — between the
customer’s mouth and your factory floor — the meaning got lost. The
requirement was translated six times, and each translation introduced a
small, invisible drift. By the time it reached the operator’s hands, the
original intent was unrecognizable.
This is Quality Translation, and it is the single most underestimated
source of defects in modern manufacturing. Not machine capability. Not
operator error. Not supplier quality. The simple, devastating fact that
organizations are terrible at moving meaning from one person to the next
without corrupting it.
The Telephone Game You
Never Outgrew
Remember the childhood game of telephone? One person whispers a
message to the next, and by the time it reaches the end of the line,
“The cat is on the mat” has become “The bat ate a hat.” Everyone laughs.
It’s harmless.
In manufacturing, that same game plays out with product requirements,
and nobody is laughing. A customer says they need the surface finish to
feel smooth to the touch. The sales engineer writes “smooth surface.”
The design engineer interprets that as Ra 1.6 μm. The manufacturing
engineer targets Ra 1.2 μm for safety margin. The CNC programmer sets
the tool path for Ra 0.8 μm because that’s what the machine naturally
produces with that material. The quality inspector measures Ra 0.8 μm
and approves. The customer receives the part and says it doesn’t feel
right.
Everyone did their job. Everyone was rigorous. And the result is
wrong.
The problem isn’t incompetence. It’s translation loss — the
inevitable degradation of meaning that occurs every time information
passes from one person, one function, or one discipline to another. In
linguistics, this is well understood. In manufacturing, it’s barely
acknowledged.
The Seven Translation Zones
In my twenty-five years of quality management across automotive,
industrial, and electronics manufacturing, I’ve identified seven
critical translation zones where meaning gets corrupted. Each one is a
potential defect generator, and most quality systems don’t even know
they exist.
Zone 1: Customer Voice to Sales Interpretation
The customer describes a need in their language, using their frame of
reference, their priorities, and their assumptions. Your sales team
hears it through their own filter — commercial priorities, technical
background, relationship dynamics. What gets captured in the CRM is
already a translation, not a recording.
A customer in the heavy equipment industry once told us they needed a
bracket that could “take a beating.” Our sales team wrote “high
durability requirement.” Engineering designed for fatigue life. What the
customer actually meant was impact resistance — the bracket needed to
survive being hit by a wrench in a maintenance scenario. Two completely
different engineering solutions. The fatigue-optimized bracket cracked
on the first day of field use.
Zone 2: Sales Interpretation to Engineering
Specification
This is where customer language gets converted into engineering
language. The informal, contextual, experience-based description from
the customer must become a formal, decontextualized, universal
specification. This translation is inherently lossy.
Engineering specifications are precise but narrow. They capture what
can be measured, not what was meant. A customer says the part needs to
“slide easily into the assembly.” Engineering writes a dimensional
tolerance on the mating surface. But the customer’s real concern was the
assembly ergonomics — the operator on their line needs to be able to
insert the part without excessive force. The tolerance is correct, but
the surface treatment that affects friction coefficient was never
specified because nobody translated “easily” into “low coefficient of
friction with the mating material in the assembled state.”
Zone 3: Engineering Specification to Manufacturing
Process
Now the specification must become a process. Every parameter, every
machine setting, every material choice is a translation of the
engineering intent into manufacturing reality. And manufacturing reality
has its own language, constraints, and priorities.
The engineer specifies a heat treatment that achieves a specific
hardness range. The manufacturing engineer selects a furnace cycle that,
based on historical data, produces that hardness range. But the
engineer’s intent was also about the microstructure — a specific grain
size that ensures fatigue performance. The hardness is a proxy for the
microstructure, not a direct measure of it. The furnace cycle that
produces the right hardness doesn’t always produce the right
microstructure. Nobody knew the translation was incomplete until parts
started failing in the field six months later.
Zone 4: Manufacturing Process to Operator
Instructions
The process engineer designs a beautiful, capable process. Then it
must be translated into instructions that a human being can follow. This
is where the most dramatic translation failures occur, because you’re
converting engineering knowledge into human action.
Work instructions are the Rosetta Stone of manufacturing — they
attempt to bridge the gap between technical process knowledge and
practical human execution. And like all translations, they’re imperfect.
The process engineer writes “monitor temperature and adjust if trend
exceeds 2°C in 15 minutes.” The operator reads “keep temperature
steady.” Two different instructions. The first requires trend analysis
and proactive adjustment. The second requires maintaining an average
value. The operator follows their interpretation faithfully, and the
process drifts.
Zone 5: Operator Execution to Quality
Verification
The operator produces the part. The inspector checks it. This seems
straightforward — the specification is the specification, and the
measurement either passes or fails. But the translation here is between
what the operator actually did and what the inspector thinks happened,
mediated by the measurement system.
An inspector measures ten dimensions on a complex part. All ten pass.
The part ships. But the inspector measured the dimensions in isolation,
not understanding that the combination of where each dimension falls
within tolerance creates a functional issue. The individual translations
are correct, but the assembly — the holistic meaning — is lost.
Zone 6: Internal Results to Customer
Communication
Your quality team generates reports, certificates, and data. These
must be translated back into customer language — what the results mean
for their application, their risk, their decision-making. This reverse
translation is just as lossy as the forward one.
A PPAP package shows a Cpk of 1.67 on a critical dimension. Your team
submits it with confidence. The customer’s quality engineer reviews it
and approves. But neither side discussed the sampling strategy behind
that Cpk — it was calculated from a single production run on a Tuesday
morning with a fresh tool. The Cpk is real but unrepresentative. The
number translated correctly. The meaning did not.
Zone 7: Customer Feedback to Corrective Action
When a problem does surface — and it will — the customer describes
the issue in their terms. Your quality team must translate that
description into root cause language, then into corrective action
language, then into process change language. Each translation is an
opportunity to solve the wrong problem.
The customer says the paint is peeling. Your quality team
investigates the paint process. The real cause is a surface
contamination issue in the stamping department that affects paint
adhesion — two departments away from where the investigation started.
The customer’s word “peeling” translated to “paint problem” when it was
actually a “surface preparation problem.” The translation error added
three weeks to the investigation.
Why This Keeps Happening
You might think that with all our quality tools — FMEA, control
plans, PPAP, statistical process control — these translation losses
would be caught and prevented. They should be. But they aren’t, for
three structural reasons.
First, each function speaks a different language.
Sales speaks in customer value and competitive differentiation.
Engineering speaks in specifications and tolerances. Manufacturing
speaks in cycle times and process parameters. Quality speaks in defects
and variation. These languages overlap, but they are not the same. When
an engineer says “robust,” they mean capable across input variation.
When a salesperson says “robust,” they mean durable in the field. When
the customer says “robust,” they might mean “I’ve never had a problem
with it.” Same word, three different translations.
Second, organizational silos create translation
gaps. Information doesn’t flow continuously through
organizations — it jumps across boundaries. Every handoff between
departments is a translation event. And handoffs are where meaning goes
to die. The engineer who wrote the specification is not the same person
who writes the work instruction. The salesperson who heard the
customer’s voice is not the same person who designs the inspection plan.
Each boundary is a filter that strips context and adds
interpretation.
Third, we mistake documentation for understanding.
Organizations are excellent at documenting requirements. We have
specification sheets, drawing callouts, control plans, and quality
agreements. We are terrible at verifying that the person reading the
document understands the same thing the person writing it intended. A
specification that says “surface finish Ra 1.6 μm max” is clear and
measurable. But if the person reading it doesn’t understand why that
surface finish matters — what function it serves, what failure mode it
prevents, what the customer will experience if it’s wrong — then the
specification is just numbers on paper. The translation failed, and the
document gives everyone false confidence that it didn’t.
The Quality Translation
Framework
After years of watching defects born from translation failures, I
developed a practical framework to address them. It’s not complex. It
doesn’t require new software or certification. It requires discipline
and a willingness to do something most organizations find uncomfortable:
slow down at the handoff points.
Step 1: Make Translation Visible
The first step is acknowledging that translation loss exists and
mapping where it occurs in your organization. Walk through your entire
value stream — from customer inquiry to delivered product — and identify
every point where information passes from one person, team, or function
to another. Each of those points is a translation zone.
For each zone, ask: Who is the sender? Who is the receiver? What is
the medium (document, verbal, system entry)? What context is lost in the
transfer? What assumptions does the receiver make that the sender didn’t
intend?
This exercise alone will reveal vulnerabilities you never knew
existed. Most organizations discover they have far more translation
zones than they realized — I’ve seen companies identify thirty or more
in a complex product realization process.
Step 2: Assign Translation Owners
Every critical translation zone needs an owner — someone whose
explicit responsibility is to ensure that meaning is preserved across
the boundary. This is not the same as a project manager who tracks
timelines, or a quality engineer who checks specifications. A
translation owner is responsible for meaning.
In practice, this means the translation owner sits at the
intersection of two functions and speaks both languages. They can
understand what engineering meant and explain it to manufacturing in
terms that preserve the intent. They can hear what the customer is
really saying and articulate it to design in a way that captures the
need, not just the words.
In automotive companies, this role sometimes exists as the customer
quality engineer or the program quality manager. But it’s rarely
formalized as a translation function. It should be.
Step 3: Implement Reverse Translation Checks
The most powerful technique I’ve encountered for preventing
translation loss is the reverse translation check. It works like this:
after a requirement passes through a translation zone, the receiver
explains it back to the sender in their own words. Not by reading the
document back — by describing what they understood.
If the engineer specifies a heat treatment for microstructure
control, the manufacturing engineer should be able to explain: “You need
this specific grain structure because it affects fatigue life in the
field, and the hardness specification is a proxy for that, so I need to
select a furnace cycle that controls both hardness and grain size, not
just hardness alone.”
If the manufacturing engineer can’t say that, the translation failed.
And it’s better to discover the failure before production starts than
after parts are in the field.
This feels slow. It feels like overhead. It is neither. A ten-minute
reverse translation check can prevent a ten-week corrective action loop.
I’ve seen this single practice reduce customer complaints by thirty
percent in organizations that implemented it consistently.
Step 4: Enrich Specifications with Context
Every critical specification should carry its context. Not just what
the requirement is, but why it exists. What function does it serve? What
failure mode does it prevent? What does the customer experience if it’s
wrong?
This context is the translation safeguard. When an operator
understands that the torque specification on a bolt exists because
undertightening causes oil leaks that destroy engines — not just because
the drawing says 47 Nm — they translate that requirement differently
into their daily work. They don’t just hit the number. They understand
what the number means.
Many organizations resist this. They argue that specifications should
be self-contained and objective. That’s engineering thinking, not
quality thinking. Quality is about ensuring the right outcome, and the
right outcome requires understanding intent, not just numbers.
Step 5: Close the Loop with the Customer
The final step is the most neglected: actively closing the loop with
the customer to verify that what you built matches what they meant. Not
what they specified — what they meant.
This goes beyond the standard customer satisfaction survey or quality
review meeting. It means sitting with the customer’s engineering team
and walking through your interpretation of their requirements. It means
asking the uncomfortable question: “Here’s what we understood. Is this
what you intended?”
I facilitated one of these sessions with a major automotive OEM and
their tier-one supplier. In four hours, the group identified eleven
requirements where the supplier’s interpretation diverged from the OEM’s
intent. Eleven. On a program that had been in production for two years.
The supplier had been shipping compliant parts that didn’t fully satisfy
the customer’s needs, and the customer had been living with it because
the formal requirements were technically met. Both sides were
frustrated, and neither understood why until they sat in the same room
and compared meaning.
The Cost of Ignoring
Translation
The costs of translation failure are enormous, but they’re almost
never attributed to their true cause. They show up as:
- Warranty claims for failures that occurred because
the specification captured the measurement but not the meaning. - Customer complaints about parts that pass every
inspection but don’t work in the assembly. - Engineering changes that are really just
corrections of translation errors, disguised as design
improvements. - Supplier disputes where both sides are technically
correct and functionally wrong. - Audit findings that identify nonconformances born
not from negligence but from misunderstanding.
I estimate that in a typical manufacturing organization, fifteen to
twenty-five percent of all quality costs are attributable to translation
failures. Not material defects, not process failures, not operator
errors — pure, preventable losses from the gap between what was meant
and what was understood.
A Personal Lesson
Early in my career, I was responsible for the quality of a
safety-critical component supplied to a major automotive manufacturer.
The component passed every test in our control plan. The Cpk values were
stellar. The PPAP was approved without a single question. We were proud
of our quality system.
Three months into production, the customer reported a field failure.
Investigation revealed that our component’s coating thickness was at the
low end of the specification range. It was compliant — just barely — but
the customer’s assembly process involved a secondary forming operation
that we didn’t know about. That forming operation stretched the coating,
and at our minimum thickness, it cracked.
Our specification was correct. Our process was capable. Our
inspection was thorough. But we had never understood why the coating
existed in the first place. We translated the thickness requirement
perfectly and missed the functional intent entirely.
That lesson cost us a lot of money. It cost me something more
valuable: the assumption that being right on paper is the same as being
right in reality.
I now approach every requirement as a translation challenge. Not
“what does the specification say?” but “what does the customer need this
to do, and does our interpretation of the requirement actually achieve
that?”
The Imperative
In an era of global supply chains, cross-functional teams, and
increasingly complex products, the translation challenge is only
growing. Your customer in Germany describes a requirement in German
engineering terms. Your design team in the United States interprets it
in ASME standards. Your manufacturing site in Mexico executes it in
their local process language. Your inspection team in Slovakia verifies
it against ISO standards.
The number of translation zones multiplies. The opportunities for
meaning loss multiply with them. And your traditional quality tools —
designed to verify that specifications are met, not that specifications
are understood — are insufficient.
Quality Translation is not a nice-to-have. It is a critical quality
discipline that sits alongside FMEA, SPC, and audit management. It
requires its own tools, its own training, and its own metrics. It
requires organizations to value understanding as much as compliance.
Because in the end, the most dangerous defect is not the one that
escapes your inspection. It’s the one that was built into the product
before production even started — born in the silent space between what
someone said and what someone else heard.
Peter Stasko is a Quality Architect with 25+ years
of experience in automotive and manufacturing quality management. He has
led quality transformations across multi-site organizations, implemented
QMS frameworks from scratch, and navigated the complex landscape of
customer-specific requirements across global supply chains. His approach
combines deep technical expertise with practical, human-centered quality
leadership.
