Incident Command
also called Incident Command System, ICS
Assigning explicit roles during an incident — commander, operations lead, communications lead, scribe — so coordination does not compete with diagnosis.
Adapted from emergency services. The failure it prevents is the one every unstructured incident has: six engineers all debugging, nobody deciding, nobody talking to stakeholders, and no record of what was tried.
The roles: the commander decides and coordinates but does not debug — this is the rule most often broken and the most important, because the moment the commander starts typing, nobody is running the incident. Operations performs the technical work. Communications handles stakeholders and status updates so responders are not interrupted. Scribe records the timeline, which is what makes the postmortem possible and is invariably lost otherwise.
Two practices make it work: the commander is whoever declared the incident until explicitly handed over, regardless of seniority; and severity levels are defined in advance so the response is proportionate and nobody negotiates scope while the site is down.
Small incidents do not need all four roles. The threshold for invoking them should be low enough that the structure is familiar when it matters.