Incidents - Do you know the 4 R's of incident communication?

Sooner or later something will go badly wrong. A server dies, the product breaks in production, customer data goes missing, or a release takes the site down.

The technical fix is only half the job. The other half is communication, and that is usually the half that damages the relationship.

You know this rule applies when someone reaches out about a critical issue. It might be the CEO, a client, or a Product Owner. Something they rely on is broken, and they are looking to you.

They may sound stressed, frustrated, or upset. That is a fair reaction when something important is broken, so take it as a signal of how much this matters to them.

The severity is set by the impact on them. It is not set by how hard the fix looks to you, so don't spend time deciding whether it really counts. If it is urgent to them, treat it as urgent.

Most incidents go pear-shaped for one reason. It is rarely that the fix took too long. It is that the person who raised it was left wondering whether anyone cared.

The 4 R's: Respond, Reinforce, Report, Resolve

1. Respond - as soon as you see it

If your team has an on-call roster or agreed response times, follow those. Otherwise, the clock starts when you see it. Once the message is in front of you, act on it straight away rather than reading it and coming back to it later.

📞 Call, don't chat

Chat is the wrong tool for an incident. It is slow, it is easy to misread, and a long back and forth reads as a lack of urgency.

Send one quick line so they know the message has landed, then call.

✅ Figure: Good example - Takes 2 seconds, and it stops them chasing other people while your phone is ringing

Pick up the phone even if you are nowhere near your computer. You can often still help verbally.

🤝 If you can't help, still point the way

If you truly can't help, say so straight away so nobody is left waiting on you. Then keep going. "Sorry, I can't help" on its own leaves the person exactly where they started, and it reads as though you have handed the problem back.

Even when you are the wrong person, you can still move things forward:

• Name someone who might know, even if you are not certain. A maybe is far more useful than nothing.
• Split the chasing. Offer to call one person while they try another. It halves the time and shows you are in this with them.
• Say what you can still do. Perhaps you can't debug it, but you can check the monitoring on your phone or find a phone number for them.
• Come back either way. Tell them you will report back once you have tried, even if the answer is that you got nowhere.

✅ Figure: Good example - Wrong person, but still helpful. It gives a name to try, takes on part of the chasing, and promises to come back

This costs you very little, and it is the difference between the stakeholder feeling passed over and feeling helped.

🙏 Use the 3 A's

Follow Communication - Do you know the 3 A's for receiving feedback/criticism?:

1. Acknowledge the issue. "Yes, the site is down, I can see it too. That's a problem."
2. Apologize for the impact. "Sorry, I know this is affecting the demo tomorrow"
3. Act by saying what you are doing next. "I'm heading home now and will be online in 30 minutes"

Acknowledging is not just confirming the facts. Agree that it is a problem and that it is bad. The person needs to hear that you are on the same side of it, not that you have simply logged what they said.

❌ Figure: Bad example - Confirms the facts but says nothing about whether it matters, so it reads as detached

✅ Figure: Good example - Agrees it is bad, so the person knows you are taking it as seriously as they are

⏰ Be specific about your availability

Never leave someone guessing when you will be back. A vague answer forces the stakeholder to either wait and hope, or chase you.

❌ Figure: Bad example - Vague. There is no timeframe and no fallback, so the stakeholder can't tell whether to wait or escalate

✅ Figure: Good example - Specific. The stakeholder knows exactly when to expect the next update

✅ Figure: Good example - Pairs a clear timeframe with a name to try, so the gap in your availability doesn't stall the incident

2. Reinforce - don't go solo

👥 Bring in a second person early

A second person is not a luxury during an incident. They halve the stress. They spot the thing you are staring straight past. Best of all, one of you can keep the stakeholder informed while the other investigates.

That split protects the person doing the fixing. Troubleshooting needs concentration, and a constant stream of "any update?" calls and messages breaks it every few minutes. Losing your place in a set of debugging steps is frustrating, and it makes the fix take longer.

A second person becomes a shield. They absorb the questions, keep everyone informed, and let you work uninterrupted. Just make sure the stakeholder knows who to contact so they aren't left guessing.

✅ Figure: Good example - Everyone knows who to talk to, so the person fixing it gets a clear run

Call someone from the team if you can. If nobody from the team is free, grab any co-worker who is.

🚨 Escalate early if progress has stalled

It is always better to involve people too early than to sit blocked. Every quiet minute burns the stakeholder's confidence. Escalate as soon as you hit a dead end, and tell the stakeholder you are doing it.

✅ Figure: Good example - The blocker, the person who can unblock it, and the fallback, all in one message

3. Report - while you work

🔄 Give regular status updates, even when there is no progress

Silence is the single biggest cause of "they don't care about this". Short updates every 15-30 minutes keep everyone calm during a major incident.

If you need a longer block of time to investigate, say so upfront so nobody is left waiting.

✅ Figure: Good example - Sets expectations for a quiet period, so silence doesn't get read as neglect

🔓 Surface blockers loudly

If you are waiting on another person, chase them actively. Call, message, use whatever works. If you still can't reach them, don't go quiet. Tell everyone that you tried, what is blocking you, and what happens next.

✅ Figure: Good example - Shows the chase is active and timeboxed, not a passive wait

🔥 Never downplay the urgency

A statement that pushes the problem into the future tells the stakeholder you have mentally clocked off.

❌ Figure: Bad example - Signals the incident isn't urgent to you, even when it is critical to them

✅ Figure: Good example - Explains what is happening right now and what the next option is

4. Resolve - and follow through

📌 Make the incident the highest priority on the next business day

An incident over a weekend is not over when the service comes back up. On the next business day:

1. Make it the team's top priority, above whatever was already planned
2. Brief everyone who was not around during the incident, especially anyone who was off
3. Start the investigation immediately. Don't let it drift into "we'll look next sprint"

🎯 Cheatsheet

• Respond - "Seen it, calling you now", then call. Acknowledge, apologize, act
• Reinforce - get a second person in early. One person fixes, one person talks
• Report - an update every 15 to 30 minutes, even when there is nothing new to say
• Resolve - make it the top priority on the next business day

💡 Final word

Nobody can see you working. From the outside, an hour of careful troubleshooting looks exactly the same as an hour of doing nothing.

The fix earns you the outcome. The updates earn you the trust.