How to Teach Your Own Diagnostic Method to a New Tech
Why this matters
A tech with twenty years in the trade walks up to a dead system, puts a hand on two things, takes one reading, and names the fault. Ask how they did it and you get "you just know." That answer is honest and it is useless, and it is the reason so much diagnostic ability dies with the person who has it.
They do have a method. It has been compiled down to something that runs below conscious thought, the way an experienced driver does not narrate a lane change. The teaching problem is not motivation or patience, it is decompilation: getting a method that has become invisible to its owner back into a form somebody else can execute.
Do this badly and you produce a parts-swapper who memorized your conclusions without your reasoning. That person is fine on the faults you showed them and dangerous on the one you did not, because they have no way to know they are off the map.
Step 1: Catch yourself in the act of narrowing
Before you can teach the method you have to observe it, and you cannot observe it while performing it at speed.
For one week, on every diagnostic call, the moment you feel yourself commit to a direction, say out loud what just happened. Not the conclusion, the input. "I just heard it try to start and quit, so I am now working the safety side and not the power side." Write it down at the end of the call.
Ten of those across a week is enough. What you will find is that four or five inputs are doing almost all of the narrowing work, and that most of them are things you never mention when you teach, because they happen before you consciously start diagnosing.
The commonest ones: what the customer said in their own words, what the equipment did in the first ten seconds, the state of things around the equipment, and the age of the installation. These are the free information, and experts use them heavily while beginners ignore them completely and go straight for a meter.
Step 2: Write the method as a sequence of questions, not answers
An answer list is a lookup table and does not generalize. A question list is a method and does.
Convert each narrowing moment into the question it answered:
- Weak: "if it hums and does not start, check the start components."
- Strong: "does it try and fail, or does it not try at all? Trying and failing means the command reached the device, so the fault is downstream of the command. Not trying at all means I am working the command path."
The second version teaches a split the learner can apply to a device they have never seen. The first version teaches one fault.
Aim for four to seven questions in order. Fewer than four and you have not decomposed anything; more than seven and nobody will carry it, and you have probably mixed in specific-fault knowledge that belongs in a separate reference.
Each question needs three parts: what you are asking, how you find out, and what each answer eliminates. The elimination is the part beginners never get told, and it is the entire value of the sequence.
Step 3: Separate the rule from the shortcut, and teach the rule first
You have two overlapping systems: the ordered method from Step 2, and a large pattern library - this noise on this vintage is almost always this part. The pattern library is faster and it is what you use most days.
Teach the method first and hold the patterns back. A learner given your shortcuts before your method gets fast and brittle: they pattern-match a symptom to the wrong cause with no procedure to catch themselves, because the procedure was never installed underneath.
The rule to say out loud: a shortcut is a hypothesis you still confirm with a measurement. When your pattern says a component has failed, you still measure it before you replace it. Skip that in front of a learner and you have taught them that guessing is how experts work, and no amount of later correction undoes it.
Step 4: Make them predict before they measure
This is the highest-yield single technique in this article and it costs no time at all.
Before any reading, ask two questions: what do you expect this to read, and what will you conclude if it reads something else. Then take the reading.
Three things happen. Their internal model becomes visible, including the wrong parts, which you would never have found by asking whether they understood. The reading becomes memorable because it confirmed or violated a prediction they committed to. And they learn that a measurement taken with no expectation attached teaches nothing.
Watch specifically for the learner who cannot state what a bad reading would look like. That is a person taking measurements ritually, and they will report a badly wrong number without blinking.
Step 5: Narrate your rejects, not just your picks
When you diagnose, you consider and discard several possibilities in a second or two, silently. The learner sees only the survivor and concludes you went straight there, which makes your ability look like magic and their own process look broken.
Say the discards: "could be the supply, but the rest of the building is fine, so no. Could be the control, but it went through its sequence, so no. That leaves the load side."
Three or four seconds, and it converts an unreachable leap into a visible elimination. It also teaches what the alternatives even were, which they cannot get any other way - a possibility you never mention is one they do not know exists.
Step 6: Hand over the sequence and keep only the veto
At some point the learner has to run the method with you standing there not running it. This is uncomfortable and it is where the transfer actually happens.
Set the terms before you walk in:
- They run the sequence out loud, in order, including the predictions.
- You do not correct a wrong step until it produces a wrong reading, unless it is a safety issue or it will damage something. A step corrected before it fails teaches nothing; a step that fails and gets traced back teaches permanently.
- You keep an absolute veto on anything hazardous or destructive, exercised immediately and without discussion.
- If they get stuck for more than a set number of minutes, agreed in advance, you take over cleanly and debrief afterward rather than hovering. Hovering while somebody flounders in front of a homeowner damages the learner's standing with customers for months.
Step 7: Test on a fault you have seen, then on one you have not
A learner who solves the faults you demonstrated has learned your answers. The real test is a fault outside the demonstration set, and the order matters: first faults you walked them through, to confirm the sequence is retained, then a fault in the same family with a different presentation, then a call where you genuinely do not know the answer walking in.
That third case is also where you teach the most important thing you own, which is what you do when the method runs out: how you decide to stop, what you go read, who you call, and how you tell a customer you need more time. A learner who has only ever seen you succeed has no model for the failure case, and the failure case is where new techs make their worst decisions.
Step 8: Write it on one page and let them keep it
The method from Step 2, four to seven questions, each with how to find out and what it eliminates. One page, their copy, in their bag.
Then ask them to rewrite it in their own words after a month. The rewrite is the real assessment: what they drop is what they never understood, and what they add is what your method left out and their experience supplied.
A worked example: decompiling a no-output call
Illustrative numbers throughout; run your own tracking rather than adopting these.
The senior tech's Step 1 week produces this observation: on a no-output complaint, they reach a correct subsystem in an average of 2 measurements. The apprentice, working the same complaint type, averages 7 measurements and lands on the wrong subsystem about 40 percent of the time before recovering.
Decompiled into five questions:
- Is there a call for it to run at all? Found by checking the command signal at the device. No signal means everything downstream is innocent and the whole load side is eliminated.
- Does it attempt and fail, or not attempt? Found by observing the first ten seconds. Attempting eliminates the command path.
- Is anything protecting it open? Found by checking the safety and limit devices in series. An open one is usually a symptom, so the question becomes what opened it, not just that it is open.
- Is supply present and stable under load? Found by measuring under load, not at rest. Beginners measure at rest, see a good number, and eliminate a supply fault that would have shown itself the moment the device pulled current.
- Does the device itself accept the input? Found by measuring at the device terminals with the command present. This is the last question, deliberately, because it is the one that requires the most disassembly.
Question 4 is the one the senior never mentioned in years of informal teaching, because measuring under load is automatic for them. It was also the source of the apprentice's most frequent wrong turn.
Now the tracking, over 12 supervised calls after the method card was handed over. Metric: correct subsystem identified within 3 measurements.
- Calls 1 to 4: 1 of 4. The learner is following the card but slowly and is still reaching for the meter before answering question 2.
- Calls 5 to 8: 3 of 4. The free-information questions have become automatic.
- Calls 9 to 12: 4 of 4.
Overall, 8 of 12, which is 67 percent, and more usefully the trend inside it goes from 25 percent to 100 percent across the block. Average measurement count over the same 12 calls falls from 7 to about 3.5, a 50 percent reduction.
Put that in day terms. At roughly 4 minutes per measurement including access and setup, 7 measurements is about 28 minutes of diagnosis and 3.5 is about 14, so roughly 14 minutes saved per diagnostic call. On a day with 3 diagnostic calls that is about 42 minutes, which is most of an additional call.
Note what the numbers do not say. The 40 percent wrong-subsystem rate is not in the after-tracking because after the card the learner's errors changed character: they stopped going to the wrong subsystem and started being slow inside the right one. That is the expected progression, and if you are only tracking the outcome you will miss it. Track measurement count as well as correctness, or you will not be able to see improvement in the phase where the learner is right but inefficient.
What changes the answer
A learner with an adjacent-trade background. They arrive with a method already, usually a good one, and your job is reconciling two methods rather than installing one. Ask them to state their sequence first and then map yours onto it, or you will spend weeks fighting a model you never made visible.
Equipment with useful onboard fault reporting. The method compresses, but do not let it collapse into reading a code and replacing what the code names. Teach the code as an input to question 1, not as a substitute for the sequence, or you have built a parts-swapper with a better excuse.
Two seniors with genuinely different methods. Do not average them. Pick one as the learner's primary until the sequence is solid, then introduce the second as a deliberate comparison. A beginner exposed to two competing sequences at once builds neither.
High-hazard work. The predict-before-measure and let-them-fail steps still apply, but the veto threshold moves way down and the failure has to be caught before contact, not after a reading. Never trade a teaching moment against a hazard.
How to verify you got this right
Hand the learner a symptom verbally, with no equipment present, and ask what they would check first and what it would eliminate. If they name a component, the transfer failed - they learned your answers. If they name a question and what each outcome rules out, it worked.
Second check: ask them to describe a case where the method did not produce the answer and what they did next. A learner with no such case has not been given a hard enough call yet.
Third check: read their one-month rewrite of the method card. If it is your page copied out, they memorized it. If the wording has moved and the eliminations are still correct, they own it.
References
- See related: Building an Apprentice's Diagnostic Vocabulary Over Time, for the term-level layer beneath the method
- See related: The Difference Between Adjacent Skill and Guessing
- See related: How to Have a Trainee Teach It Back to You, for the rewrite check in Step 8
- See related: How to Let a Trainee Fail Safely and Learn From It, for the failure terms in Step 6
- Trade-standard practice for structured diagnostic instruction in field service