A Major Incident

Production is on fire. Customers are affected. The team is in the war room. People are scared.

In the moment

• Be present, be calm, be quiet. My job is not to fix it — it’s to make sure the people fixing it have what they need.
• Confirm there’s an incident commander. If there isn’t, name one (probably not me).
• Ask “what do you need from me?” not “what happened?”
• Handle upward communication so the team can focus on the system.
• If I’m not adding signal, mute myself and stay in the room.

In the following days

• Run a blameless postmortem. Real one. Five whys, system view, action items with owners and dates.
• Communicate externally if needed — with the team’s input, with honesty, without performance.
• Defend the engineer whose change triggered it. Publicly. The system allowed the failure, not just the human.
• Follow through on the action items. A postmortem without follow-through is theater.

What to watch for in yourself

• The hero reflex. Taking over because I’m anxious. Trust the people doing the work.
• Asking “why” in a tone that lands as blame, even when I don’t mean it.
• Going to bed too early and leaving them on the fire alone. Stay until the team has what they need.

Common traps

• Making myself the incident commander out of habit.
• Letting the person who shipped the bug feel publicly responsible. The team will calculate the cost of shipping anything risky after that.
• Punishing instead of learning.
• Treating the postmortem as a deliverable to close out rather than a system to change.

Sample language

“I’m here. What do you need from me?”

“I’ve got the comms upstream. Focus on the system.”

“This is on the system, not on [person]. Our job now is to figure out what to change.”