Breaking tunnel vision during an incident

WHAT THIS TESTS: Whether you can recognize and counteract confirmation bias and anchoring during an incident, where stress pushes teams to latch onto the first plausible story and ignore contradicting evidence.

A GOOD ANSWER COVERS: First, name it: as incident lead, explicitly state that the current theory is one hypothesis among several and that you want to avoid tunnel vision. Demand disconfirming evidence by asking what observation would prove this theory wrong, and check whether the data actually supports it or just fits the story. Run a quick structured brainstorm of alternative hypotheses, including the most recent changes (deploys, config, traffic, dependency incidents) since 'what changed' is the highest-yield starting point. Then parallelize: assign different responders or pairs to investigate distinct hypotheses simultaneously rather than the whole team crowding one theory, with the IC tracking each thread. Re-anchor everyone on observable signals (metrics, logs, traces, the timeline) instead of speculation. If the leading theory cannot be confirmed in a bounded time, explicitly move on. Throughout, keep mitigation efforts (rollback, failover) running in parallel with diagnosis, since restoring service does not require knowing the full root cause.