How do you decide when a technical disagreement is significant enough to escalate beyond your immediate team, versus letting it go?

Escalate based on actual stakes and reversibility, not on how strongly you personally feel about being right — a disagreement over something low-risk and easily reversible is usually not worth spending escalation capital on, even if you're confident you're correct, while a disagreement over something high-risk, hard to reverse, or touching safety/compliance/security is worth escalating even if it creates friction, because the cost of being wrong (by staying silent) outweighs the social cost of raising it further. The interviewer is checking for proportionality and judgment, not for a consistent bias toward either "always push" or "always defer."

The reasoning process worth demonstrating has a few concrete dimensions, not just a gut feeling about escalation:

Reversibility: a decision that's easy to undo if it turns out wrong (a config value, a naming convention, most day-to-day implementation choices) doesn't need escalation even if you disagree — the cost of being wrong is low, and the team can course-correct later without drama. A decision that's expensive or impossible to reverse (an architecture choice locking in months of future work, a security posture, a data model that's painful to migrate later) has a much higher cost if wrong, which justifies pushing harder, including escalating, even at the cost of some team friction.

Actual risk magnitude, not just personal conviction: being very confident you're right isn't itself sufficient justification to escalate — a disagreement can feel important without actually being high-stakes. The better question is "what's the realistic worst case if this goes the way I disagree with, and is that worst case actually severe" — not just "how strongly do I feel about this."

Whether normal channels have actually been exhausted first: escalating should generally follow having raised the concern directly with the people involved first, given a real chance to be heard and to update the decision, rather than skipping straight to a manager or a broader forum at the first sign of disagreement — jumping straight to escalation without that step reads as poor judgment about process, not just about the technical substance.

Whether escalation actually has a mechanism to help, or would just create friction without resolving anything — escalating to someone with no actual ability or standing to change the outcome is often just adding noise rather than genuinely surfacing a decision-worthy risk.

A strong interview answer names these dimensions concretely, ideally with a real example distinguishing "I let this one go because the downside was small and reversible" from "I escalated this one because the downside was severe and hard to undo" — showing the judgment is genuinely proportional to stakes, not a fixed personal disposition toward either conflict-avoidance or contrarianism.

• Escalation should track actual stakes and reversibility, not personal conviction about being right.
• A low-risk, easily-reversible disagreement usually isn't worth escalating even with strong personal confidence; a high-risk, hard-to-reverse one often is, even at the cost of friction.
• Escalation should generally follow, not skip, raising the concern directly with the people involved first.
• Escalating to someone with no actual standing to change the outcome just adds friction without resolving the underlying risk.

• Google SRE Book: Postmortem Culture