What Does an Incident Commander Actually Do? The Delegation Boundary
An incident commander coordinates the response to a major incident and fixes nothing themselves. They hold the overall picture, decide what happens next, delegate every repair action to the people who own the systems, and keep the response from turning into six engineers changing things at once. PagerDuty's publicly published incident response documentation states the boundary plainly: the incident commander is not a resolver.
This article covers where the role comes from, the specific things an incident commander does during an incident, the boundary that defines the job, who should hold it, and why the most common failure is a technically excellent person quietly abandoning the role mid-incident. It is a coordination job, and treating it as a senior engineering job is what breaks it.
Where the role comes from
Incident command is borrowed wholesale from emergency services. Google's incident management approach, described in its SRE material as IMAG, is explicitly based on the Incident Command System, the structure used in the United States for coordinating responses to wildfires and similar emergencies. PagerDuty's process, published openly at response.pagerduty.com, uses the same lineage.
That origin explains the parts of the role that feel strange in a software context. The commander does not need to be the most knowledgeable person present. Authority attaches to the position rather than the person, which is why PagerDuty's own documentation says the incident commander becomes the highest-ranking individual on a major incident call regardless of their day-to-day rank, and describes the willingness to remove a distracting participant from the call as a requirement of the job even when that participant is the chief executive. In an emergency-services context nobody finds that surprising. In an engineering org it takes explicit sanction to work, which is why it has to be written down before the incident rather than asserted during one.
Alongside the commander, both models define supporting roles: a deputy acting as a hot standby rather than an observer, a scribe keeping the timeline, subject matter experts who own the affected systems, and a communications or customer liaison role handling external updates. Our guide to incident management best practices covers how those roles fit into a broader process.
What the job consists of during an incident
Establish and hold a single channel. The first act is getting everyone into one place, whether that is a call or a chat room, and funnelling latecomers into it rather than answering the same question in five threads.
Run the roll call and build the picture. Ask each system owner for the status of their area, in turn, and assemble those answers into a coherent statement of what is happening. This is information gathering, and doing it properly is what makes the later decisions defensible.
Collect proposed actions, then choose one. Responders suggest repairs. The commander decides which one is taken, by whom, and when, then says so unambiguously. Google's SRE material makes the same point from the other direction: the operations role should be the only group modifying the system during an incident, which is only possible if somebody is authorising changes.
Acknowledge everything you are told. Explicitly confirming that you received and understood a responder's message lets them move on. PagerDuty's guidance puts it as clear being better than concise, and the reason is that abbreviated commands under stress produce misunderstandings that cost more time than the words saved.
Set and track timers. Decide when the current approach gets re-evaluated, and hold to it. Without a clock, a promising fix absorbs an hour before anyone asks whether it is working.
Prompt the communications role. The commander does not write the customer update, but they decide when one is needed, review it, and approve it.
The delegation boundary, and why it defines the role
Call it the delegation boundary: everything on the commander's side of the line is a decision, and everything on the other side is a repair. The commander crosses it exactly never during an incident. If they need to make a change themselves, the correct move is to formally hand over command first.
This is the part that gets violated most, and it gets violated by the best people. The natural failure is a senior engineer taking the commander role, spotting the fix ten minutes in, and dropping into a terminal to apply it. The moment that happens the incident has no coordinator. Nobody is running the roll call, nobody is tracking the timer, nobody is deciding what happens if the fix does not work, and the other five responders start improvising in parallel. The incident does not usually get worse dramatically; it gets worse quietly, and the postmortem records twenty minutes nobody can account for.
This is also why deep technical knowledge is explicitly not a prerequisite. PagerDuty's training documentation says so directly. What the role needs is the ability to size up a situation, listen to expert input, decide quickly, change course when the experts say to, and communicate without ambiguity. Those are different skills from debugging, and pretending they are the same is why organisations keep appointing their best engineer and wondering why coordination is poor.
Who should hold the role, and how they get ready
Not the person who owns the broken system. They are your most valuable subject matter expert and you need their attention on the failure, not on the call structure.
Not automatically the most senior person present either. Seniority and coordination ability are unrelated, and a commander who is also the person everyone reports to makes it harder for responders to say the fix is not working.
The practical answer most mature teams reach is a rotation of trained commanders, separate from the engineering on-call rotation, drawn from anyone with the temperament for it. PagerDuty's own path runs through shadowing an active commander, then reverse shadowing where the trainee runs the incident with an experienced commander ready to take over, and only then going on the schedule. That progression matters because the role is unpractised by definition. Major incidents are rare, so without deliberate training the first time somebody commands one is during a real outage at three in the morning.
Common mistakes in running incident command
The commander starts fixing things. The most common and most damaging error. If you need to touch the system, hand over command first and become a subject matter expert.
Appointing the owner of the broken system. They are the person you most need thinking about the failure. Putting them in charge of coordination costs you your best debugger and gives you a distracted commander.
Leaving the authority implicit. The role only works if everyone has agreed in advance that the commander outranks the room during an incident. Deciding that mid-outage, with an executive on the call, does not go well.
Skipping the deputy. Somebody has to watch the timers and catch what the commander missed. A deputy is a working role, not a shadow, and a single commander tracking everything alone will drop something.
Declaring the role only for the largest incidents. Teams that reserve incident command for catastrophes never practise it. Declaring early and often, even when the incident turns out to be minor, is what makes the process reliable when it is needed.
FAQ
What does an incident commander actually do?
They coordinate the response and make the decisions. That means establishing one communication channel, gathering status from system owners, choosing between proposed fixes, delegating every repair action, tracking timers, and approving external communications. They do not perform the repairs themselves.
Does an incident commander need deep technical knowledge?
No, and PagerDuty's published training documentation says so explicitly. The role needs situational assessment, decisiveness, willingness to be corrected by experts, and unambiguous communication. High-level knowledge of how the systems relate is useful; the ability to debug them is not the point.
Who should be the incident commander?
Ideally a trained commander from a rotation kept separate from the engineering on-call schedule, and specifically not the owner of the failing system. Seniority is not the qualifying factor, and putting the most senior person in the role can make responders reluctant to push back.
What is the difference between an incident commander and a deputy?
The deputy is a working support role rather than an observer. They track timers, catch items the commander missed, and act as a hot standby ready to assume command if the commander needs to step into a technical role.
Closing thought
The strangest thing about incident command is how much of it is about restraint. The role is defined less by what the commander does than by what they refuse to do, and the discipline that makes it work is a competent engineer sitting on their hands while someone else types. That is genuinely difficult, which is why it needs training rather than an announcement.
None of the coordination helps if the clock started late. Odown checks from seventeen global locations at intervals down to one minute on every plan and routes alerts through Slack, Discord, Telegram, Opsgenie, PagerDuty, email, and webhooks, so the roll call begins from a detection you did not have to wait for a customer to report. Every minute an incident runs undeclared is a minute the delegation boundary does not exist yet.
