When Two Technicians Genuinely Disagree: The Resolution Process

Why this matters

Two competent techs can look at the same failed unit and land on different causes. That is not a sign someone is incompetent, it is a sign the evidence is ambiguous or one of them is missing a piece of information the other has. How a shop handles that moment decides whether the customer gets a confident, unified answer or watches two people argue in their driveway. Handled badly, a disagreement becomes a comeback, a bad review, or a tech who quietly stops speaking up. Handled well, it is one of the best training moments a shop has.

Disagreement is a signal, not a failure

Treat a genuine diagnostic split as data. It usually means one of three things: the fault presents ambiguous symptoms that legitimately point two directions, one tech has information the other does not (a callback history, a reading taken earlier, a customer detail), or one tech is pattern-matching from experience while the other is following the textbook fault tree and neither has actually confirmed the failure yet. None of those are a discipline problem. Jumping straight to "who is right" skips the more useful question: what does each person actually know that the other does not?

Separate opinion from evidence

The fastest way to collapse a disagreement is to make both techs state their case as evidence, not conclusion. Ask each one: "what did you measure or observe, specifically, that leads you there?" A conclusion like "I think it is the control board" is not evidence. A reading, a visual finding, or a customer statement is. Write both evidence lists side by side. Very often one list is longer or more direct, and the disagreement resolves itself once it is laid out, because one tech was reasoning from a hunch and the other from a confirmed reading.

The questions that actually settle it

Work through these before pulling in anyone else:

• Did both techs test the same thing, or different things? A disagreement about "is it the sensor or the board" often means one person tested the sensor and one tested the board, and neither tested both. Closing that gap is diagnosis, not arbitration.
• Is either diagnosis actually confirmed, or are both still theories? If neither tech has isolated the fault (see the parts-cannon anti-pattern article), the disagreement is premature. The fix is more diagnosis, not a vote.
• Does one diagnosis explain all the symptoms and the other only some? The theory that accounts for every symptom the customer reported, not just the most obvious one, usually wins.
• Is there a simpler explanation neither has tested yet? Two experienced techs disagreeing between two complex causes sometimes both missed a simple one underneath both of them.

When it's genuinely a coin flip

Some faults really do sit at the edge of ambiguity, most often intermittent faults, faults with overlapping symptom sets, or borderline readings sitting right at a spec limit. If two reasonable people looking at the same confirmed evidence still land in different places, that is not a failure of process, it is the nature of the fault. In that case, resolve by verification, not authority: run the specific test that would prove one theory and rule out the other, even if it takes extra time. A coin flip resolved by rank ("the senior tech decides") still leaves you guessing; a coin flip resolved by one more targeted test leaves you knowing.

Rank has a role, but it's the tiebreaker, not the referee

Experience should weight a disagreement, but it should not silence it. A junior tech's evidence-backed observation deserves the same table time as a senior tech's, and a shop that always defaults to seniority trains its junior people to stop speaking up, which is the exact quality-control signal you want to keep. Use rank as the tiebreaker only after both cases have been heard and neither more testing nor a simpler explanation resolves it. If seniority decides, say so out loud and record the reasoning, not just the verdict, so a genuinely wrong senior call gets corrected next time instead of ossifying into "how we do it here."

Document both, not just the winner

Even after the team lands on one diagnosis, write down that a second, reasonable theory existed and why it was ruled out. This protects the shop two ways: if the chosen fix does not hold, the second theory is already on record as the next thing to test, and if the customer later asks "another tech said it might be X," you have a documented answer instead of an improvised one. See the related article on documenting competing diagnoses for the customer-facing version of this record.

References

• Trade-standard practice for structured fault isolation before repair
• Internal quality-control practice: pairing junior and senior technicians on ambiguous calls
• See related: The Parts-Cannon Anti-Pattern; Documenting Two Competing Diagnoses for the Customer