In the middle of a major incident, a senior leader joins the response channel and posts something like this:

“Let’s try to get this resolved in the next 10 minutes, please!”

They mean it as encouragement. Maybe they’re feeling pressure from their own leadership, or from a major customer, or both. Maybe they know the CEO is worried about a contract renewal call in an hour with a customer already frustrated with reliability. They want the team to know this incident matters. Posting a rallying message feels like leadership: it’s visible, it’s supportive in intent, and in normal day-to-day work, rallying the team really is a valuable leadership skill.

During an incident, it usually backfires.

What the responders actually hear

In nearly every incident I join, the responders are already working as fast as they feel they safely can. They don’t need to be told the incident matters; they’re the ones who got paged, who are staring at dashboards, who are juggling three competing hypotheses about what’s going on. When a leader urges that team to go faster, the message they receive isn’t “we believe in you.” It’s “you’re not working hard enough.”

And if the team is already at their limit, a call for more speed can’t add speed. It can only add anxiety. Anxiety during an incident is expensive: responders start splitting their attention between the problem in front of them and the audience watching them, and split attention is something that a complex technical investigation can’t afford. The pep talk was meant to help the team focus. It does the opposite.

The trouble with “10 minutes”

The arbitrary deadline makes it worse. Why 10 minutes? Where did that number come from? The responders don’t know. Often the leader who posted it doesn’t know either; it just sounded suitably urgent.

But now the number is sitting in the channel, and every responder is doing math against it. If the team resolves the incident in 12 minutes instead of 10, did they fail? Nobody can answer that, which means the deadline has created a test that everyone can feel and nobody can pass. Some part of each responder’s attention now goes to the clock, and to the question of how this will look to a senior leader who’ll have a big say in their next performance review. None of that attention is going to the outage anymore. The team has been handed a no-win condition in the middle of an emergency, by someone who was trying to help.

How experienced commanders convey urgency

I’ve spent a lot of time around public safety incident command, and one of the things that struck me early is what you don’t hear on the radio at a working fire: nobody broadcasts “let’s try to knock this fire down in the next 10 minutes, please!” to the crews working the fire.

What you do hear is information. “We have a report of a person trapped on the second floor” changes how the crews operate, instantly, without anyone being exhorted to care more. On the fireground, commanders convey urgency through facts and objectives, because facts and objectives change what responders do. Cheerleading doesn’t.

Even with the arbitrary number removed, “let’s wrap this up quickly, team!” is not actionable, because it doesn’t tell anyone what to do differently. It changes the mood, but probably not for the better, without changing a single decision.

Urgency is information, not exhortation

The leader’s urgency is usually genuine, and often there’s real business context behind it. That context is valuable. But it needs to be delivered as information, to the right person, through the right channel.

The right person is the incident commander (IC), the person coordinating the response. The right channel is a private one. “The CEO has a contract renewal call with our largest customer in an hour; they’re already frustrated with our reliability, and this outage isn’t going to help” is genuinely useful: the IC can prioritize mitigations that affect that customer’s services, loop in the account team, or prepare a status update the CEO can reference on the call. “Legal needs to know by end of day whether customer data was affected, so they can meet the notification deadlines in our customer contracts” is useful in the same way. The IC can act on information like that.

What to do instead

For senior leaders: when you feel that urge to rally the troops, pause and apply a simple test: can the responders use what you’re about to post to make any decision better? If so, you have real business context, and you already know where it goes: to the IC, privately. If not, it might indeed change the mood, but probably not for the better. And if the honest answer to what’s driving your urgency is “I’m anxious and I want them to know I’m paying attention,” then the most supportive thing you can do is trust the team and stay out of the channel. The most valuable contributions senior leaders make during major incidents mostly happen outside the response channel anyway: clearing roadblocks and handling the stakeholders who would otherwise be pestering the responders for updates.

For incident commanders: when one of these pep talks lands in your channel, don’t respond defensively, but don’t ignore it either. Acknowledge it briefly, then follow up with the leader privately: “Is there specific business context driving that timeline? If so, it would help me to know what it is.” Most of the time there is something behind it, and that question converts an anxiety-inducing exhortation into information you can actually use. You’ll also be quietly teaching your leadership how to engage with the next incident.

For everyone else on the response: you don’t need to respond to the pep talk, and it doesn’t change your priorities unless the IC says it does. During an incident, you take your cues from the IC, not from voices outside the response, no matter how senior. Messages like this are the IC’s to handle, and now you know how they’ll handle it.

The urgency itself was never the problem. Every incident deserves urgency. The problem is urgency delivered as pressure instead of as information, because pressure makes responders slower and more mistake-prone just when the company most needs them sharp.

---

I’m writing a book about all of this: Incident Management for DevOps and SRE. If you’d like to hear when it’s available, you can sign up at im4ds.com.

Need help preventing, preparing for, responding to, and learning from incidents? That’s the focus of my consulting practice at Great Circle.