The Best Engineering Leaders I’ve Seen All Have One Thing in Common: They’re Calm When Everything…
There’s a moment in every engineer’s career when the pager goes off, and the world feels like it’s ending. The dashboard is a wall of red…
The Best Engineering Leaders I’ve Seen All Have One Thing in Common: They’re Calm When Everything Is on Fire
American Visionary Art Museum, Baltimore, Maryland
There’s a moment in every engineer’s career when the pager goes off, and the world feels like it’s ending. The dashboard is a wall of red. Slack is exploding. Someone just typed “all users affected” in the incident channel. And in that moment, the person running the call sets the tone for everything that follows.
The best engineering leaders I’ve worked with stay calm. They keep their voices steady, avoid blaming others, and don’t bombard the team with questions. Instead, they become quiet, focused, and deliberate. Somehow, that calm spreads to everyone else.
The Night the Game Went Dark
I learned this lesson firsthand. We had a function that relied on a third-party call before loading user data for a game. It seemed simple enough in theory, but then that third-party call failed, and we had no fallback, and we didn’t fail open. To make matters worse, when it failed, it wasn’t just for some users or one region, but for everyone around the world.
The game was bricked. Completely unplayable as it was unable to start. Millions of players were hitting the same wall. The incident channel filled up fast. Engineers, product managers, executives, support leads, everyone wanted answers.
And then our senior manager joined the call.
There was no drama and no “how did this happen?” interrogation. Instead, our manager spoke in a steady voice: “Okay. Who’s confirmed the root cause? What’s the blast radius? What are our options to restore service?”
Within minutes, we went from a room full of panic to a team following a plan. That manager wasn’t the most technical person on the call, but that didn’t matter. What mattered was their ability to keep everyone focused and steady, even when things felt chaotic.
We got the game back up. And I never forgot how that felt.
Why Calm Leadership Matters in Incidents
High-severity incidents are intense. The technical problem is only half the challenge; the other half is managing how people react. Fear makes people focus too narrowly. Stress makes people louder. Urgency causes people to skip steps.
A calm leader helps with all of that. They create a sense of stability during the chaos, and that stability allows people to think clearly when it matters most.
The opposite is also true. A leader who panics, demands constant updates, brings in executives too early, or asks “why wasn’t this caught?” while the site is still down, only makes things worse. People start focusing on appearances instead of solving the problem.
Advice for Handling High-Pressure Incident Calls
If you lead engineering teams, you will eventually run an incident call where the stakes are high and the pressure is real. Here’s what I’ve seen work.
1. Establish the Facts Before Anything Else
The first few minutes of an incident call are often the most chaotic. Everyone has a fragment of the picture and wants to share it. Your job is to slow things down just enough to get a shared understanding.
Start with three questions:
- What do we know is happening right now?
- Who and what is affected?
- What has already been tried?
Don’t let anyone jump to solutions before these are answered. You can’t triage what you don’t understand.
2. Name the Roles Out Loud
Ambiguity is dangerous during incidents. In the first few minutes, make it clear who the incident commander is, who handles communication, and who is doing the hands-on investigation. If people don’t know their role, they either do nothing or try to do everything, and both are problems.
A simple “Alex, you’re driving the investigation. Sam, you’re handling stakeholder updates every 15 minutes. Everyone else, stay available but keep the channel clear” goes a long way.
3. Protect the People Doing the Work
During a major incident, there’s enormous pressure from leadership, customers, and support teams to get updates. That pressure usually falls directly on the engineers trying to fix the problem.
As the leader on the call, your job is to protect your team. Let the investigators focus on their work. Take care of status updates yourself or assign them to someone who isn’t debugging. Every interruption to ask “any update?” is more costly than most people realize.
4. Timebox, Don’t Spiral
When a mitigation path isn’t working, it’s easy to keep throwing time at it because you’ve already invested effort. Set explicit timeboxes: “We’re going to try this approach for 15 minutes. If we don’t see progress, we pivot.”
This approach keeps the team from getting stuck on one idea and lets everyone feel comfortable changing direction without seeing it as a failure.
5. Narrate What’s Happening
In the fog of an incident, people lose track of the big picture. Periodically restate where things stand: “Okay, we’ve confirmed the root cause is the third-party dependency. We’re currently working on a bypass. ETA for the next check-in is ten minutes.”
This narration keeps everyone aligned, reduces repeated questions, and most importantly, shows that someone is in control. That alone helps everyone stay calm.
6. Save the Retrospective for Later
This one is non-negotiable. During the incident is not the time to ask why something wasn’t caught by tests, why there wasn’t a fallback, or who approved the change. Those are important questions, and they deserve thoughtful answers, but no one can give them while the building is on fire.
If someone on the call starts going down this path, redirect them gently but firmly: “We’ll absolutely dig into that in the post-incident review. Right now, let’s stay focused on getting users back.”
7. Check In on Your People After
Once the incident is over and the adrenaline wears off, people crash. The engineer who was debugging at 2 AM, the on-call who caught it first, and the support lead who handled angry customer messages are all exhausted.
A good leader follows up, not just with a Slack message saying “great job team,” but with a real check-in. “That was a tough one. How are you doing? Take some time tomorrow if you need it.” This is how you build the kind of trust that makes people willing to step up with you next time.
The Quiet Superpower
No leadership training can truly teach you how to stay calm when everything is falling apart. It’s a skill you develop through experience, self-awareness, and, honestly, by making mistakes along the way.
But if you can develop this skill, if you can be the person who helps everyone stay calm, you’ll be surprised at how much it changes the outcome. It affects not just the incident but also the team’s confidence, their trust in leadership, and their willingness to take responsibility rather than hide from problems.
The best engineering leaders I’ve seen don’t have all the answers during an incident, and they don’t need to. What matters is that they have the composure to help their team find the answers together, without panic, one step at a time.
By Joshua McDonald on March 12, 2026.
Exported from Medium on August 26, 2026.
Reader discussion