It happens on way too many incidents. The ad hoc team of responders is deep in discussion when somebody new joins the call or the channel, and the first thing they say is: “Hey, what’s going on?”

The incident commander (IC) stops what they’re doing and recaps the timeline, the current theories, who’s working on what, and what’s been tried so far, which can easily take a few minutes. Meanwhile, the discussion and coordination stall, other responders wait (or, worse, proceed without coordination), and the IC loses their train of thought. Then fifteen minutes later someone else joins, and it happens again.

Each interruption seems small. Cumulatively, they’re one of the biggest drags on incident response that nobody talks about. And it’s not just responders. Executives, customer care reps, sales teams, and other observers who join the channel to follow along often do the same thing, without realizing how much these interruptions add up.

The problem isn’t the people

People who ask “what’s going on?” aren’t being lazy or inconsiderate. They’re doing what feels natural: they’ve been pulled into an unfamiliar situation, they don’t know what’s happening, and they turn to the person in charge for orientation. It’s a reasonable instinct.

But it’s also an expensive one. The incident commander is typically the busiest person in the response. They’re tracking multiple threads of investigation, coordinating assignments, communicating with stakeholders, and maintaining the big picture. Every time they stop to deliver a verbal briefing, all of that pauses. And because each new arrival gets a slightly different recap depending on when they ask and what the IC remembers to mention, the team can end up with inconsistent pictures of the situation.

A new arrival who doesn’t know what’s going on has three options, none of them good. They can interrupt the IC for a recap, which is disruptive. They can wait until someone has time to bring them up to speed, which delays whatever they’re there to do. Or they can start acting on incomplete information.

There’s a better alternative: self-briefing. It’s one of the simplest, highest-impact changes a team can make to their incident response, though it does require laying some groundwork.

What self-briefing looks like

Self-briefing means that when you join an incident in progress, you orient yourself rather than interrupting to ask someone else to orient you. For observers following along from the exec team or customer care, this can be completely silent: read the channel, read the latest situation report (sitrep), and you’re up to speed without anyone even knowing you arrived. For responders, a two-message pattern lets other responders know you’re there and coming up to speed, with minimal disruption.

Message one, on arrival: “Hi, I’m Jordan from the caching team. Reading back through the channel now.”

This tells the IC and the rest of the team several important things: you’re here, you have potentially relevant expertise, and you’re getting yourself up to speed rather than asking them to stop and brief you.

Then you actually do the reading. Scroll back through the incident channel. Read the most recent sitrep, if one has been posted. Check the status document if there is one. Note who’s involved and what they’re working on. This typically only takes a few minutes, depending on how long the incident has been running and how much has happened.

Message two, when you’ve briefed yourself: “Jordan from caching, caught up. I’ve read the channel and the latest sitrep. It looks like nobody is currently investigating the CDN layer. Want me to start looking there, or is there something else that would be more useful?”

Now your first real interaction with the IC is useful rather than disruptive. You’ve demonstrated that you understand the current situation. You’ve identified a potential gap. And you’ve offered a specific proposal for what you could work on, which is much easier for a busy IC to respond to than an open-ended “what do you need?”

Why this only works with text channels

Self-briefing depends on text channels. It works well in Slack (or a similar channel-oriented text tool), but isn’t feasible in Zoom (or any voice/video-first approach).

In Slack, the incident channel gives a new arrival something powerful: control over their own depth. You can skim the last twenty messages for a quick sense of where things stand, then slow down and dig into the thread about cache hit rates because that’s your area and the detail matters to you specifically. You can click the dashboard link someone shared and look at the graph yourself. You can see who said what, which tells you who’s working on what and who to direct your follow-up questions to. You can reread a confusing message until it clicks. You can forward a specific message to a colleague and ask “what does this mean?” or “this seems critical for your team.”

With Slack, a few minutes of reading lets you go shallow for orientation and deep where your expertise is relevant, all in the same pass.

In a Zoom call, that context evaporates the moment the words are spoken. You can’t rewind a conversation. When a new responder joins a call that’s been running for forty-five minutes, those forty-five minutes of discussion are gone. And it’s not just the words. Every graph someone screen-shared, every dashboard someone walked through, every log snippet someone pasted into the Zoom chat (which late joiners also can’t see) is gone too.

With Zoom, the only option is exactly what we’re trying to avoid: asking someone to stop and recap.

“But what about transcripts?” Even if your video conferencing tool offers AI-generated “catch me up” summaries for late joiners, those give you the shallow orientation pass and nothing else. They can’t show you the graphs and dashboards people were discussing while screen-sharing. They struggle with the names of people, systems, and services that fill every incident conversation. And they don’t let you drill into the specific thread that matters most to a person with your particular expertise. An AI summary might tell you the team is investigating a caching issue. It won’t let you read the actual exchange between the two engineers who narrowed it down, click through to the dashboard they were looking at, and decide for yourself whether they’ve checked the CDN layer yet.

Some teams start out with the best of intentions, keeping the Slack channel updated alongside the Zoom call. In practice, it works for a little while, and then the person doing the updating gets drawn into the verbal conversation and stops scribing. Critical information, discoveries, and decisions never make it into text. The Slack channel becomes a sparse, incomplete shadow of what’s actually happening on the call.

This isn’t a minor inconvenience. It’s a structural barrier to self-briefing. If your primary incident communication happens on a voice call, you’ve made it physically impossible for new arrivals to orient themselves without interrupting someone. You’ve baked the “what’s going on?” problem into your communication architecture.

Periodic situation reports posted on a regular cadence by the incident commander help bridge this gap, because a good sitrep gives a new arrival a snapshot of the current state regardless of what communication tool the team is using. But sitreps are periodic summaries. They can’t let you explore the details that matter for your specific expertise. A team that communicates primarily in text gets both: the running record you can explore at your own depth in the channel, and the periodic snapshot in the sitrep.

Make it an organizational expectation

Self-briefing sounds simple, and it is. But it won’t happen consistently unless the organization establishes it as an explicit expectation, not just a nice idea. This means a few things.

Teach the pattern. Include self-briefing in your incident response training. Teach responders the two-message template. Explain why it matters. Most people will adopt it readily once they understand the reasoning; they just need to know it’s expected.

Lay the groundwork. Self-briefing depends on having something to brief yourself from. That means using a text channel as your primary communication tool during incidents, posting regular sitreps, and maintaining a status document on longer incidents. If your team’s incident communication happens mainly on a Zoom call with a neglected Slack channel on the side, there’s nothing for a new arrival to self-brief from. The expectation and the groundwork go hand in hand: each one reinforces the other.

Reinforce it from the IC role. When a new responder joins and immediately asks “what’s going on?”, the IC can gently redirect: “Welcome! Take a few minutes to read back through the channel and check the latest sitrep, then let me know what questions you have.” A few consistent redirections establish the norm quickly.

Model it yourself. When you join an incident as a responder, follow the two-message pattern even if you could get a faster verbal briefing. Especially if you’re senior. When a staff engineer or a VP visibly self-briefs rather than expecting a personal recap, it sends a powerful signal about how things work here.

The compounding benefit

Self-briefing doesn’t just help the person who arrives prepared. It helps everyone.

The IC stays focused on managing the response instead of delivering repeated briefings. The investigation maintains momentum because nobody is hitting pause to catch up new arrivals. The existing responders don’t lose context from their own work while waiting for the IC to finish briefing someone else. Observers from customer care or the exec team can follow along and update their own stakeholders without pulling anyone away from the response. And the new responder starts contributing faster, because five minutes of reading usually builds better context than a rushed verbal summary anyway.

Over the course of a large incident where a dozen people join at different times, the difference between “everyone self-briefs” and “everyone asks the IC for a recap” can easily be an hour of the IC’s time, and several hours of cumulative disruption to the response.

The technique is simple, but the impact is significant. For observers, self-briefing is invisible: just read the channel and the latest sitrep. For responders, it takes two messages and a few minutes of reading. Nobody gets interrupted. Nothing stalls. And the response keeps its momentum.

---

Self-briefing is one of the practices I cover in my forthcoming book, “Incident Management for DevOps and SRE.” If you’d like to hear when it’s available, sign up at im4ds.com. And if your organization needs help building effective incident management practices right now, my consulting practice is greatcircle.com/im.