Diagnostic Repair Strategy: Why Process Matters
When it comes to diagnostics, my goal is simple: take the path most likely to repair the vehicle correctly the first time.
That sounds obvious, but it is where a lot of technicians still get sideways. Too many people are looking for a silver bullet. They want the one common fix, the one bad module, the one known issue that gets the vehicle out the door fast. Sometimes that works. More often it burns time, parts, and confidence.
That problem gets worse as vehicle systems get more complex. Advanced driver assistance systems are one of the clearest examples of why diagnostic strategy matters.
ADAS calibrations themselves usually are not the hard part. The hard part is what happens when the calibration does not go through, the system does not behave like service information says it should, or the fault path is not obvious. This is where the gap shows between a diagnostician and a parts changer.
A diagnostician wants to know what the problem is, how the system is supposed to operate, what inputs it needs, what outputs it should produce, and what tests can confirm or deny a working theory. If the first round of tests does not produce anything conclusive, the diagnostician adjusts the hypothesis and keeps working.
A parts changer does something different. They go looking for the most likely answer before they fully understand the problem. They jump on forums, search groups, or pull up a product that shows top fixes. They want someone else to hand them the answer. That is not diagnostic strategy. That is outsourced guesswork.
What made ADAS different was not just the sensors or targets. It was the number of ways a system could fail and still not give the technician a clean path to the answer.
A lot of technicians grew up with the idea that if you had a diagnostic trouble code and service information, you could work the problem from there. ADAS showed quickly that was not always true. You could have failure states with little to no useful DTC direction. You could have service information that only gave generic checks and sent the technician in circles. You could confirm that a module was mounted correctly and still have the problem be firmware, coding, version mismatch, or even whether the factory tool completed programming correctly.
As complexity has gone up, there are more ways for systems to fail. If a technician attacks a modern problem with old habits and assumes the path is linear, the odds of getting to the right answer go down.
One of the biggest mistakes technicians can make is treating the DTC as the problem.
A DTC must be associated with some failure or error state in the vehicle, but that does not mean the system always failed in the exact way the flow chart assumes. Sometimes a system fails in a way that mimics a certain DTC path. The code is real. The symptom is real. But the service information tied to that code may not be correct for the actual problem sitting in front of the technician.
That is where technicians get trapped. They trust the code too much. They skip checking TSBs and recalls. They do not verify firmware level. They jump to the bottom of the flow chart because they think they already know the answer. Or they replace a control module too early without ruling out everything around it first.
When I start to suspect a module like a PCM, TCM, or BCM, I proceed with caution. Those modules are built to do a job at a high duty cycle. That does not mean they never fail. It means I want to be sure I have ruled out every other reasonable cause before I condemn one.
Technicians use judgment heuristics every day. There is nothing wrong with pattern recognition; a technician’s experience matters. The problem starts when probability gets treated like certainty.
When a vehicle presents a problem similar to something the technician has seen before, the urge is to apply the same repair now. That may work. It may also be wrong because the root cause is different even though the symptom looks familiar.
The industry structure makes this worse. Flat rate pushes a turn-and-burn mindset. Diagnostics often does not pay in a way that rewards deep work. Advisors do not always want to sell every hour of diagnostic time because they feel pressure from the customer. Production flow pushes for fast answers so the next vehicle can get moving. Managers want updates. Phones ring. People interrupt the process in the middle of a line of thought.
Fast thinking is useful when it helps narrow what to test first. It becomes a problem when it causes the technician to decide what the fix is before the testing is done.
For me, diagnostics starts with the customer's concern in detail.
What is the customer actually experiencing? When did it start? Under what conditions does it happen? Has the customer tried to fix it? If the vehicle came from another shop, what did that shop already do? What were their findings? If it came from a collision repair shop, I want to know the repair scope, what was replaced, and whether the parts used were new, used, or aftermarket.
From there, I scan the vehicle and look at the full picture. If there are a lot of DTCs, I do not lock onto one. I look for a possible correlation and ask whether multiple codes may point back to one failure. Then, I pull up system operation information. I want to understand how the system is supposed to work before I start deciding how it failed.
Next, I verify the condition and monitor the data points that look relevant. I do not want the flow chart biasing me too early if the live data is telling me something else.
After that, I work through the DTC information and rank possible causes from most likely to least likely or group the codes in a way that points to a common problem. Then I build a hypothesis and start testing. The first round might be connections, corrosion, harness issues, aftermarket accessories, or obvious physical faults.
If I find the problem, I repair it and verify it. If I do not, I revise the hypothesis and start the next pass. That second run may go beyond the flow chart and move more into tests tied to how the system should operate. If I get deep enough into a problem and still do not have a clear answer, I bring in another technician for differential diagnosis.
That process is slower than guessing, but it is far more repeatable.
One thing ADAS teaches quickly is that not every electronic-looking problem is really electronic.
Early in my ADAS calibration work, I had a late-model Mazda Miata that was having trouble passing blind spot monitor calibration with the Doppler box. My initial thinking was that the BSM module may have been damaged in the collision and was not receiving the Doppler generator signal at full strength.
I removed the rear bumper to verify module installation and check for unrepaired damage. I did not find any. Then I ran the calibration again with the bumper removed. This time it passed.
That changed the direction of the diagnosis immediately. I talked with the collision shop and found out the rear bumper cover had been repaired in the area of the BSM module instead of being replaced. A new bumper cover went on the car, and the calibration was completed without an issue.
That problem looked electronic. It was not. The system was affected by a physical repair condition.
I had another case on a 2020 Audi Q8 that drove this point even harder.
The vehicle had a laser distance scanner replaced after a collision. I programmed the new module as required and then moved to calibration. The calibration failed. I adjusted the sensor. No change. I moved the target. No change. I ran the programming again. No change.
At that point, against my better judgment, I called the module bad out of the box. We all know the joke that "new" sometimes means "never ever worked." I got another module, repeated the process, and got the exact same result.
Now, I was thinking firmware or programming path. I reached out for factory support. Their first response was to point at setup and environment. I knew that was not the issue, but I still documented everything: shop setup, photos, lighting measurements, and target specs.
That is when support came back and confirmed that the factory diagnostic software was not actually completing the programming routine correctly on its own. An SVM code had to be entered for the programming to be applied correctly. Once that was done, the programming took and the calibration completed successfully.
That case stuck with me because it proved something important. Sometimes the diagnostic tool itself has to be questioned.
From there, I scan the vehicle and look at the full picture. If there are a lot of DTCs, I do not lock onto one. I look for a possible correlation and ask whether multiple codes may point back to one failure. Then, I pull up system operation information. I want to understand how the system is supposed to work before I start deciding how it failed.
Next, I verify the condition and monitor the data points that look relevant. I do not want the flow chart biasing me too early if the live data is telling me something else.
After that, I work through the DTC information and rank possible causes from most likely to least likely or group the codes in a way that points to a common problem. Then I build a hypothesis and start testing. The first round might be connections, corrosion, harness issues, aftermarket accessories, or obvious physical faults.
If I find the problem, I repair it and verify it. If I do not, I revise the hypothesis and start the next pass. That second run may go beyond the flow chart and move more into tests tied to how the system should operate. If I get deep enough into a problem and still do not have a clear answer, I bring in another technician for differential diagnosis.
That process is slower than guessing, but it is far more repeatable.
Another thing that gets overlooked is how often diagnostics start with bad information.
Sometimes another technician is trying to cover up something they did not do correctly. Sometimes a body technician accidentally damages a harness or gets weld spatter into a connector. Sometimes service information is incomplete or has misprints. Sometimes the customer tries to fix the car and leaves that part out because they do not want to admit it.
And sometimes the handoff to the technician is just, "Customer states the system does not work." That is not a diagnostic starting point. That is a guessing contest.
Good leaders have to protect the diagnostic process from constant interruption. Good technicians must resist the urge to fill in missing information with assumptions.
I think the industry still underestimates what strong diagnostics require.
There has been a lot of hiring from outside the automotive field into ADAS work. That can be good. Fresh eyes are valuable. But, when people are trained only on a narrow frame of vehicle repair, they often do not have the foundation to reason across the full vehicle when something goes wrong.
The industry has also not done a great job encouraging continuing education. On top of that, there is often no clear growth path for technicians who want to become diagnosticians. In some shops, the technician who gets deeper into diagnostics feels punished for it, either by pay structure, workflow, or constant pressure.
The takeaway here is not complicated.
Technicians need a dialed-in process for diagnosis. If they rely on judgment heuristics alone, they will get some lucky wins, but over time the losses will be greater.
Shops need to set customer expectations up front. They need to gather and pass along the right information. Service advisors and managers need to give technicians room to work without constant disruption. That can be handled with clear time marks for progress updates, so the technician knows when communication is expected.
Leaders also need to build better compensation plans, better cultures, and better work environments. If a shop wants strong diagnostics, it has to support the kind of thinking that strong diagnostics requires.
In modern vehicle repair, especially ADAS, the silver bullet mindset is not enough. The shops and technicians who will win are the ones who build a repeatable process, trust evidence over ego, and stay disciplined long enough to find the real root cause.
About the Author
Paul Bostel
Director of Advanced Vehicle Technology
Paul Bostel is a seasoned leader with a rare blend of expertise in both advanced automotive technology and fire service operations. With over 20 years in the automotive industry, he is recognized as one of fewer than 2,300 ASE World Class-certified technicians — a distinction that underscores his mastery in diagnosing and repairing complex vehicle systems, with a specialized focus on ADAS. Paul is director of Advanced Vehicle Technology for Quality Collision Group, where he applies his analytical precision and strategic mindset to elevate operational performance and repair standards.
In parallel with his automotive career, Paul has proudly served the Apple Valley Fire Department for over nine years and holds the rank of captain, demonstrating his strong leadership, commitment to community service, and ability to manage high-pressure environments. His career is defined by innovation, efficiency, and a continuous drive to raise industry standards across every role he takes on.