Communication During an Incident: Cadence and Audience

Chapter 1's own bad-process example ended in "total silence for hours." This chapter is about the specific discipline that avoids it — not because silence looks bad, but because silence is itself read as information, almost always the wrong information.

Silence Reads as "Nobody Is Working on This"

The absence of an update during an active incident isn't neutral — anyone waiting interprets it, usually as neglect rather than "actively investigating something genuinely hard." "Still investigating, no new findings yet" is itself real, valuable information worth sending, even when there's nothing new to report.

Setting a Cadence, Not Just Reacting

Deciding on a regular update interval up front — every 30 minutes for a SEV1, every few hours for a SEV3, scaling with severity the same way Chapter 7's escalation timing did — avoids the awkward gap where 45 minutes pass with nothing sent purely because "there's nothing new to say yet," when that absence itself needed communicating.

Audience-Appropriate Updates

The same "know your audience" principle from Chapter 7's escalation split, now applied to ongoing updates: a technical status update for the team actively working differs from a stakeholder-facing one for people who need impact and rough timing, not technical detail.

Updating Even When the News Isn't Good

"We tried X, it didn't work, we're now trying Y" is still a genuinely useful update, despite not being good news — it demonstrates active, real progress, which maintains trust. Silence erodes trust regardless of how hard the team is actually working behind the scenes; a visible, honest update — even a discouraging one — doesn't.

The "All Clear" Message

Once resolved, an explicit "this is now resolved" message matters just as much as the original "we're investigating" one. People who were told about a problem need to be explicitly told it's over — otherwise, a real fraction of them continue operating under the assumption it might still be happening (avoiding a feature, expecting delays) longer than necessary, a real and often-overlooked gap.

Working Example: A Full Update Sequence

Notice the 14:35 update carries no good news at all — a ruled-out theory, no ETA — and it's still exactly the kind of update this chapter recommends sending, matching Chapter 5's own timeline for this same running incident. The 15:22 message is the explicit all-clear, not left implied.

Hands-On Exercises