Incident Response Roles: Commander, Scribe, Comms, and Ops

The difference between an incident that feels controlled and one that feels like a mob is almost always role clarity. In the controlled version, everyone knows what they’re responsible for and, just as importantly, what they’re not. In the mob version, ten people are all half-debugging, nobody’s writing anything down, a stakeholder’s question sits unanswered for fifteen minutes, and two engineers are unknowingly working the same fix. The work isn’t the problem. The lack of assigned lanes is.

There are four core roles that, between them, cover everything a major incident needs: Incident Commander, Scribe, Communications, and Operations. This is who owns what, how the roles relate, and — crucially — how they collapse down sensibly when you don’t have four people to spare. Get the boundaries right and even a big, ugly incident stays coordinated.

The four roles at a glance

ROLE            OWNS                          DOES NOT
--------------  ----------------------------  ---------------------
Incident        Coordination. The picture,    Fix the system.
Commander (IC)  severity, decisions, who       (Hands off keyboard.)
                does what.

Operations      The investigation and the     Coordinate the whole
(Ops / SME)     fix. Hands on the system.     response or manage
                                              stakeholders.

Communications  Status page, stakeholder &    Make technical
(Comms)         exec updates, cadence.        decisions.

Scribe          The timeline. Timestamped     Debug or decide.
                record of events, decisions,
                actions.

The magic is in the “does not” column. Each role is defined as much by what it stays out of as what it owns. That’s what prevents overlap and keeps five people from all doing the coordinator’s job badly.

Incident Commander: coordinates, doesn’t fix

The IC owns the response, not the repair. They hold the single source of truth on what’s happening, assign clear ownership for each workstream, decide severity and escalation, and keep communication flowing. The defining discipline of the role is that the IC does not put their hands on the keyboard to fix the system. The moment they start debugging, coordination stops — and coordination is the one thing only the IC is doing.

This trips up senior engineers hardest, because they’re often the best debugger in the room and have to deliberately not debug. Their value as IC — keeping the whole response coordinated — is worth more than their individual fix.

Operations: the ones actually fixing it

Ops (or subject-matter experts) do the real work: investigating, forming and testing hypotheses, and applying mitigations and fixes. They report findings up to the IC and take direction on priorities. Their job is depth — go deep on the technical problem — which is exactly why they can’t also be tracking stakeholders and severity. Protecting their focus is one of the IC’s main jobs. When Ops surfaces “connection pool exhaustion, testing a fix,” the IC folds that into the picture; Ops stays heads-down.

Communications: the outward face

Comms owns every message that leaves the response — status-page updates, internal stakeholder notes, executive summaries — each in the right register for its audience, on a predictable cadence. This role exists to free the IC and Ops from context-switching into writing. A dedicated comms owner is the single biggest upgrade most teams can make past a small incident, because it lets the IC command and Ops fix without either of them freezing in front of a status-page box. Comms doesn’t make technical calls; they translate the response outward.

Scribe: the memory of the incident

The Scribe keeps a running, timestamped timeline — observations, decisions, actions, handoffs — while everyone else is loaded. They don’t debug and don’t decide; their detachment is the feature. The payoff is double: during the incident, the timeline gives the IC an at-a-glance current state, and after it, the postmortem inherits an accurate record instead of a reconstruction from fuzzy memory and scrollback.

A RACI for a typical major incident

Who’s Responsible, Accountable, Consulted, Informed for the common incident activities:

ACTIVITY               IC    Ops   Comms  Scribe
---------------------  ----  ----  -----  ------
Set/change severity    A/R    C      I      I
Investigate & fix       C    A/R     I      I
Assign workstreams     A/R    I      I      I
Customer/status comms   A     I    A/R      I
Exec/stakeholder comms  A     I    A/R      I
Keep the timeline       I     I      I     A/R
Decide to escalate     A/R    C      C      I
Declare resolution     A/R    C      C      I

The point of writing it down isn’t bureaucracy — it’s that during the incident, nobody wastes a second wondering “whose call is this?” The severity change is the IC’s; the status page is Comms’; the timeline is the Scribe’s. Decided in advance, it just runs.

How the roles collapse on small teams

Most incidents don’t have four spare people, and that’s fine — the roles are responsibilities, not required headcount. They collapse sensibly:

Two people: one is IC + Comms + Scribe (coordinate, communicate, keep notes), the other is Ops (fix it). The critical boundary to preserve is that the person fixing is not also trying to coordinate and communicate.
One person: you wear all hats, but separate them in time. Spend the first two minutes as IC — assess, set severity, post one comms update, set a cadence — then drop into Ops, and resurface on a timer to re-coordinate and re-communicate. Set an actual alarm so the fixing doesn’t swallow the coordinating.

The rule that survives all the way down: the person elbow-deep in the fix should never be the only one holding coordination, because a heads-down debugger can’t also keep the picture. Even solo, you separate the jobs by switching between them deliberately.

Common role mistakes

The IC becomes the fixer. The number-one failure. Coordination silently stops. Keep the IC off the keyboard.
No named scribe. The timeline gets “reconstructed later,” which means inaccurately. Assign someone not on the critical path.
Comms as an afterthought. The IC writes every message and falls behind. Split comms off early.
Roles that don’t collapse. Insisting on four people for a two-person incident, or refusing to name roles at all on a small one. Scale the roles to the incident.
Unclear decision rights. Nobody knows who can change severity or call resolution. The RACI settles it in advance.

Where AI supports the roles

AI slots in most naturally alongside the Scribe and Comms roles — the synthesis-and-drafting work. A model in the incident channel can maintain the running current-state summary (a force multiplier for the Scribe or a solo IC) and draft the audience-tuned comms for a human to send. Keep it firmly in the passenger seat: it synthesizes and drafts; humans hold every role’s actual decisions and never let it touch production. It’s especially valuable when the roles have collapsed onto one or two people, because it carries the notes and the picture so the humans can do the parts only humans can. The Incident Response tool can maintain that live current-state view and produce comms drafts.

Wrapping up

Four roles cover a major incident: the Commander coordinates, Ops fixes, Comms communicates, and the Scribe records — each defined as much by what it stays out of as what it owns. Write down who owns which decisions so the response never stalls on “whose call is this?”, and let the roles collapse gracefully onto however many people you actually have, always keeping the fixer out of the sole coordination seat. Clear lanes are what turn a mob into a response.

AI assistance supports the scribe and comms work as drafts for humans to verify. People own every role’s decisions.