📣 The Communications Lead Role in Incident Response

On a small incident, one person does everything: they diagnose, they fix, and they tap out a status update between commands. On a real SEV1 — the kind with a VP in the channel and customers tweeting — that one person becomes a bottleneck. They’re either fixing or communicating, and whichever they’re doing, the other is starving.

The communications lead exists to fix that. It’s the most underrated role in incident response, and the first one teams skip. After enough 3am incidents where the fix was fast but the story was a disaster, I’ve learned: the comms lead is not optional on a major incident, and they are not the incident commander wearing a second hat.

What the comms lead is responsible for

The incident commander owns the response — the technical direction, the decisions, the “who’s doing what.” The comms lead owns the narrative, in every direction at once:

• Outward, to customers — status-page updates, the public-facing story, the cadence of “we’re aware and working on it.”
• Upward, to leadership — executive briefings that translate technical chaos into business impact without the play-by-play.
• Inward, across the org — telling support, sales, and account teams what they can say to customers asking right now.
• Sideways, into the incident channel — keeping the timeline clean so the postmortem writes itself later.

Crucially, the comms lead is a shield for the incident commander. Every “any update?” from leadership that lands on the IC is a context switch away from the fix. The comms lead intercepts those.

Why separating it from the IC matters

The instinct is “the IC knows the most, so the IC should communicate.” That’s exactly why they shouldn’t. The IC’s attention is the scarcest resource in the room. Every minute they spend writing a customer update or fielding the CEO’s DM is a minute they’re not driving resolution.

Splitting the roles also creates a healthy translation layer. The IC speaks in raw technical state. The comms lead’s job is to not leak that raw state to customers — no root-cause speculation, no internal jargon, no premature “it’s fixed.” A dedicated comms person naturally filters; an IC moonlighting as comms tends to overshare under pressure.

The comms lead’s operating loop

A good comms lead runs a tight, repeating cycle:

1. Pull current state from the IC — a 30-second sync: what’s broken, what we know, ETA confidence. Pull it; don’t make the IC push it.
2. Translate it per audience — the same facts become three different messages for customers, executives, and internal teams.
3. Publish on a predictable cadence — even “no change, still investigating” on schedule. Silence reads as “they’ve lost control,” and predictability buys you patience.
4. Repeat until resolution, then own the resolution message and the all-clear.

The discipline is in the cadence. A comms lead who posts brilliant updates erratically is worse than one who posts adequate updates like clockwork. Set the interval by severity — SEV1 might be every 30 minutes — and hit it.

What to communicate, and what to withhold

The hardest skill is knowing what not to say.

• Say: what’s affected, what the customer experiences, that you’re engaged, when the next update will come.
• Don’t say: the suspected root cause before it’s confirmed, blame toward a team or vendor, a fix ETA you can’t stand behind, or “it’s resolved” before you’ve confirmed it’s actually resolved.

That last one burns teams constantly. Declaring victory and then walking it back destroys more trust than the original outage. The comms lead is the person who says “not yet, let’s wait for the metrics to hold” while everyone else wants to post the all-clear.

A comms-lead handoff template

When the role is handed between people (long incidents, follow-the-sun coverage), pass this:

Incident: [ID / link] Current public message + where it’s posted: [link] Last update time / next scheduled update: [HH:MM / HH:MM] Cadence: every [N] min Audiences engaged: customers via [status page], leadership via [bridge/thread], internal via [channel] Tone/constraints so far: [e.g. no RCA speculation; legal reviewing customer-data wording] Open comms asks: [e.g. support needs an approved holding line]

A clean handoff means the narrative doesn’t reset every time the person changes.

When you need the role — and when you don’t

Don’t conjure a comms lead for a SEV3 that two engineers will close in ten minutes; the overhead isn’t worth it. Activate the role when:

• The incident is customer-visible and will run longer than ~30 minutes.
• Leadership or external stakeholders are watching.
• The IC is visibly being pulled away from the fix to answer questions.

Bake the trigger into your severity matrix so it’s not a judgment call mid-incident — “SEV1 activates a comms lead” should be written down, the same way SEV1 activates an IC.

Practice it before you need it

The comms lead role is a skill, and skills decay. Rotate people through it in gamedays so you have more than one person who can do it well. The worst time to discover your only competent comms lead is on vacation is during the outage.

We keep status-update, executive-brief, and internal-comms templates in our incident-response toolkit, and the AI Incident Response Assistant can draft audience-specific updates from the current incident state so the comms lead is editing instead of staring at a blank page.

AI-drafted comms are starting points. A human comms lead must review every external message for accuracy and tone before it’s published.