Incident Commander

The incident commander (IC) is the person who runs the response — not necessarily the engineer deepest in the codebase. During an active incident, the IC coordinates people, sets priorities, tracks status, and ensures decisions are recorded while technical responders work on mitigation.

The IC role is one of the clearest differentiators between ad-hoc firefighting and structured incident management. Without a commander, teams duplicate effort, talk over each other, and lose minutes debating who is in charge.

Why it matters

Incidents are parallel problems: diagnosis, communication, escalation, and customer updates all happen at once. The IC frees specialists to focus on their lane. They also decide when to page additional help, when to publish a status page update, and when the incident can move to a lower-intensity stage.

Example

During a payment outage, the IC might:

• Assign a communications lead for external updates
• Direct the database engineer to investigate replication lag
• Call a go/no-go on rolling back the latest deploy
• Keep a live timeline so the next on-call rotation handoff has context

The IC does not need to be the most senior engineer — they need calm, clarity, and authority to say “stop” and “next.”

Common mistakes

• No IC assigned until chaos peaks — name one in the first minutes of triage.
• IC also doing all technical work — coordination suffers; split roles early.
• Rotating IC every hour without handoff notes — use a shared timeline.
• IC making irreversible calls alone — major customer or security decisions need explicit agreement.

Use the incident response template to document IC responsibilities alongside comms lead and escalation paths. Pair the role with runbooks for known failure modes so the IC can route work instead of improvising structure under pressure.