Incident Commander Role

Definition

The incident commander (IC) is the one person formally accountable for the response to a major incident — not for fixing the technical fault, but for running the effort that fixes it. The IC declares severity, assigns roles (tech lead, scribe, communications), maintains the incident timeline, decides when to escalate or roll back, and owns stakeholder communication until stand-down. The role borrows directly from emergency services command structures, and its first principle is counter-intuitive: the IC keeps their hands off the keyboard.

Why It Matters

Uncommanded incidents fail in predictable ways. Forty people join the call; the three engineers who could fix it spend the hour answering status questions; two responders independently restart the same service; nobody tells support what to say to customers; and an executive, starved of updates, starts directing technical work from the bridge. Mean time to mitigate stretches not because the fault is hard but because the response is unmanaged. A trained IC converts that crowd into an organisation: one decision-maker, one timeline, one voice outward, and specialists left alone to specialise.

How the Role Works in Practice

1. Declare and take command explicitly — "I'm IC, tech lead is Ana, scribe is Ben, comms goes out every 15 minutes from me."
2. Set the severity and the structure — one bridge or channel, roles named, bystanders thanked and released.
3. Keep the rhythm — regular update cadence to stakeholders, even when the update is "no change, next update at :30."
4. Assign, don't absorb — every hypothesis gets a named owner and a deadline; the IC tracks, the owner investigates.
5. Make the hard calls — roll back versus fix forward, fail over versus ride it out — with the information available, at the time it is needed.
6. Hand over or stand down cleanly — long incidents get structured IC handovers; every incident ends with a declared close and a review scheduled.

Real-World Example

A payments platform suffered a database failover that left checkout erroring at 09:12 on a Tuesday. Within minutes forty people had joined the incident call, including two VPs. The three engineers who understood the replication topology spent forty-five minutes narrating their screens to management while two well-meaning responders applied contradictory fixes. Mitigation came at 74 minutes. The post-incident review introduced a trained IC rotation. Three months later a similar failure was declared at 14:03, roles assigned by 14:05, customer comms out by 14:20, rollback decision made at 14:16 — and checkout was healthy at 14:21. Same systems, same engineers, same fault class. The eighteen-minute outcome was not better technology; it was one person whose entire job was to run the response.

Practical Lessons Learned

• The IC must not debug. The moment the commander starts reading logs, nobody is commanding — hand the hypothesis to an owner and keep the picture.
• Announce the cadence and keep it. Stakeholders who know the next update lands at :15 and :30 stop interrupting; stakeholders in the dark interrupt constantly.
• A scribe doubles the IC's effectiveness. The timeline, decisions and actions captured live are the post-incident review half-written.
• Small is fast. Release everyone not actively working a task; a twelve-person bridge is a meeting, not a response.
• Severity drives structure. Not every page needs an IC — a Sev-3 with one responder just needs a ticket. Declare command proportionally.

Expert Tips

• Run game days quarterly where the IC role rotates through engineers and engineering-adjacent staff — command is a practised skill, and the quiet hour of a drill is where people learn it.
• Give the IC explicit authority in writing: they may pull anyone from any meeting, and their rollback decision stands unless a named executive overrules on the record.
• Script the first five minutes — declaration phrases, role assignments, comms template. Under stress, nobody improvises good process.
• Hand over command formally for incidents crossing hours: current state, open actions, next decision point, next comms slot. Ten minutes of structure saves an hour of re-discovery.
• Close every incident with the same three artifacts: timeline, customer impact statement, review date. Future-you, writing the board report, will be grateful.

Common Mistakes

• The most senior engineer appoints themselves IC and then fixes the fault personally — the response has no commander precisely when it needs one.
• Executives freelancing in the channel, asking for updates off-cadence and redirecting responders mid-investigation.
• No declared severity, so a company-wide structure gets applied to a minor fault — or worse, no structure to a major one.
• The IC making decisions silently, so responders work at cross purposes because the plan lives in one head.
• Skipping the review because "it was only twenty minutes" — short incidents are the cheapest training data you will ever get.

Key Takeaways

• Major incidents need one named commander whose product is decisions and communication, not code.
• The IC assigns and tracks; specialists investigate and fix. Mixing the roles halves both.
• A visible update cadence is what keeps stakeholders out of the responders' way.
• Authority, scripts and drills make command real — titles alone do not.
• Every incident closes with a timeline, an impact statement and a scheduled review.

Related Concepts

Pairs with Incident Management, Post-Incident Review, On-Call Rotation, and Blameless Postmortem.