Incident Roles: Commander, Scribe & Comms Lead

What's in this guide

• What each role does, what it does not do, and who makes a good fit
• The one rule that matters more than any role definition
• How to staff the roles at 15, 40 and 100 engineers, with a table you can steal
• The trade-offs, including when roles are overkill

Why incident roles exist at all

Picture a typical SEV-1 without roles. Checkout is down. Six engineers are in a Slack channel. Three of them are debugging the same database. Nobody has told support anything, so support is asking in four different channels. The VP of Engineering joins and asks for an ETA every ten minutes, and the person most likely to fix the problem is the one answering him. Forty minutes in, someone asks "wait, did anyone roll back the deploy?" and the honest answer is that everyone assumed someone else had.

None of these people are bad at their jobs. The incident simply had no structure, so everyone did the most visible thing instead of the most useful one.

Incident roles fix that by giving each kind of work exactly one owner. The idea is older than software: the Incident Command System was built in the 1970s to coordinate wildfire crews in California, where a dozen agencies needed one shared answer to "who is in charge here?". Google's SRE book adapted it for production outages, and most modern incident response processes, PagerDuty's open-source one included, are variations on the same theme.

The one rule that matters more than any role definition: at any moment during an incident, everyone in the channel should be able to answer "who is running this?" with a single name. If they can't, you don't have roles, you have a group chat.

Incident Commander

The Incident Commander (IC) runs the response. Not the fix. The response.

What the IC does

• Declares the incident and its severity, and changes the severity when the facts change
• Decides who works on what, and makes sure no two people are silently working on the same thing
• Makes the calls nobody else wants to make: roll back or roll forward, wake up the database team or wait ten more minutes, take the feature offline or keep limping along
• Runs short check-ins ("what do we know, what are we trying, what do we need?") at a steady rhythm
• Declares the incident resolved and makes sure someone owns the follow-up

What the IC does not do: debug. This is the hardest part of the job, especially for strong engineers. The moment the IC opens a terminal, nobody is watching the whole incident anymore. If you are the IC and you are the only person who can fix it, hand the IC role to someone else and go fix it. That is a perfectly good decision. Doing both is not.

Who makes a good IC: someone calm, decisive and comfortable saying "I don't know yet, here is what we're doing about it". Seniority helps less than you'd think. The IC needs to understand the system well enough to follow the conversation, not well enough to fix it. Some of the best ICs are mid-level engineers who have been through a few incidents and enjoy keeping a room organised. Some of the worst are principal engineers who can't resist taking the keyboard.

The handover habit: for long incidents, ICs hand over every few hours, and they do it out loud. "I'm handing IC to Priya. Current state: we've rolled back, errors are down 80%, we're waiting on the cache to warm. Priya, you have it." Then Priya confirms in the channel. A silent handover is how you end up with two commanders, or none.

Scribe

The Scribe keeps the written record of the incident while it happens: what was observed, what was tried, what was decided, and when.

What the Scribe does

• Writes a timestamped timeline in the incident channel or document as things happen
• Records decisions with the reason behind them ("rolled back v4.12 because errors started at deploy time")
• Notes open questions and loose ends that nobody has picked up yet
• Hands the timeline to whoever writes the post-mortem, so the review starts from facts instead of memories

Why it matters more than it looks: the timeline is the raw material for everything that comes after. Without it, your post-incident review becomes six people reconstructing a 2 a.m. outage from scattered Slack messages and a strong sense that "it was probably around 2:40". Memories are confident and wrong. Timestamps are boring and right.

Who makes a good Scribe: someone who can follow a technical conversation without being needed in it. This is a great role for newer engineers. They learn more about how your systems fail in one incident as Scribe than in a month of reading docs, and nobody expects them to fix anything.

The honest trade-off: a lot of the Scribe's job can be automated. If your tooling already logs alerts, acknowledgements, escalations, status changes and comments with timestamps, the Scribe's job shrinks to capturing decisions and the reasons behind them, which no tool can do for you. On smaller teams, that slimmed-down version is usually done by the IC, and that's fine.

Communications Lead

The Communications Lead (Comms Lead for short) owns every message that leaves the incident channel: to customers, to support, to leadership and to the rest of the company.

What the Comms Lead does

• Posts and updates the public status page
• Gives support a short, accurate line they can send to customers
• Keeps leadership informed so they stop asking the responders directly
• Sets a predictable update rhythm ("next update in 30 minutes") and keeps it, even when the update is "no change yet"

Why this needs its own person: every stakeholder question that reaches an engineer costs that engineer their focus. One "any ETA?" from a VP can cost the person fixing the database five minutes of context. The Comms Lead is a shield. Stakeholders talk to the Comms Lead, the Comms Lead talks to the IC, and the engineers keep working.

Who makes a good Comms Lead: someone who writes clearly under pressure and knows the difference between what you know and what you hope. Engineering managers, support leads and customer success people are often better at this than engineers. The best updates are plain: what is affected, what we are doing, when you will hear from us next. Leave out root cause guesses. You will be wrong about the root cause at least once per incident, and customers remember the first explanation, not the correction. For more on what good updates look like, see incident communication.

Internal and external, split or not: larger organisations sometimes split this role into an internal liaison (leadership, other teams) and a customer liaison (status page, support, key accounts). Until one person can't keep up with both, one Comms Lead is enough.

SMEs and Ops: the people doing the fix

Subject Matter Experts (SMEs) and operations responders do the technical work: they investigate, try fixes, roll things back and confirm recovery. This is the role everyone already understands, because it existed long before anyone talked about roles.

What changes when you have the other roles

SMEs get to focus. They report findings to the IC instead of to six people, they don't write status updates, and they don't have to decide on their own whether to wake up another team. The IC decides, the SMEs execute.

A few rules that keep SMEs effective

• One problem, one owner. If two people are investigating the database, the IC should know and should have decided that on purpose.
• Say what you're about to do before you do it. "I'm going to restart the payment workers" in the channel takes three seconds and stops two people restarting different things at once.
• Pull in the right expert early. The cost of waking up the database specialist ten minutes too early is a grumpy specialist. The cost of waking them up an hour too late is an hour of outage. Clear escalation policies make that call easier.
• Leave when you're done. An SME who is no longer needed should say so and step out. A crowded channel makes everything slower.

How roles scale from 15 to 100 engineers

Here is the part most role guides skip: you do not need four people for every incident, and a 15-person team that staffs roles like a 500-person company will drown in process. Roles are a list of jobs that must get done. How many people do them depends on your size and on the severity of the incident. Your severity levels should decide how much structure you use.

At around 15 engineers, the most important change is cultural, not structural: make it normal to say "I'll be IC" out loud when an incident gets serious, and normal to hand it off. Your on-call engineer is the default IC. If they are also the only person who can fix it, they hand the IC role to the next person who joins, even if that person is less senior. Keep a one-page cheat sheet of what each role does, so a tired engineer at 3 a.m. doesn't have to remember it.

At around 40 engineers, incidents start crossing team boundaries, and that is when a separate IC pays for itself. You don't need a formal rotation yet. A list of five or six people who have done it before and are happy to be pulled in is enough. This is also when a dedicated Comms Lead starts to matter, because you now have enough customers and internal stakeholders that updates become a job of their own.

At around 100 engineers, you need an IC rotation that is separate from your service on-call rotations. The engineers on call for a service should be fixing it, not coordinating it. Train your ICs, let new ones shadow a few real incidents, and give them the authority to pull anyone in. At this size the Scribe becomes its own role again for major incidents, because there are too many decisions for the IC to capture while also running the response.

Signs you've outgrown your current setup: incidents where two people both thought they were in charge, status updates that went out late or not at all, post-mortems that start with "we're not sure exactly when this happened", and the same three senior engineers acting as IC for every incident because nobody else has done it.

Where tooling helps (and where it doesn't)

Roles are a people problem first. No tool will make your IC calm or your Comms Lead clear. But tooling can take the busywork out of each role, and that is where an incident management platform earns its keep.

In All Quiet, which is what we build, that looks like this:

• For the IC: escalation policies and on-call schedules mean the IC doesn't have to work out who to wake up. From Slack, the IC can pull a specific person or team into the incident instead of searching a spreadsheet for "who knows the database".
• For the Scribe: alerts, acknowledgements, escalations, status changes and comments land in the incident's history timeline with timestamps, so the Scribe only has to capture decisions and reasons.
• For the Comms Lead: stakeholders can follow an incident in a read-only Slack or Microsoft Teams channel without being able to click anything they shouldn't. On the Pro plan, status pages are included, and internal comments can be published to a status page or hidden again later.
• For SMEs: alerts arrive by push, SMS, voice call, email, Slack or Teams, so the right expert actually gets woken up.

Pricing is public. The Standard plan, which covers on-call schedules, escalations and every alert channel, is $4.99 per user per month on the US price list, and status pages come with the Pro plan at $9.99. EU-hosted accounts are billed 6,99 € and 11,99 €, because the price follows the hosting region. The honest version: if your team is 15 people and has two serious incidents a year, a shared Google Doc and a Slack channel will get you a long way. Tooling starts to matter when incidents are frequent enough that the busywork adds up, or when paging the wrong person is costing you real time.

The trade-offs nobody mentions

Roles can make small incidents slower. If a minor bug triggers a full IC, Scribe and Comms Lead setup, you have spent four people's attention on something one engineer could have fixed in ten minutes. Tie the roles to severity, and let minor incidents stay minor.

The IC role lands on the same people. Without a deliberate rotation, the same two or three experienced engineers end up running every serious incident. They burn out, and nobody else learns. Pair new ICs with experienced ones on real incidents, even when it is slightly slower.

A Comms Lead with nothing to say still has to say something. "No change, still investigating, next update at 14:30" feels pointless to write. It is not. Silence is what makes stakeholders start messaging engineers directly, which is exactly what the role exists to prevent.

Titles don't transfer authority on their own. If the most senior engineer in the channel overrules the IC whenever they disagree, the IC role is decoration. Leadership has to back the IC publicly, including when the IC tells a VP to wait for the next update.

Frequently Asked Questions

What are the main roles in incident management?

The four core incident roles are the Incident Commander, who coordinates the response and makes decisions; the Scribe, who records a timestamped timeline; the Communications Lead, who updates customers, support and leadership; and Subject Matter Experts, who investigate and fix the problem. Larger organisations sometimes add a deputy incident commander or split communications into internal and customer liaison roles.

What does an incident commander do?

An incident commander leads the response to a serious incident. They set the severity, decide who works on what, make calls such as whether to roll back, run regular check-ins, and declare the incident resolved. They deliberately do not debug or fix the problem themselves, so that someone always has an overview of the whole incident.

Should the incident commander be the most senior engineer?

Not necessarily. The incident commander needs to understand the system well enough to follow the technical conversation, stay calm and make decisions. Deep expertise is usually more valuable in the subject matter expert role. Senior engineers are often better used fixing the problem while a well-practised mid-level engineer runs the response.

Who should be the scribe during an incident?

Anyone who can follow the technical discussion without being needed to fix the problem. It is a good role for newer engineers, because it shows them how systems fail. On small teams the incident commander often keeps the timeline, especially when tooling already records alerts, acknowledgements and status changes automatically.

Do small teams need incident roles?

Yes, but not as separate people. A team of around 15 engineers can cover all four roles with two or three people by combining them, for example one person acting as incident commander and scribe while another fixes the problem. What matters is that everyone knows who is in charge and who is communicating, not how many people are involved.

What is the difference between an incident commander and an incident manager?

The terms are often used interchangeably. Where they differ, the incident commander leads the response during a live incident, while an incident manager owns the incident process over time: severity definitions, on-call structure, post-incident reviews and follow-up actions. In smaller companies the same people usually do both.

Sources and further reading

The role model in this guide draws on a few well-known public sources. All checked 5 October 2026.

• Managing Incidents, Site Reliability Engineering (Google), chapter 14. The standard reference for separating incident command, operational work, communication and planning, adapted from the Incident Command System.
• Incident Response, The Site Reliability Workbook (Google), chapter 9. Case studies of incident command in practice, including handovers.
• Different Roles, PagerDuty Incident Response Documentation. An open-source role set covering incident commander, deputy, scribe, subject matter expert and liaison roles.