What is an incident commander?
Engineering culture and software practice
An incident commander is the single named person who takes charge of a live incident: coordinating people, deciding priorities, controlling communication and keeping the response moving, without necessarily doing the technical fixing themselves. The role is borrowed from the emergency services Incident Command System and is now standard in software operations. It replaces the pattern where the same heroic engineer always fights every fire alone.
What this means
When a system is down and several people are scrambling, the biggest risk after the fault itself is chaos: two people making conflicting changes, nobody talking to customers, and no single view of what is happening. The incident commander exists to remove that chaos. They hold the overall picture, decide what happens next, and make sure everyone knows their role.
Importantly, the commander does not have to be the best engineer in the room, and often should not be doing hands-on repair at all. Their job is command, control and communication, not typing the fix. That separation is what lets the technical responders focus.
The role has a name and a defined shape because improvised, everyone-piles-in responses fail predictably. Giving one person clear authority, for the duration of the incident only, turns a mob into a team.
Why it matters
The practical question every organisation faces is simple: who is in charge when the website is down at nine in the morning? Without an answer agreed in advance, the answer becomes "whoever shouts loudest" or "the one person who always fixes it", and both are fragile.
In a small firm the role can be lightweight but still real: whoever declares the incident commands it, and their first act is to stop doing hands-on work and start coordinating. Someone has to decide priorities, keep a running record, and make sure a customer-facing message goes out, because silence during an outage does its own damage.
The role also matters because of the clock. Where a regulator or a contract sets a deadline for reporting certain incidents, having one person accountable for the response makes it far more likely those obligations are noticed and met. This is a reason to define the role, not legal advice on any specific duty.
Finally, the role is the cure for hero culture. When the same individual always saves the day, the organisation is one holiday or resignation away from disaster, and it never learns because the knowledge never leaves that person's head.
How it works
Where the term came from
The Incident Command System was developed by Californian fire agencies in the 1970s. A federally funded project called FIRESCOPE, standing for Firefighting Resources of California Organized for Potential Emergencies, was created after catastrophic wildfire seasons in which fires killed people, destroyed hundreds of homes and burned vast areas, and in which the response was hampered by agencies that could not coordinate. FIRESCOPE produced the Incident Command System and a companion multi-agency coordination system. In 1982 the approach was broadened into the National Interagency Incident Management System, and after the September 2001 attacks it was absorbed into the US National Incident Management System, overseen by FEMA.
Software operations adopted the model wholesale. Google's site reliability engineering teams based their incident management on the Incident Command System, describing it in the 2016 book Site Reliability Engineering, in the chapter "Managing Incidents", and in the later SRE Workbook. The system defines clear roles so that, in Google's telling, everyone knows their role and does not stray onto someone else's turf.
The commander's duties and the other roles
The incident commander holds the high-level state of the incident, structures the response, and holds every role they have not delegated. Alongside them sit a small set of defined roles: an operations lead, the only person or group actually changing the system; a communications lead, the public face who updates stakeholders and customers; and a scribe or planning role, who keeps the timeline and handles the longer-term tasks such as arranging handovers. Keeping these separate, counter-intuitively, gives each person more autonomy, because they need not second-guess the others.
Declaring, escalating and handing over
An incident begins when someone declares it, and the person who declares it commands it until they explicitly hand over. Handover matters: incidents outlast human stamina, and a clean handover to a fresh commander, with the state written down, prevents mistakes made through exhaustion. Severity levels help calibrate the response; in a paragraph, they run from a minor, contained glitch up to a major outage affecting many customers or exposing data, with the severity setting who is paged, how often updates go out, and when leaders are informed.
Why hero culture fails, and how teams train
The role exists to replace firefighting by a lone hero. Hero culture burns people out, concentrates all knowledge in one person (a low bus factor), and prevents the organisation learning, because the hero simply absorbs each incident rather than turning it into a documented improvement. Experienced teams rotate the commander role deliberately, train people in it, and rehearse with exercises so that the process is second nature before it is needed under pressure. As the ACM Queue literature on operational practice notes, capturing this knowledge in a shared, discoverable form is what stops each incident being relearned painfully from scratch.
Examples
A retailer's checkout fails on a busy morning. An engineer declares an incident and, instead of diving into the code, becomes the incident commander: they ask one colleague to investigate the payment service, appoint another to post a status update to customers, and keep a running note of what has been tried. Decisions run through one person, so two engineers never restart the same service at once. This is an illustrative scenario.
A charity's donation platform starts rejecting cards during an appeal. The duty manager, who is not technical, takes the commander role: they decide the priority is restoring donations, they hold the line on communication so supporters are told what is happening, and they escalate to the hosting provider. The technical contractor focuses purely on the fix while the commander handles everything else.
A software team of eight has always relied on one senior developer to handle outages. After she is unreachable during a weekend incident and the response flounders, the team introduces a simple rotation: each week a different person is the on-call commander, with a one-page checklist. The next incident is calmer, and, importantly, three more people now know how to run one.
Common misunderstandings
The first misconception is that the incident commander is the best engineer or the most senior person. The role is about coordination and decision-making; in incident roles, authority follows the role and the situation, not the normal reporting chain.
The second is that the commander fixes the problem. Usually they should not touch the system at all; the operations lead does that, while the commander keeps the whole response coherent.
The third is that this is just an AI incident response plan or a post-mortem. It is not. The incident commander is the live role during an incident, unlike the AI incident response plan, which is the document prepared in advance, and unlike the blameless post-mortem, which is the review held afterwards. It is also not the 10x engineer or lone hero the role is designed to replace.
The fourth is that only large companies need it. A one-page version works for a team of a few people; the principle of a single coordinator matters at any size.
The fifth is that declaring an incident is an admission of failure. Mature teams declare early and often, because early declaration and a clear commander limit the damage.
Risks and boundaries
The full emergency-services model can be overkill. A small organisation that tries to appoint four separate leads for a minor glitch will add ceremony without benefit. The minimum viable version is one named coordinator who stops doing hands-on work, keeps a written timeline, and owns communication; roles can be added only as an incident grows.
The role also has limits. A commander cannot conjure knowledge they do not have, which is why the surrounding practices, runbooks, training and a healthy bus factor, matter as much as the role itself. And the authority is strictly temporary and situational: it exists for the incident and dissolves when the incident closes, which is what makes it acceptable for a junior person to direct a senior one during a crisis. Standards such as ISO 22320 set out requirements for incident response and command more formally for organisations that want them, though most small firms will not need that level of formality.
What to do next
Decide now who is in charge when something breaks, and write the rule down: whoever declares the incident commands it until they hand over. The answer must exist before the outage, not during it.
Give the commander explicit permission to stop doing technical work and to direct others, including people senior to them, for the duration of the incident. Make clear this authority is temporary and situational.
Adopt a one-page checklist covering declare, assign roles, communicate, keep a timeline, and hand over. The NCSC's incident management guidance is a good, free UK reference for the shape of this.
Rotate and rehearse the role so it does not rest on one person. If the same hero always runs incidents, treat that as a risk to fix, not a strength to celebrate.
FAQs
Does the incident commander fix the problem?
Usually not. They coordinate, decide priorities and control communication, while a separate operations lead makes the actual technical changes.
Where does the role come from?
The Incident Command System developed by Californian fire agencies in the 1970s under FIRESCOPE, later absorbed into FEMA's national system and adopted by software teams.
Does a small team need an incident commander?
Yes, in a lightweight form. Even a one-page rule that whoever declares the incident coordinates it is a large improvement on chaos.
Can a non-technical person be the commander?
Yes. The role is coordination and decision-making, so a manager can command while technical staff handle the fix.
What are the other roles?
Typically an operations lead, a communications lead, and a scribe or planning role, delegated by the commander as the incident needs.
How does it relate to hero culture?
It replaces it. Relying on one heroic engineer causes burnout, a low bus factor and no learning; a rotating commander spreads the load.
Why does the reporting clock matter?
Because some incidents carry reporting deadlines, and one accountable person makes those far more likely to be met. This is a reason to define the role, not legal advice.