If you’ve had any exposure to automotive, you know the vibe: everything looks normal in the morning, and by the afternoon you get an email with a customer complaint—and on the shop floor the fast counting starts: how many went out, where they went, and whether you can still stop it. That’s when the quality engineer steps in.
Sometimes as the person who handles the situation “here and now,” sometimes as the one who has to set things up so the same story doesn’t come back two weeks later. And no—this isn’t a job about sitting in procedures and adding rows in Excel. Documents matter, but usually because they’re meant to protect the process: from the customer, from the audit, from chaos.
Who is an automotive quality engineer, and how is this different from “quality” in other industries?
In simple terms: an automotive quality engineer makes sure the product meets requirements—and that the company can prove it. Sounds obvious until you see what “prove it” looks like in real life.
In automotive, the sentence “we checked it” is rarely enough. The questions start coming:
What exactly did you check?
On what basis did you decide it was OK?
Where is the record?
Who made the decision to release it and move on?
And that’s the first big differentiator in this industry: facts, records, and the way you react to risk.
Customer requirements are not a slide in a PowerPoint
In automotive, requirements are alive. You’ve got IATF, specifications, drawings, CSRs, packaging requirements, traceability requirements, and requirements related to how you react to nonconformities (most often customer-specific or corporate). The quality engineer ties all of that together and makes sure the process is set up to:
reduce the risk of errors,
detect issues before they leave the plant,
have a clear reaction when something goes wrong.
This isn’t “for the sake of it.” These requirements usually come back during the first complaint—or during a customer audit.
“Conformance” = requirement + verification method + evidence
This is where the difference between a “by eye” approach and the automotive approach often shows up. A scenario I’ve seen in countless variations: an operator says the part looks good from an aesthetic point of view. Fair—operators often have strong experience. But in automotive, additional questions show up immediately:
Do we have a reference (boundary sample) and does everyone know how to use it?
Are we using master plates provided by the customer? (This applies to painted parts, injection-molded parts, and material/leather-covered surfaces.)
Does the characteristic have a defined acceptance criterion (a number, tolerance, limit)?
Does the measurement make sense (MSA, stability, repeatability), or are we just producing numbers for peace of mind? This is basically the dividing line between a “good enough” mindset and real quality.
Does the inspection have a defined frequency, sampling plan, and a reaction plan when the result is out of limit?
When these elements are in place, discussions are shorter. When they aren’t, the issue comes back like a boomerang.
A Quality Engineer is the “link” between production, the customer, and the system
In practice, this role sits right on the edge of everything. One day you’re with production, checking what changed in the process (tooling, settings, material, operator, measurement). The next day you’re on a customer call and you need to say clearly:
what you found,
what you contained,
what you corrected,
how you protected shipments.
And in the background there’s the system: procedures, records, audits, IATF requirements, sometimes VDA, sometimes CQI, sometimes the customer’s internal standards (like AQRs used when working with Stellantis). Documentation has to match what’s actually happening on the shop floor. If everything looks perfect on paper but people are “improvising” at the workstation, sooner or later you’ll become the headline of the month—and not in a good way.
That’s the point: in automotive, a quality engineer doesn’t “win” with a clever document. You win by getting to facts fast and setting up the reaction so the process doesn’t drift silently in production.
A Quality Engineer’s responsibilities — what you do day to day
If someone tells you the quality engineer job is mostly “paperwork,” they’ve seen only part of the picture. Documents are in the background, but your day is shaped by real-life situations: out-of-spec parts produced on the line, a supplier issue, a customer question, an audit, a sudden scrap spike. Below are typical scenarios—the kind that actually fill your calendar.
Morning: a customer email and the “action” starts
A complaint lands in your inbox. Photos, a batch number, sometimes a polite “please provide an urgent analysis.” Your first steps are fairly consistent:
you check whether the issue affects current shipments (do you need to stop anything),
you identify which lots were shipped to the customer and what’s still in transit,
you launch sorting / extra inspection (if needed),
you collect facts: when the issue could have started, where it could have been missed, what changed in the process.
At this point, a “nice-looking report” matters less than your ability to structure the situation quickly and not lose details. The customer expects a clear message: what you did, what you contained, and when they’ll get the analysis.
Production calls: “we’ve got a problem” or “something’s off”
Classic scenario: someone on the station notices measurement results drifting, there’s suspicion of the wrong resin, the injection process isn’t holding parameters, an operator flags concerns about appearance. The quality engineer usually does three things—no slogans, just practical work:
stops the problem from spreading further through the process (block, segregate, identify parts),
checks whether the detection system works (is inspection catching it, or is there a “system gap”),
defines what the standard reaction should be in these situations (so it doesn’t depend on who’s on shift).
And very often there’s one question running in the background: “can we actually measure this properly?” If the result is different every time, you go back to MSA, the measurement method, the gauge condition, fixturing, and how the criteria are interpreted.
You have a problem — so you start root cause analysis (without philosophy)
In a perfect world every problem has one root cause you can find in 30 minutes. In real life, the cause is sometimes a combination: a small change in settings, plus a borderline material batch, plus a tired operator, plus inspection that was tuned more for output than detection. Your job is to turn that mess into a clear logic:
you collect process data (parameters, changes, breakdown history) — usually with support from the process engineer and maintenance,
you run a simple analysis: defect Pareto, trend, when it started to go wrong,
you use 5Why / Ishikawa in a way that ends with a decision, not a drawing on a board,
you test hypotheses instead of “guessing at a desk.”
Only then do 8D / A3 / QRQC come in—as a way to structure actions and communication. A well-used tool shortens the time to stabilize the process. It doesn’t exist to generate slides.
You set up safeguards so the issue doesn’t come back in two weeks
Once the fire is under control, the next job is to make the process able to defend itself. In practice, the fix usually ends up in one place—or a few places at the same time:
an update to the Control Plan (inspection frequency, method, reaction plan),
tightening up the acceptance criteria (references, acceptance limits),
improving detection (poka-yoke, sensor, interlock, better measurement). And yes—don’t forget TPM for the poka-yoke, because a “dead” sensor is just a decoration,
stabilizing the process (parameters, settings, maintenance, training),
updating FMEA (if it turns out the risk was underestimated).
One thing matters here: the safeguard has to be usable on the line. If the solution is “smart” but nobody can apply it at line speed, it will survive until the first rough week—then it quietly disappears.
I also strongly recommend bringing a production representative in already at the solution-definition stage, and getting proper sign-off from every shift. If one shift buys in and the next one doesn’t, the same problem will reappear—just with different faces.
Audits: internal, customer, supplier
Audits rarely start with a big confrontation. Most of the time it begins with a simple question:
“Show me the record from the last inspection.”
“Please describe this process.”
“How do you know this gauge is OK?”
“Where is your reaction when the result is out of limit?”
“Does the operator know the requirement and what to do when they see a deviation?”
A quality engineer prepares the plant so the answers are fast and fact-based:
documentation matches what’s actually on the workstation,
records are complete and readable,
people know what’s required and why.
In supplier audits there’s one more layer: assessing risk on the supplier’s side and checking whether their process truly holds the requirements—not just in a nice-looking presentation deck.
Suppliers: the material doesn’t hold—and you collect evidence
Supplier issues can be sneaky: it happens once, then silence, and then it returns at the worst possible moment. Your job is to:
confirm the nonconformity (not “it looks like,” but measurement + criteria),
protect production (sorting, extra inspection, decision to use / reject),
launch the topic at the supplier (8D, action plan, deadlines, ownership),
verify effectiveness (is the improvement real, or just “on paper”).
Communication comes back here every time. If you send data, samples, results, measurement conditions, and clearly state the expected outcome, the conversation moves faster.
In the background: training, standards, “is this in the system?”
And then there’s the work you don’t really see—until something blows up:
training people on reaction to nonconformities, onboarding training, training on types of special characteristics,
tightening up work instructions and inspection methods,
keeping documents aligned (FMEA, Control Plan, Flow Chart, instructions, records),
making sure process changes don’t slip through “the side door.”
That’s everyday life: some operational work, some analysis, some communication. One day you’re on the floor, the next day you’re on a customer call, then you’re deep in data. Boredom doesn’t show up often.
Quality tools every automotive quality engineer needs to know (and when you actually use them)
In automotive, quality tools are 100% practical. They show up at very specific moments: a new launch, the first production after Start of Production (SoP), a process change, a complaint, an audit, a supplier issue. If you know what to reach for—and why—work becomes simpler. If you don’t, you end up chasing documents after the fact.
Core Tools in real life (the set you keep coming back to)
APQP — when the project starts for real
APQP is often associated with a checklist, a kick-off, and a “quality plan.” In real life, it’s about making sure you know from day one:
what the customer requirements are (and where the traps are),
what process risks you already have at the start,
what evidence you’ll need at launch and for PPAP.
APQP is most useful while the project is still shapeable. Once production is running and only then you realize there’s no inspection method or no clear characteristic definition—at that point it’s usually already too late.
PPAP — what the customer wants to see and why
PPAP is the “show me” moment. The customer isn’t asking whether you have a nice metrology lab. The customer is asking whether:
the process produces parts that meet requirements (and yes—in the required volume too),
you can prove it with measurements and records,
you have control over what could go wrong.
The most common failures aren’t dramatic. They’re the classics:
documents don’t line up (FMEA says one thing, the Control Plan says another, and the workstation reality is a third version),
measurement results exist, but the acceptance criteria or method isn’t clear,
process changes went through as a “running change” without informing the customer, while the PPAP still pretends nothing changed.
FMEA and the Control Plan — a pair that has to match the shop floor
FMEA makes sense when it’s used as a tool to think about process risk—not as a file “for the audit.” The Control Plan is the translation into everyday life: what you check, how often, with what method, and what you do when the result is not OK.
If your FMEA and Control Plan don’t match what’s happening at the station, sooner or later you’ll end up on a collision course with a customer complaint or an escalation.
MSA — when measurement starts lying
A lot of people treat MSA as a compliance requirement. But handled practically, it’s one of the tools that saves time and nerves.
Signals you need to go back to MSA:
two measurements of the same part give different results,
operators “agree” on the result because everyone measures a bit differently,
you get production disputes like “this is OK” versus “this is NOK,” and nobody can settle it objectively.
Often the issue isn’t the gauge itself—it’s the method: clamping force, part positioning, measurement location, interpretation of criteria, temperature, wear of the probe tip. MSA helps you catch this before you start sorting good parts as bad (or the other way around).
SPC — when the data tells you “a problem is coming”
SPC is often misused as “let’s drop Cp/Cpk into a report and call it done.” In practice, SPC should help you answer one question: is the process stable—or is it drifting?
SPC makes sense when:
you’re measuring a special characteristic (critical or significant) that’s sensitive to process variation,
the measurement frequency is realistic,
you can react before the product becomes nonconforming.
If you collect data but nobody looks at it—or the reaction comes a week later—then it’s just an archive, not a tool.
Problem solving (what a quality engineer does when the issue already exists)
8D — most commonly used for complaints and customer-driven issues
8D is required in many companies. Why? Because it gives a clear structure: containment, analysis, actions, effectiveness confirmation. The biggest failure in 8D is focusing on the report instead of the facts.
What works in practice:
fast containment of shipments (so the issue doesn’t escalate),
analysis based on data and samples, not opinions,
actions that can actually be sustained on the shop floor,
effectiveness confirmation—not just “implemented” in a spreadsheet.
If the root cause in an 8D is described with a generic line like “operator error,” it usually means the process had a gap in detection or in the work standard.
A3 — strong for process topics and cross-functional problems
A3 is great when the problem is about process flow, communication, ownership, or when there are many threads and it’s easy to get lost. It forces clarity: what exactly is the problem, what data do we have, what are we doing, who owns what, and when do we check results.
QRQC — fast reaction on the shop floor (here and now)
QRQC is the “go to the place, look at facts, act fast” approach. Good QRQC isn’t about putting a board on the wall. It’s about making sure that:
the problem is named immediately and contained,
it’s clear what’s suspected and what must be checked,
ownership for actions is defined,
by the next day there is progress—not “in progress.”
QRQC often carries the first 24–48 hours, before a full 8D is even ready.
5Why and Ishikawa — tools that are easy to ruin
5Why and Ishikawa are simple, so many people do them “just to have them.” The result is often a list of causes that leads nowhere. A solid approach looks like this:
you start with a specific, measurable problem,
every cause needs confirmation (data, observation, trial),
you end on a cause you can address systemically (change in process, detection, standard, tool).
How to connect it all so you’re not living “audit to audit”
If I could give you one practical rule (no motivational speech): the tools have to meet in one place—at the workstation and in the data.
FMEA defines the risk → the Control Plan defines how you control it → the workstation shows it’s actually in place → records confirm it was done → and when something breaks, you react and feed the update back into the Process FMEA / Control Plan. If needed, it escalates to a design change and an update to the DFMEA.
When that chain is broken, quality starts operating after the fact.
Author: Dariusz Kowalczyk
