Crisis-Mode Composure: Authoring Postmortems, Not Pointing Fingers
Two infrastructure crises a year apart played out the same way. An OS upgrade that broke our containerized build agents on a Friday afternoon. A multi-hour outage of the developer platform we run all our work on. Different causes, different months, different teams in the room, and the same approach worked for both.
The approach isn't stoicism, and it isn't grace under fire as a personality trait. It's a learnable practice made of four distinct moves, plus the document the producer writes on the other side. This post is what I've come to call crisis-mode composure, and what it actually looks like when a producer is trying to do it in real time.
Two Ways It Goes Wrong
Most producers under crisis pressure fall into one of two traps. Knowing them is half the battle.
The first is visible panic. Frequent updates with no information. Long messages full of speculation. Public second-guessing of the people working the problem. Every team has watched this play out in some incident, and the lesson it teaches is that the person in charge can't be trusted to lead through a hard moment. That lesson is hard to unlearn.
The second is invisible silence. The producer disappears into a back channel. The team can hear the producer working on it somewhere, but there's no public signal of what's happening, no acknowledgment of the disruption, and no indication of when there will be one. Silence is worse than panic, because at least panic confirms that someone is paying attention. Silence reads as abandonment.
The practice I'm going to describe is the path between those two. It isn't the absence of stress. It's the habit of acting despite the stress, in a way the team can rely on.
The Four Moves
Steady comms. Short, frequent, factual updates in the public channel where the team works. The format I use is roughly: what's broken, what we know, what we're doing, what we don't know yet, when the next update will be. Same rhythm whether there's news or not. "No new information, next update in thirty minutes" is a real, valuable update, because it tells the team the producer is still on it and they don't have to be.
The rhythm is the thing. People can take in a lot of bad news if it arrives reliably. What they can't handle is uncertainty about whether the next update will ever come. Setting a rhythm and meeting it is the cheapest trust a producer will ever buy.
Work the problem. The producer stays visible doing the work, not managing perceptions. Part of the job during a crisis is clearing blockers for the people who can actually fix the issue. That means coordinating with vendors, holding off non-essential interruptions, surfacing relevant information from older incidents. It also means not second-guessing the engineers in real time. The right call is to trust the people whose job it is to fix it, give them the cover they need, and let them work.
When the producer is also one of the engineers, which happens at small enough scale, the job splits in two. The producer works the problem in one channel and writes the steady comms in another, and the two have to stay distinct. Raw debug output pasted into the public channel is not a substitute for an update. It has to be translated.
Recognize the people getting through it alongside the team. By name, for specific actions, in public. Mid-incident, after the worst of it has passed but before the postmortem. The vendor support engineer who picked up the call at 2 AM. The team lead who held the rest of the team's day together while everyone else was heads-down. The junior engineer who spotted the misconfiguration nobody else had thought to check.
Recognition matters because crisis is when the team's trust in leadership is most observable. Public recognition during the bad hours is the cheapest, most durable team-trust investment available. It also gets noticed. After one of the outages I've referenced, an engineer DM'd me with a one-liner I still think about: "I see you and appreciate you being everywhere." That's the trust recognition produces. It's worth spending freely, and it doesn't run out.
Author the postmortem. The senior person in the room should write the postmortem, and set the tone before someone else sets it for them. The postmortem is not a punitive document. It's a structural record. What happened, in clear language. What worked. What didn't. What we're going to change so this is less likely or less costly next time. Who doesn't appear in a good postmortem. What appears throughout.
The reason the producer should author it is that the postmortem is the framing the team will remember. If the framing is "an outage happened, here's what we learned, here's what we're changing," the team carries that into the next crisis. If the framing is "someone messed up and we're going to track that," the team carries that instead, and the next outage gets reported later, with less detail, by a team that's now afraid of being blamed.
The Postmortem as a Record, Not a Punishment
The blameless framing is not a soft option. It's a tool that produces better outcomes than the alternative.
Blameless framing optimizes for the next outage. It treats the current incident as data about the system, and the system as the thing to change. Who messed up is rarely actionable. The same person, given the same information, the same time pressure, and the same constraints, would mess up the same way next time. Changing the system is what changes the outcome.
The structural changes that come out of a postmortem are the actual product. From the two crises I referenced, those changes included a 24-hour merge cutoff before milestone deadlines (so the last build before a deadline isn't also the riskiest one) and a dedicated production point of contact for releases (so engineering and partner-facing communication don't both fall on the same person at the worst moment). Neither change was visible during the postmortem itself. Both were live within the next sprint.
A useful test for whether a postmortem is doing its job: does it produce a structural change someone can point to, that lives past the document? If yes, it's working. If no, it's a meeting summary, and the next outage will look exactly like this one.
What This Is Not
Crisis-mode composure is not a personality trait. People who appear naturally calm under pressure have usually built the practice through repetition. People who don't appear calm are often doing fine internally and just need a little support shaping the comms. Either way, the four moves are learnable.
It's also not the absence of stress. The whole point of the four moves is that a producer can run them while stressed, while scared the team will lose trust, while running on too little sleep, while not actually knowing if the issue can be fixed in the next hour. The stress isn't the problem. Letting the stress determine the output is the problem.
And finally, it is not stoicism. Public recognition is part of the practice, and so is acknowledging, in the postmortem, that the incident was hard. "This was a tough day, the team handled it well, here's what we learned" is a better postmortem opener than a clinical incident summary. Composure does not mean detachment.
Why the Default Matters
The whole practice fits in one line. Stay visible, work the problem, name the people, write the document.
The studios I've seen handle crises well, even minor ones, are the studios where this is the default. The studios that don't are the ones where every incident becomes a story about who's at fault and how to avoid that person next time. The first kind gets steadily more resilient. The second kind doesn't, and the gap widens with every outage. Composure isn't a gift some people have and others don't. It's a practice, and the four moves are how a producer builds it.