A Fire is Not an Emergency for the Fire Department

Good leadership is remaining calm and steady while everything crashes around you.

Yesterday (Oct 20, 2025), AWS had a major incident. A lot of companies had a really bad day.

I’ve been chatting with friends at impacted companies and a few had similar stories. Their teams were calm while their execs were not. There was a lot of “DO SOMETHING!” or “WHY AREN’T YOU FREAKING OUT?!”

Incidents happen, but panic doesn’t do anything to solve them. Fires aren’t emergencies for the fire department and incidents shouldn’t be for engineering responders either.

In this case, very little was likely in their control. For all but the most trivial of systems, you’re not going to migrate off of AWS in the middle of an incident and expect a good outcome. But the principle stands: the worst thing you can do is freak out, especially when the incident is self-inflicted. Calm leadership is going to be better than panic every time.

Calm Leadership is True Leadership

Imagine you lit your stove on fire and called the fire department to put it out. Which of these two responses would you prefer after the fire chief hops out of the truck:

• [Screaming] “Oh dear! A fire! Somebody get the hose! Agggh!”
• “We see the problem, we know how to deal with it, we’ll handle it and give you an update as soon as we can.”

I’m sure the first response would have you questioning who hired this person to be the fire chief and would not give you a lot of confidence that your whole house wasn’t going to burn down.

Similarly, the second response might let you be able to exhale and leave things to the professionals.

Why Calm Matters More in Big Incidents

Like fires, not all incidents are created equally. A pan on fire on the stove is much more routine than a large wildfire threatening a major city. I would argue the need for calm leadership gets MORE important the bigger the impact of the incident. A small incident might not attract much attention, while a big incident certainly will. In yesterday’s AWS incident it would most definitely not be reassuring to see whoever was in charge of the response making an announcement about how bad it was and how they were on the verge of a panic attack. Same goes for wildfires, and same goes for your incidents.

When you’re in a leadership position during an incident, it serves no useful purpose to yell and scream or jump up and down or tear your hair out.

Your responders want normal operations to be restored as much as you do, especially if it’s off-hours and they’ve had their free time or sleep interrupted. Shouting isn’t going to make them solve the problems any faster.

Managing the Emotional Blast Radius

Now and then someone else will react negatively to someone in the Incident Commander or the engineering management seat behaving in a calm and collected way during an incident. Usually it’s someone who is in the position to get yelled at by a customer, like an account rep or a non-technical executive. They’re under a lot of pressure because incidents can cost your customers money, can result in churn or lost sales opportunities, and all of those things can affect the bottom line or career prospects of people who have no control over the actual technical issue.

So they’re stressed about a lot of factors that are not the incident per se, but might be downstream consequences of it, much in the same way you would be after setting your kitchen on fire.

Sometimes this comes out as anger or frustration that you, the technology person responsible for this, are not similarly stressed. This is understandable. Keep in mind too that to them, they are utterly dependent on you and the tech team in this moment. They don’t know how to fix whatever’s broken, but they’re still going to hear about it from customers and prospects who might not be nice about it. This can cause a feeling of powerlessness that results in expressions of frustration.

This is not a reason to change your demeanour. The best thing you can do is keep the updates flowing, even if there’s no new news. People find reassurance in knowing the team is still working the problem. Keep the stakeholder updates jargon-free and high-level. Show empathy that you understand the customer impact and the potential consequences of that, but reassure them that the focus right now is restoring normal operations and, if appropriate, you’ll be available to talk through what happened after the dust settles.

Updates Calm Nerves

A negative reaction to the calm approach is usually born out of a fear that ‘nothing is happening’. The truth is often a big part of incident response is waiting. Without the technical context to understand what’s really going on, some people just want to see something happening to reassure themselves. You can mitigate this with updates:

• Here’s what we’ve done.
• Here’s what we’re doing (or waiting on the results of).
• Here’s what we’ll likely do next.

Use your tools to broadcast this as often as you can and you’ll tamp down on a lot of that anxiety.

The Responders Are Already Stressed, Don’t Make It Worse

Big cloud provider incidents are fairly rare. Self-inflicted incidents are not. The responders trying to fix a self-inflicted problem are very likely to be the ones who took an action that caused or contributed to the outage. Even in a healthy, blameless culture this is going to cause some stress and shame, and in a blameful, scapegoating culture it’s going to be incredibly difficult.

Having their manager, manager’s manager, or department head freaking out is only going to compound the problem.

Highly stressed people can’t think straight and make mistakes. Set a tone of calm, methodical response and you’ll get out from under the problem a lot faster.

Keep Stakeholders Off the Call, Have a Separate Channel for Updates

This might be culturally hard to achieve if you have very hands-on execs who want to be very involved, even when their involvement is counterproductive (hint: they don’t see it that way even if you do). But to the extent you can, have one communication channel for the responders and a separate one for updates for stakeholders. Mixing the two just distracts the responders and lengthens the time-to-resolution.

The key to this being successful is not neglecting the updates. I recommend using a timer and giving an update every 10 minutes whether there’s news or not. People will appreciate it and your responders can focus on responding.

Building a Culture of Calm, Professional Response

I don’t want this to be a “how to run a good incident” post. There are plenty of comprehensive materials out there that do a better job than I would here. I do want to focus on how to be a good leader in the context of incidents. Like many things, it comes down to culture and practice.

Firefighters train to stay calm when responding to fires. They’re methodical and follow well-known good practices.

To make this as easy as possible on yourself:

• Set a good example when you’re in the incident commander seat (whether in an official or ad-hoc capacity).
• Run practice incidents where the stakes are low.
• Build up runbooks and checklists to make response activities automatic.
• Define your response process and roles.
• Define your communication channels so everyone knows where to find updates.

If you can, work “fires aren’t emergencies for the fire department” into your company lexicon and remind people that in the context of incidents, the engineering team are the fire department.

"Wildfire" by USFWS/Southeast is marked with Public Domain Mark 1.0 .