Name three jobs at the start of every incident: a lead who decides, a scribe who records, and a communicator who talks to customers. Everyone else fixes things. One person can hold two roles on a tiny team, but never lead and fixer at once for long.
Why roles help
Without roles, everyone investigates, nobody records, and customers hear nothing. Decisions get made in side conversations. After the incident, nobody can reconstruct what happened or in what order, which makes the review thin.
The roles
Incident lead. Owns decisions and priorities. Asks questions, assigns work, calls the failover or rollback, and decides when to escalate. The lead does not type commands, because the moment they dive into debugging, nobody is steering. On a small team, the lead may be the most senior person available, not necessarily the most technical.
Scribe. Keeps a timeline in a shared document: times, observations, decisions, commands run. This is the raw material for the postmortem. Google's SRE guidance describes a postmortem as a written record of the incident, its impact, the actions taken, the root causes and follow up actions, and collecting key data during the event makes that possible.
Communicator. Writes customer and internal updates, using templates, on the rhythm agreed. See customer updates during an outage. Gets facts from the lead, not from raw chat.
Fixers. Engineers working on the problem. Each has a clear task and reports back to the lead, not to each other in many threads.
Optional: subject expert. Someone who knows a particular system, called in on request rather than joining everything.
Starting an incident
- Open a dedicated channel or call.
- Announce roles by name: "I am lead, Sam is scribe, Priya is communicator."
- State the problem in one sentence and the current priority.
- Set a check in time, such as every 15 minutes, for the lead to summarize.
Making decisions
Use a simple rule: the lead decides after hearing the options, and objections are voiced before the decision, not after. When two people disagree about a risky action, the lead picks, and the scribe records the reasoning. This avoids long debates while the outage continues.
Handoffs on long incidents
Tired people make mistakes. If an incident passes a few hours, rotate the lead and fixers. A good handoff covers: current state, what has been tried, what is being tried, open decisions, who is doing what, and the next update time. The scribe's timeline makes this easy. The outgoing lead stays reachable for a short period.
Fit the roles to your size
- Two people: one leads and communicates, one fixes. Scribe by chat log.
- Three to five: lead, fixer, communicator and scribe split, with the scribe doubling as fixer if needed.
- Larger: add subject experts and a separate security contact when an attack is possible.
Practice
Run the roles in a tabletop exercise. The guide to running a tabletop shows a short format. After each real incident, ask whether the roles helped and adjust.
Escalation
Write down who to wake up for what: security contact, legal contact, executive sponsor, key vendor contacts. Keep the list somewhere that does not depend on the systems that might be down.
Quick check
Can the lead also fix the problem?
Briefly, in a very small team. But the lead role suffers when they go deep into debugging, so hand the lead role to someone else if you can.
Why have a scribe?
A running timeline makes handoffs smooth and the postmortem accurate. Memory after a long night is unreliable.
Sources
Last reviewed: 19 October 2026.
