An incident is underway and everyone is debugging. What role is missing?

What is being tested

Whether you know the role that is most often missing and most determines how the incident goes.

Why the commander

Without one, everyone debugs and nobody coordinates. Symptoms are unmistakable: three people investigating the same hypothesis, nobody investigating another, no decision about mitigation, and stakeholders interrupting responders for updates.

The commander does not debug. That is the discipline, and it is difficult for a senior engineer who can see the problem. Their job is to hold the state of the investigation, assign work, decide, and protect the responders from interruption.

The other roles

Communications lead — updates stakeholders, support and customers on a cadence, so responders are not interrupted. The second most valuable role and frequently absorbed by the commander, which degrades both.

Responders — the people investigating, ideally with clearly assigned hypotheses so effort is not duplicated.

Scribe, where the incident is large — recording the timeline as it happens, which makes the postmortem accurate rather than reconstructed.

The practices that matter as much

Declare early and downgrade later. Under-declaring is the more common and more costly error: by the time it is obviously serious, an hour has been lost with no coordination.

One shared channel, so the timeline reconstructs itself and latecomers can read up rather than asking.

Mitigate before diagnosing. Restoring service and understanding the cause are different activities, and doing them in that order is almost always correct — roll back, fail over, shed load, then investigate.

A decision-maker available for business calls — disabling a feature, accepting degraded behaviour — because those wait indefinitely if nobody is named.

What a strong answer adds

That the roles must be practised, which is what game days are for. An incident is a poor time to discover that nobody knows who commands.