How do you decide when to escalate or pull in another team during an incident, versus continuing to investigate solo?
Short Answer
Escalate based on a combination of severity (how bad is the user impact, and is it getting worse) and elapsed investigation time without meaningful progress (not "have I tried everything" but "have I been going in circles for a while with no new information") — a genuinely time-boxed self-check ("if I haven't made real progress in N minutes, escalate") removes the ambiguity of deciding in the moment, which is exactly when judgment is hardest to trust under pressure.
Detailed Explanation
The core difficulty is that the decision has to be made under exactly the conditions that make good judgment hardest — mid-incident, under time pressure, with your own assessment of "am I close to figuring this out" being notoriously unreliable in the moment (people investigating alone consistently underestimate how close or far they actually are). A few concrete practices make this decision less dependent on in-the-moment judgment alone:
Set an explicit time-box in advance, not decided mid-incident: agreeing on "if I haven't made meaningful progress within N minutes (commonly 15-30 for a severe incident), I escalate" as a standing team norm — decided calmly beforehand, not negotiated with yourself under pressure — removes the ambiguity of the in-the-moment decision. This isn't about giving up; it's about recognizing that a fresh perspective is often more valuable than more time spent by the same person who's already tried the obvious things.
Weight severity independently of investigation time: for a severe, actively-worsening incident (a full outage, active data loss), escalating immediately — even before any solo investigation — is often correct regardless of how long you've been looking, since the cost of delay is high enough that parallel investigation from more people outweighs the overhead of bringing them up to speed. For a lower-severity, contained issue, a longer solo investigation window before escalating is a reasonable trade-off, since the cost of continued impact is lower.
"Meaningful progress," not "have I tried everything," is the actual bar: the time-box shouldn't be about exhausting every possible thing to check — it's about whether you're actually learning new information that's narrowing down the cause, versus repeating similar checks with the same inconclusive result. Genuine progress (even without a full answer yet) is a reasonable basis to continue a bit longer; going in circles is the signal to escalate, even if the clock hasn't technically run out.
Escalating isn't a failure signal, and treating it as one is exactly what causes people to escalate too late: a team culture that treats escalation as "admitting you couldn't handle it" directly causes people to delay past the point they should have asked for help — explicitly normalizing escalation as a routine, expected part of incident response (not an exception reflecting poorly on the person escalating) removes that psychological barrier to escalating at the appropriate time.
Interview Follow-Up Questions
- How would you calibrate the specific time-box duration for your team's actual incident severity levels?
- How would you handle a case where escalating brings in someone who also doesn't immediately know the answer — what's the next step?
- How would you build this "escalation is normal, not a failure" culture on a team where it currently isn't the norm?
Key Takeaways
- An explicit, pre-agreed time-box for solo investigation removes the unreliable in-the-moment judgment call about whether you're "close."
- Severity should weight the decision independently of elapsed time — a severe, worsening incident often warrants immediate escalation regardless of how long you've looked.
- "Meaningful progress" (learning new, narrowing information) rather than "have I exhausted every option" is the right bar for continuing solo.
- Normalizing escalation as routine, not a failure signal, is what actually gets people to escalate at the right time rather than too late.
References
Related Questions
- How do you decide when a technical disagreement is significant enough to escalate beyond your immediate team, versus letting it go?SuggestedIntermediate
- How would you decide whether an S3 public-write exposure is a supply-chain security incident requiring broader notification, versus a contained issue?SuggestedAdvanced
Last updated August 21, 2026 · Last reviewed August 21, 2026