Most developers prepare for production incidents technically.

They know how to roll back a deployment. They understand the monitoring tools. They have runbooks and playbooks and documented procedures.

What almost nobody prepares for is what to communicate — and when — while the technical work is happening.

That gap is where most incidents become significantly worse than they need to be.

Two developers. One Friday. The same failure.

It is 4:47pm. The release went out thirty minutes ago. Production is down.

Both developers know exactly how to fix it technically.

Here is what they do differently.

The junior developer's response:

Twenty minutes of silence on Slack. Multiple undocumented changes made simultaneously. Then one message:

"Sorry, I'm not sure what happened, I was trying to fix it but I think I maybe made it worse, I'm not sure what to do, can someone help?"

Every hedge in that message — "I'm not sure," "I think maybe," "I'm not sure what to do" — signals to the entire team that the person handling the incident does not have it handled.

The team stops their own work. Decision-making fragments. The incident takes three hours.

The senior developer's response:

One Slack message within ninety seconds:

"Production is down. I'm on it. I'll update every 10 minutes until resolved. Current hypothesis: deployment config. Rolling back now."

Followed by three update messages at minutes ten, twenty, and twenty-three.

The team continues their own work. One person owns the incident. It resolves in twenty-three minutes.

Why the difference is not technical

The junior developer's silence created a second incident running in parallel — team anxiety. Every minute without information amplified that anxiety and pulled people away from their work to fill the vacuum.

The senior developer's message did the opposite. It established ownership, committed to a communication rhythm, demonstrated structured thinking, and announced a clear action. Twelve words that contained the incident to one person and one process.

Technical skill was identical. Communication skill was not.

The five-move formula

Every effective incident communication follows the same five moves in the same order.

Move 1 — Name it immediately State the severity directly in the first message. "Production is down" — not "something seems off" or "there might be an issue." Hedging the severity wastes the first ninety seconds when clarity matters most.

Move 2 — Own it "I'm on it." Two words that transfer the team's anxiety to one person who is handling it. This ends the scramble for ownership and allows everyone else to continue their work.

Move 3 — Contain it "I'll update every 10 minutes until resolved." Committing to a communication rhythm removes the team's need to ask for updates. Every question they do not need to ask is focus they keep on their own work. This is the move most developers never make — and the one that makes the largest difference to the team's experience of the incident.

Move 4 — Hypothesize "Current hypothesis: [X]." The word hypothesis signals structured scientific thinking rather than panicked randomness. It also opens the door for others to contribute relevant information without turning the response into a committee.

Move 5 — Act "Rolling back now." One decision. Stated clearly. Executed immediately. No committee. No hesitation. No qualifier. This is the sentence that moves the incident from diagnosis to resolution.

These five moves take approximately forty words and ninety seconds to send.

The template

Write this now and keep it somewhere accessible — a phone note, a pinned Slack message, a document on your desktop:

"[System] is down. I'm on it. I'll update every 10 minutes until resolved. Current hypothesis: [X]. [Action] now."

Fill in the brackets when the moment comes. The template removes the blank-page panic that causes twenty minutes of silence. The words exist. You just need to send them.

What managers see during incidents

Panic is contagious. So is calm.

Technical skill is assumed — managers already know you have it. What an incident reveals is something different: whether you can be trusted with more responsibility. With a bigger system, a bigger team, a more consequential failure.

Communicate clearly under pressure once. They will not forget it.

The developer who handles a Friday afternoon incident with composure and clear communication is the developer who gets promoted when everything is working normally.

The formula above is forty words. The career impact is not.

Want one framework like this every Monday?

Senior Dev English delivers one practical communication strategy for non-native software developers every week — built for standups, code reviews, salary conversations, and every high-stakes moment that moves careers.

Free to subscribe. Includes an instant download of The Senior Dev Communication Cheat Sheet.

→ Subscribe free at SeniorDevEnglish.com

This article was originally published in Senior Dev English — a weekly newsletter for non-native software developers who want to communicate with the confidence their code already deserves.

​
​