Skip to content

Apply review feedback to the 4 R's of incident communication rule #13103

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tomek-i wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Apply review feedback to the 4 R's of incident communication rule #13103

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 27 additions & 35 deletions public/uploads/rules/communicate-during-an-incident/rule.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
type: rule
title: Incidents - Do you know the 4 R's of incident communication?
title: Do you know the 4 R's of incident communication?
uri: communicate-during-an-incident
authors:
- title: Tom Iwainski
Expand All @@ -22,20 +22,16 @@ isArchived: false
archivedreason: null
---

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.
Sooner or later something will go badly wrong. A server dies, the product breaks in production, 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.
This rule applies when **someone reaches out about a critical issue**. They may sound stressed or upset, which is fair. The severity is set by the impact on them, not by how hard the fix looks 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.
<endIntro />

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.

<endIntro />

<boxEmbed
style="info"
body={<>
Expand All @@ -51,7 +47,7 @@ Most incidents go pear-shaped for one reason. It is rarely that the fix took too

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**
#### 📞 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.

Expand All @@ -68,16 +64,16 @@ Send one quick line so they know the message has landed, then call.

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 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.
* **Name someone who might know** - a maybe is far more useful than nothing
* **Split the chasing** - offer to call one person while they try another
* **Say what you can still do** - you might not be able to debug it, but you can check the monitoring from your phone
* **Come back either way** - report back once you have tried, even if you got nowhere

<boxEmbed
style="greybox"
Expand All @@ -90,13 +86,13 @@ Even when you are the wrong person, you can still move things forward:

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

**🙏 Use the 3 A's**
#### 🙏 Use the 3 A's

Follow [Communication - Do you know the 3 A's for receiving feedback/criticism?](/how-to-take-feedback-or-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"*
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.

Expand All @@ -118,7 +114,7 @@ Acknowledging is not just confirming the facts. Agree that it is a problem and t
figure="Agrees it is bad, so the person knows you are taking it as seriously as they are"
/>

**⏰ Be specific about your availability**
#### ⏰ 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.

Expand Down Expand Up @@ -151,7 +147,7 @@ Never leave someone guessing when you will be back. A vague answer forces the st

### 2. Reinforce - don't go solo

**👥 Bring in a second person early**
#### 👥 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.

Expand All @@ -170,7 +166,7 @@ A second person becomes a shield. They absorb the questions, keep everyone infor

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**
#### 🚨 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.

Expand All @@ -185,7 +181,7 @@ It is always better to involve people too early than to sit blocked. Every quiet

### 3. Report - while you work

**🔄 Give regular status updates, even when there is no progress**
#### 🔄 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.

Expand All @@ -200,7 +196,7 @@ If you need a longer block of time to investigate, say so upfront so nobody is l
figure="Sets expectations for a quiet period, so silence doesn't get read as neglect"
/>

**🔓 Surface blockers loudly**
#### 🔓 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.

Expand All @@ -213,7 +209,7 @@ If you are waiting on another person, chase them actively. Call, message, use wh
figure="Shows the chase is active and timeboxed, not a passive wait"
/>

**🔥 Never downplay the urgency**
#### 🔥 Never downplay the urgency

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

Expand All @@ -237,23 +233,19 @@ A statement that pushes the problem into the future tells the stakeholder you ha

### 4. Resolve - and follow through

**📌 Make the incident the highest priority on the next business day**
#### 📌 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"
3. Start the investigation immediately, rather than letting it drift into "we'll look next sprint"

## 🎯 Cheatsheet
<hr />

* **Respond** - "Seen it, calling you now", then call. Acknowledge, apologize, act
* **Reinforce** - get a second person in early. One person fixes, one person talks
## Summary

* **Respond** - send "Seen it, calling you now", then call and use the 3 A's
* **Reinforce** - get a second person in early so one person fixes and 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.
2 changes: 1 addition & 1 deletion public/uploads/rules/unplanned-outage-process/rule.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ During your course of being a SysAdmin, you will come across many unplanned outa
body={<>
For planned outages, see [Outage - Do you have a planned outage process?](/planned-outage-process)

For how to communicate with stakeholders while the outage is live, see [Incidents - Do you know the 4 R's of incident communication?](/communicate-during-an-incident)
For how to communicate with stakeholders while the outage is live, see [Do you know the 4 R's of incident communication?](/communicate-during-an-incident)
</>}
figurePrefix="none"
figure=""
Expand Down
Loading