Two Techs Disagree on Diagnosis: Tiebreak Decision Tree

Why this matters

When two competent techs look at the same equipment and reach different conclusions, the worst outcome is letting seniority, volume, or stubbornness decide instead of evidence. A diagnosis chosen by who argued hardest rather than what the data shows leads to wrong parts, repeat failures, and a customer caught in the crossfire of an internal disagreement they should never see. Disagreement itself is healthy; it means at least one tech is questioning a theory before parts get ordered. The risk is resolving it badly: defaulting to the senior person regardless of evidence, splitting the difference into a fix that addresses neither cause, or replacing both suspected parts to avoid the argument and inflating the customer's bill. A structured tiebreak turns two opinions into a better single answer than either tech had alone, and it keeps the conflict out of the customer's view entirely.

The situation

Two techs, either on the same job or one reviewing the other's work, hold different root-cause theories for the same symptom. One says it is component A, the other says component B, and the recommended repair differs accordingly. A decision has to be made about what to actually do, ideally before a part is ordered or the customer is quoted, and the customer is often waiting on the answer. The disagreement may be live on site between two techs dispatched together, or asynchronous, where a second tech inherits a job and reads the first tech's notes with a different conclusion in mind. Either way the resolution method should be the same, because the goal is the correct diagnosis, not a winner.

What is at stake

The immediate stake is a correct repair versus a wrong one that triggers a callback. There is a cost stake too: replacing both suspected components to sidestep the disagreement doubles the parts cost and erodes margin or overcharges the customer. There is a team stake, because how a disagreement is handled sets whether techs feel safe questioning each other in the future or learn to stay quiet. And there is a customer-trust stake, because if the disagreement leaks into the conversation, the customer loses confidence in the whole company, not just one tech. Resolving on evidence protects all four.

Decision factors

• What each theory predicts and how to test it. A good diagnosis makes a falsifiable prediction; the better theory is usually the one you can confirm or rule out with a measurement.
• The strength of supporting evidence behind each position. Readings, error codes, and observed behavior outrank intuition and "I have seen this before."
• The cost and reversibility of being wrong on each path. A cheap, easily-undone test beats committing to an expensive irreversible repair on contested grounds.
• Safety implications of each theory. If one theory implies a hazard, it must be ruled out before proceeding regardless of which tech holds it.
• Relevant specialization. One tech may have deeper experience with this exact equipment or failure mode, which is evidence to weigh, not a trump card.
• Time and customer pressure. Whether the customer is waiting on site with the system down, which may force a cheap reversible step now and a definitive determination later rather than a prolonged on-site debate.

The decision

Resolve by test, not by rank. First, ask each tech what measurement or observation would prove their theory and disprove the other; if such a test exists, run it, because the equipment is the tiebreaker. When a definitive test is available and cheap, it always wins over argument. When no clean test exists, choose the path that is cheaper and more reversible first, so that if it is wrong you have lost little and gained diagnostic information. If the two theories carry different safety weight, the more conservative path wins until the hazard is ruled out. Only when testing is impractical and both paths are comparably costly should you escalate to a third opinion, a senior tech, or the manufacturer's technical line, and let that input break the tie. Never default to replacing both parts to avoid the conversation; that is hiding a diagnostic failure inside the customer's invoice, and it teaches both techs that they never have to resolve a disagreement because the customer will fund the ambiguity. Throughout, present one unified recommendation to the customer; the internal debate stays internal, because a customer who hears two of your people contradict each other loses confidence in the company even when one of them is right. If the matter genuinely cannot be settled on site and the system is down, the fair move is the cheap reversible step now plus a clear plan to confirm, communicated as one company position rather than as two competing ones.

What to document

Record both theories and the evidence behind each, so the reasoning is preserved if the chosen path fails. Document the test you ran and its result, or the cost-and-reversibility logic if you proceeded without a definitive test. If you escalated, note to whom and what they concluded. Whatever the outcome, capture which theory the evidence ultimately supported, because that is exactly the data that makes the next disagreement faster to settle and helps both techs calibrate. Handled this way, disagreement becomes a training asset rather than a friction point: the tech whose theory the evidence rejected learns something concrete, and the one whose theory held learns to articulate the readings that proved it. A culture where techs can challenge each other and let the equipment settle it produces better diagnosticians than one where the senior person is always right by default, because in that culture nobody questions a wrong call until the customer does.

References

• Occupational Safety and Health Administration, General Duty Clause, 29 U.S.C. 654(a)(1) (conservative-path obligation when a diagnosis implies a recognized hazard)
• Magnuson-Moss Warranty Act, 15 U.S.C. 2301 et seq. (consequences of misdiagnosis-driven part replacement under warranty representations)
• Air Conditioning Contractors of America (ACCA), technical-diagnostic and quality-control guidance
• Electronics Technicians Association International (ETA), root-cause analysis and peer-review best practices