The Fault That Only a Specific Technician Can Reproduce: Decision Tree

Why this matters

Two techs test the same equipment. One gets the fault every time. The other can't reproduce it at all and starts to wonder if the first tech is imagining things or doing something wrong. Both reactions cost you: dismissing a real, technique-sensitive fault as "user error" leaves a genuine problem unfixed, and assuming your teammate is simply mistaken damages trust on the crew. This tree is how to work out whether the difference is in the equipment, the technique, or the conditions, without turning it into a credibility contest.

Start here: rule out the boring explanations first

Before treating this as a genuine technique-dependent fault, check the explanations that have nothing to do with skill.

• Different equipment or setup. Are both techs actually testing the identical unit, in the identical configuration, or is there a subtle difference (a different port, a different test point, a firmware or setting difference) neither noticed?
• Different test tools. A different meter, gauge, or tool model, or one with a calibration drift, can produce a real difference in what gets measured, not just how it's measured.
• Different conditions at time of test. Load, temperature, time of day, or what else is running on the system can make a fault present for one tech and absent for another purely by chance of timing, with no technique difference at all.

If any of these explain it, you've found the answer and it isn't about the person.

If the boring explanations are ruled out: it's technique-sensitive

Some faults genuinely only appear under a specific sequence, pressure, angle, or handling that one tech happens to use and another doesn't. This is real, not a knock on either tech's competence, and it's worth documenting precisely because it's easy to dismiss.

1. Have the tech who reproduces it walk through their exact steps while the other watches, in real time, step by step, rather than describing it after the fact from memory. The difference is almost always in a step that felt too minor to mention.
2. Look specifically for: order of operations, how much force or pressure is applied, whether a component is moved, flexed, or loaded during the test, and the exact test point used. Intermittent faults are frequently connection- or position-sensitive, and a technique that happens to stress the right point will find it while one that doesn't will miss it entirely.
3. Once you've identified the technique difference, test the hypothesis directly: have the tech who couldn't reproduce it try the exact sequence that does. If it now reproduces, you've confirmed the mechanism, and you've also just taught a real diagnostic technique that's worth writing down for the team.

If you still can't isolate what's different

• Consider that the fault may be genuinely intermittent and timing-dependent rather than technique-dependent, and the first tech simply happened to be present during an active window. Log the time, conditions, and duration of each reproduction attempt; a pattern by time or condition will show up in the log even if it's invisible in the moment.
• Consider a physical variable neither tech has isolated yet: ambient temperature, vibration, someone else's equipment running elsewhere on a shared system, humidity. These produce exactly this signature, works for one visit or one tech, not the next, with no technique difference at all.
• If it remains unresolved, don't close it out as "could not duplicate" without a note explaining what's been ruled out. A future tech (possibly the one who "couldn't reproduce it") deserves that context instead of starting from zero.

Recap

1. Rule out different equipment, different tools, and different conditions before treating it as technique-dependent.
2. If it's genuinely technique-sensitive, have the reproducing tech walk through the exact sequence in real time; the difference is usually in a step nobody thought to mention.
3. Confirm the hypothesis by having the other tech try the identified technique.
4. If still unresolved, log it as a genuine intermittent with full detail rather than dismissing it.

References

• Trade-standard practice for structured intermittent-fault documentation
• Manufacturer documentation for connection-sensitive and load-sensitive test procedures
• See related: Forcing an Intermittent to Show Itself; The Diagnostic Log Worth Keeping for Your Own Learning