Major Incident Response Responsibilities
Effective major incident response separates command from execution. The Incident Commander (IC) coordinates, sets severity, makes trade-off decisions, and keeps the responder group focused; the IC does not debug. Supporting roles include the Operations/Technical Lead who directs hands-on mitigation, the Communications Lead who owns the status page, stakeholder updates, and customer messaging, and the Scribe who records a timestamped timeline and decisions. Subject matter experts are pulled in as needed and released when their part is done. On smaller incidents one person may wear several hats, but the separation of communicating from fixing is the principle that survives.
The lifecycle runs detect → triage → declare → mitigate → resolve → learn. Declaring an incident early and assigning severity is cheap; under-declaring is the classic failure. During response the priority is stop the bleeding first, find root cause later - mitigation actions (rollback, failover, traffic shift, feature flag off, scale out) generally come from recent-change hypotheses and known runbooks. Communication runs on a fixed cadence (for example every 30 minutes even when nothing changed), because silence is interpreted as incompetence by stakeholders. Handoffs between ICs need an explicit briefing. Afterwards, a blameless postmortem reconstructs the timeline, distinguishes trigger from contributing causes, and produces action items with owners and due dates that are actually tracked.
Traps: the IC joining the debugging; skipping stakeholder comms until resolution; severity assigned retroactively; postmortems with vague actions like "be more careful" and no owners; resolving without verifying that user-facing SLIs recovered; and forgetting to cancel false alarms in monitoring so the next responder knows the state.
Rule of thumb: if two people are working the incident, one of them should be communicating. If nobody is communicating, the incident commander role has effectively been dropped.