Five engineers join a P1 channel. Three are checking the same dashboard. Two are deploying conflicting fixes. Nobody is talking to customers. Forty minutes in, the incident is worse than when it started — not because the team lacked skill, but because nobody was in command.
This is what incidents look like without an incident commander.
An incident commander (IC) is the single person accountable for the entire incident response from the moment it’s declared to the moment the postmortem is signed off. The IC doesn’t fix the problem — they make sure the right people fix it, in the right order, with the right information flowing to the right places.
What you’ll learn in this guide:
- Why the IC role exists and what separates it from other incident roles
- The one rule every IC must follow (and what happens when they break it)
- The five-minute playbook for the moment a P1 fires
- How to build and rotate an IC program across your engineering team
Table of Contents
- What Is an Incident Commander?
- The Golden Rule: The IC Does Not Touch the Keyboard
- Incident Commander vs. Tech Lead vs. Communications Lead
- IC Responsibilities: From Declaration to Postmortem
- The First 5 Minutes: What an IC Does When a P1 Fires
- How to Build an IC Rotation Program
- IC and On-Call: How They Work Together
- 4 Common IC Mistakes
- FAQ
What Is an Incident Commander?
An incident commander is the designated leader of an incident response — the single point of accountability from the moment an incident is declared to the moment it’s closed.
The role has roots in emergency services, where the Incident Command System (ICS) was developed after coordination failures in the 1970 California wildfires caused preventable deaths. Google and Amazon brought the same command structure to software engineering: one person holds command, all decisions funnel through them, and nobody freelances.
Quick Answer: An incident commander is the person who declares the incident, assigns roles, drives decisions, owns stakeholder communication, and leads the postmortem — without touching the code or keyboard. The IC holds the 30,000-foot view so technical responders can focus entirely on resolution.
The incident commander is not a permanent title. It’s a role that activates during an incident and deactivates when the incident is resolved. Most engineering teams rotate the IC function across several trained engineers, just as the primary on-call role rotates.
IC vs. incident manager: The terms are used interchangeably in most organisations. When a distinction is drawn, the incident commander holds broader authority — including the power to define how the response is structured — while an incident manager focuses on mitigating the specific active incident.
The Golden Rule: The IC Does Not Touch the Keyboard
Every IC training programme leads with the same rule: the IC does not touch the keyboard.
This isn’t about hierarchy. It’s about cognitive capacity. The moment an incident commander starts running queries or debugging code, they lose their view of the full incident. While their attention is on a database connection pool, a cascading failure on an adjacent service goes undetected for 20 minutes.
Coordination failures at team handoff boundaries — not technical gaps — drive the majority of incident costs. Poor coordination alone adds 33% to breach containment time (SageSims, 2025). The IC exists precisely to prevent that failure mode.
What the IC does instead of debugging:
- Asks sharp questions: “What’s the blast radius if this deploy rolls back?”
- Sets priorities: “Stop the bleeding first — optimise later.”
- Sequences decisions: “Before anyone touches the database, confirm the read replica is healthy.”
- Manages time: “It’s been 15 minutes. What’s changed? What’s our next step?”
- Controls information: “One update to stakeholders, from one person, every 20 minutes.”
When the incident touches a system the IC knows well, the urge to debug usually beats the urge to coordinate. Experienced ICs describe resisting this urge as the hardest part of the job. The rule is a forcing function, not an insult to their technical ability.
Incident Commander vs. Tech Lead vs. Communications Lead
Most incidents above P2 severity need three active roles. Each has a fundamentally different job — and they cannot be merged without damaging response quality.
| Role | Primary job | Touches keyboard? | Talks to customers? |
|---|---|---|---|
| Incident Commander | Coordinate, decide, sequence | No | No |
| Tech Lead | Diagnose, remediate, implement fix | Yes | No |
| Communications Lead | Update stakeholders, manage status page | No | Yes |
Why you can’t combine IC and Tech Lead
These roles have opposite cognitive demands. The tech lead needs to be head down, focused on root cause, working through the problem sequentially. The IC needs to be scanning the whole incident continuously, tracking multiple threads, and making decisions with incomplete information. Requiring one person to do both produces a worse outcome at each.
When a team is too small to separate these roles, the IC should stay in command and delegate the technical work completely — even if they’re the most qualified person to perform it. A slightly slower diagnosis coordinated well beats a faster fix that creates three new problems.
Scribe and communications lead are often the same person at smaller organisations. The scribe maintains a timestamped decision log during the incident. The communications lead owns external updates. On teams of four to six engineers, one person can carry both; above that, separate them.
IC Responsibilities: From Declaration to Postmortem
The IC’s job spans the full incident lifecycle. Each phase has a distinct set of actions.
Phase 1: Declare
- Acknowledge the alert and open a dedicated incident channel
- Set the initial incident severity level — P1 through P4
- Page the tech lead and communications lead
- Announce yourself as IC in the channel: “I’m IC for this incident. Tech lead: [name]. Comms: [name].”
Phase 2: Assemble
- Confirm every role is filled and acknowledged
- Brief the team in two sentences: what’s broken, what we know so far
- Link to the relevant runbook in the channel immediately
- Set communication cadence: “Stakeholder update every 20 minutes until resolved.”
Phase 3: Command
- Ask the tech lead for a hypothesis within 5 minutes: “What do you think it is?”
- Require two-point confirmation before any hypothesis becomes the working theory
- Approve significant changes before they execute — no unilateral deploys during a P1
- Escalate to the next tier per the escalation policy if the incident isn’t contained within the defined window
Phase 4: Communicate
- Own every external update — the comms lead drafts, the IC approves
- Separate channels: one for technical responders, one for stakeholder updates
- Never communicate uncertainty as fact: “We are investigating” is better than a wrong diagnosis
Phase 5: Resolve
- Confirm the fix is verified, not just deployed
- Declare the incident resolved with an explicit statement in the channel
- Set a time for the postmortem: “Postmortem scheduled for Thursday 14:00 UTC.”
Phase 6: Debrief
The IC leads the blameless postmortem. Their job in that session is to guide the discussion toward root causes and actionable follow-up items — not to assign blame for decisions made under pressure. Postmortems should be held within 24–72 hours of resolution, while memory is fresh but emotions have cooled.
The First 5 Minutes: What an IC Does When a P1 Fires
The first five minutes of a P1 set the trajectory for the entire incident. Here is what an effective IC does, in sequence:
Minute 0–1: Acknowledge and claim command
- Acknowledge the alert in the alerting platform
- Open a dedicated channel named
#incident-[date]-[brief-description] - Post in the channel: “IC on scene. This is a P[severity]. I’m taking command.”
Minute 1–2: Assign roles
- “@tech-lead: You’re leading technical investigation. What do you see?”
- “@comms-lead: You’re handling stakeholder updates. First update in 10 minutes.”
- “@scribe: Track all decisions and timestamps in the incident doc.”
Minute 2–3: Gather first facts
- What is broken? (service, region, feature)
- Who is affected? (all users, specific customers, internal only)
- When did it start? (alert time vs. actual impact start — these often differ)
Minute 3–4: Set the initial severity and activate escalation if needed
- Confirm severity based on impact scope — per your incident severity levels
- If it’s a P1 involving revenue or data: page leadership per escalation policy now, not in 20 minutes
Minute 5: First stakeholder update
- Send a factual, short update to the status channel and status page
- Template: “We are investigating [brief symptom]. Impact: [who is affected]. Next update in 20 minutes.”
The IC does not begin debugging at any point in this sequence. The MTTA target for P1 incidents is under 5 minutes — the IC’s job in those five minutes is command structure, not root cause.
How to Build an IC Rotation Program
An IC rotation program is the structured system for training engineers to take the IC role and distributing that duty across the team.
Who should become an IC?
The IC role does not require the most senior engineer — it requires strong communication, calm decision-making, and coordination skills. Engineers who make good ICs tend to:
- Stay organised under time pressure
- Communicate clearly in writing, quickly
- Ask “what’s the impact?” before “what’s the cause?”
- Know when to escalate rather than wait
Technical depth helps for asking sharp questions, but it’s secondary to coordination ability.
The four-stage training path
Stage 1 — Observe: Attend four to six real incidents as a silent observer. Read the timeline, watch how the IC sequences decisions, note what communication patterns work.
Stage 2 — Shadow: Join incidents as the scribe. Maintain the decision log. This builds the habit of timestamping everything and forces you to listen actively rather than react.
Stage 3 — Buddy: Take the IC role with a senior engineer available to consult (not to take over). Run tabletop exercises first — “Failure Fridays” or structured incident simulations — before going live.
Stage 4 — Solo with backup: Take the IC rotation independently. A senior IC is in the escalation path but does not intervene unless explicitly requested.
Debrief every incident for the first three months: what went well in coordination, what slowed the response, what decision timing could improve.
Rotation cadence
For a team of eight to twelve engineers, weekly IC rotation works well — the same cadence as on-call scheduling best practices. The IC rotation can be separate from the primary on-call rotation, or the same person can carry both for their week. Separating them distributes cognitive load; combining them simplifies the schedule.
Every IC shift needs a designated backup — an experienced IC who can step in if the primary is unavailable or overwhelmed. A rotation with no backup is one sick day away from an unled P1.
IC and On-Call: How They Work Together
The incident commander and the primary on-call engineer are not the same role, even when carried by the same person.
The primary on-call owns alert acknowledgment and initial triage. They’re the first human in the loop when a page fires. Their goal is to get eyes on the problem fast — MTTA under 5 minutes for P1s.
The incident commander owns the response from declaration through resolution. They may be paged by the primary on-call or may self-activate based on alert severity.
For P3 and P4 incidents, the primary on-call often handles both functions without formally declaring an incident. For P1 and P2 incidents, a named IC should always be active. This is where the MTTA and MTTR metrics diverge: fast MTTA without IC command often produces slow MTTR, because acknowledgment without coordination still leaves the response unled.
Your escalation policy should define exactly when the IC function activates — typically at P2 or above — and which engineer takes command. Teams that leave this ambiguous find out the cost during their next unled P1.
itoc360 is purpose-built for this handoff. Alert ingestion, escalation routing, and on-call scheduling work as a coordinated system — so when a P1 fires, the IC is paged automatically, not after five minutes of manual escalation.
4 Common IC Mistakes
Mistake 1: The keyboard trap
The IC starts debugging because they know the system best. Thirty minutes later, nobody is tracking a second failure that started while the IC was focused on the first. Fix: Write “I am IC, I will not touch the keyboard” in the incident channel when you take command. Public commitment creates accountability.
Mistake 2: Underestimating severity at declaration
Teams consistently set initial severity too low because the first responder hopes the problem is smaller than it looks. This delays IC activation, stakeholder notification, and escalation. Fix: Default to the higher severity when uncertain. It’s easier to downgrade a P1 to P2 after 15 minutes than to explain why P1 customer impact went unannounced for an hour.
Mistake 3: Communication blackout
The IC gets absorbed in the technical response channel and forgets stakeholder updates. Customers punish silence more than slow fixes. Fix: Set a timer — every 20 minutes, a stakeholder update goes out, no exceptions. The comms lead drafts, the IC approves in 30 seconds.
Mistake 4: Skipping or rushing the postmortem
Incidents closed without structured review produce the same incidents again. The IC’s most durable contribution is turning each incident into a learning artefact. Fix: Schedule the blameless postmortem before declaring the incident resolved. If it’s not scheduled, it doesn’t happen.
Conclusion
The incident commander role is the difference between five engineers working in parallel chaos and a coordinated team that resolves incidents in a fraction of the time. The IC doesn’t need to be the most technically skilled person in the room — they need to be the most coordinated one.
Four things to take away:
- The IC does not touch the keyboard. Coordination is the job. Technical work belongs to the tech lead.
- The first five minutes set the trajectory. Declare, assign roles, gather facts, send the first update — in that order.
- IC is a rotation, not a title. Train it like on-call: shadow, buddy, solo, debrief.
- IC and on-call are different functions. For P1 and P2 incidents, they should always be named explicitly — even if the same person carries both.
If your on-call and incident management platform isn’t designed to activate the IC role automatically based on severity, that gap costs you minutes on every P1. itoc360 handles alert routing, escalation policy, and IC paging as a single coordinated system. For a deeper reference on structuring incident response teams, Google’s SRE Workbook incident response chapter covers the command structure in detail.
Frequently Asked Questions
What is an incident commander in IT?
An incident commander (IC) is the single person accountable for leading incident response from declaration to resolution. The IC assigns roles, makes decisions, manages communication, and keeps the timeline moving — without performing any technical troubleshooting themselves.
What is the difference between an incident commander and an incident manager?
The terms are often used interchangeably. When a distinction is drawn, the incident commander holds authority across the entire response lifecycle — including defining the IC role itself — while an incident manager focuses on mitigating a specific active incident.
Does the incident commander need to be the most senior engineer?
No. The IC needs strong communication, decision-making, and coordination skills — not the deepest technical expertise. Many high-performing teams rotate the IC role across mid-level engineers, with a senior backup available to consult.
How many incident commanders does a team need?
Every P1 or P2 incident needs exactly one IC. For a team running 24/7 on-call coverage, you need enough trained ICs to cover the rotation without burnout — typically four to six engineers with IC certification for a team of eight to twelve.
What should an incident commander do first when a P1 fires?
In the first five minutes: acknowledge the alert, open a dedicated incident channel, set the initial severity, assign a tech lead and communications lead, and send the first stakeholder update. The IC does not begin debugging.