Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / Why Your Eng Team Needs a Pre-Mortem Before Every Launch
Transcript
- Lucas: So we all know the post-mortem — your service went down, you write a doc, figure out what happened, and promise not to do it again. But there's a far more interesting exercise that most teams skip entirely, and it's called the pre-mortem. Luna: A pre-mortem? As in, you imagine the failure before it happens? Lucas: Exactly. The term was coined by psychologist Gary Klein back in the late 1990s. The premise is simple: you gather your team right before a launch, and you ask everyone to imagine it's six months in the future and the project has failed catastrophically. Then you work backwards to figure out why. Luna: That sounds almost too simple. But I've read that it's surprisingly effective at surfacing risks that nobody talks about in a regular planning meeting. Lucas: It is. And the reason is psychological. In a standard planning session, people are optimistic — they want to believe the project will succeed. There's social pressure not to be the person who brings up worst-case scenarios. A pre-mortem flips that: you're now expected to be pessimistic. The higher-ups are literally asking you to describe what goes wrong. Luna: So it gives permission to voice concerns that might otherwise be suppressed. Lucas: Right. And the results can be dramatic. I've done this with teams before. One time, we were about to launch a new payment processing service — heavily anticipated, big revenue upside. We ran a pre-mortem, and within 20 minutes, an engineer said: 'Look, if we scale to 50,000 concurrent users on day one, our database connection pool will exhaust in about four minutes.' Luna: Oof. And that hadn't come up before? Lucas: Not once. The performance tests had been run at 10,000 users. Everyone assumed launch traffic would be gradual. The pre-mortem forced them to think about the worst-case spike. We ended up redesigning the connection pooling layer before launch. That one change probably saved us a two-million-dollar recovery effort. Luna: Two million? That's a big number. But I think the real value is that a pre-mortem doesn't just find technical flaws — it uncovers assumptions about timelines, resources, dependencies. Lucas: Absolutely. And it does so without blame. That's the key difference from a post-mortem, where you're often trying to figure out who dropped the ball. A pre-mortem is speculative — 'we haven't failed yet, so let's imagine how we could.' No one's defensive. Luna: I've heard that Amazon uses pre-mortems as part of their six-pager culture. They write a hypothetical press release about the failure, then work backward to prevent it. Lucas: They do something close to that. Jeff Bezos has talked about using a 'pre-mortem' before big launches. And Google's Project Aristotle research — the one about psychological safety — identified that teams where people feel safe to voice dissenting opinions perform better. A pre-mortem is a structured way to build that safety. Luna: So it's not just about catching bugs. It's about culture. Lucas: Exactly. And the great thing is, you don't need a huge time commitment. A good pre-mortem can be done in 45 minutes. Here's the template I use: First, you frame the scenario — 'It's six months after launch, and the project has been a disaster. Revenue is down, users are complaining, and leadership is unhappy. Write down every reason why that might have happened.' Luna: And everyone writes individually first, right? So they aren't influenced by the loudest voice in the room. Lucas: Yes. Silent writing for five minutes. Then you go around the table and each person shares one reason. You capture them on a whiteboard or a shared doc. No debate, no judgment — just listing. Then you group the risks by category: technical, resource, market, whatever. Luna: What happens next? Do you assign owners for each risk? Lucas: You do. For each risk, you ask: 'What is the probability of this happening? And what is the impact?' Then you pick the top three to five risks — the ones with high probability and high impact — and you assign someone to investigate or mitigate them before launch. It becomes a concrete action plan. Luna: I like that it's not just a brainstorming exercise. It leads to actual changes. Lucas: That's the point. If you just list risks and do nothing, you've wasted everyone's time. I've seen teams that run a pre-mortem, identify a critical dependency on an external API that has no SLA, and then go negotiate a better contract or build a fallback. That's the kind of thing you'd never catch in a regular status meeting. Luna: But I can imagine some managers pushing back: 'We don't have time for another meeting. The launch is in two weeks.' Lucas: That's the most common objection. And my answer is: 'You don't have time not to do this.' If a pre-mortem catches even one issue that would have caused a production outage, it pays for itself a hundred times over. Plus, you can run it as part of an existing planning meeting — just replace the usual status update with this exercise. Luna: So you're saying it's a higher-leverage use of the same hour. Lucas: Exactly. And there's another benefit I didn't mention: the pre-mortem builds shared context. When everyone on the team knows the top risks, they start making decisions that avoid those risks. It aligns the team without micromanagement. Luna: I want to push on one thing. You said the pre-mortem works because it gives permission to be pessimistic. But what if the team culture is already toxic — where people fear retaliation? Will a pre-mortem still work? Lucas: Good question. If the culture is genuinely toxic, no single exercise will fix it. But a pre-mortem can be a first step. I've seen it used in low-trust environments where the team starts off quiet, but after the facilitator models vulnerability — like 'I'm worried we're underestimating the migration effort' — others start chiming in. It's not a silver bullet, but it can crack the door open. Luna: And you can do it without the manager in the room, right? Have a peer facilitate. Lucas: Absolutely. Sometimes it's better if the manager isn't there, because people might still filter. You can run it as a skip-level exercise. The key is to make the output anonymous if needed, and then the manager sees only the aggregated risks. Luna: That's a smart adaptation. Okay, let's talk about the cognitive biases a pre-mortem counteracts. Overconfidence is the obvious one. Lucas: Right. The planning fallacy — we systematically underestimate how long things will take and how much they'll cost. A pre-mortem forces you to consider the obstacles that could derail the plan. It also fights groupthink: when everyone in a meeting nods along, the pre-mortem gives an excuse to dissent. Luna: And confirmation bias — you tend to look for evidence that supports your plan, not evidence that contradicts it. The pre-mortem flips that search. Lucas: Exactly. It's a structured debiasing technique. And it's remarkably low-cost. I've run pre-mortems with teams of five and teams of fifty — you can scale it by breaking into small groups and then sharing highlights. Luna: Any memorable failures from your own experience where a pre-mortem would have helped? Lucas: Oh, plenty. One that comes to mind: a team I was on built a new microservice for handling image uploads. We launched, and within an hour, the service was overwhelmed because we hadn't accounted for a viral marketing campaign that drove ten times our expected traffic. A pre-mortem would have surfaced that risk, and we could have added auto-scaling or a queue. Luna: Classic. And that's the kind of thing that feels obvious in hindsight. Lucas: Right. Hindsight bias is a powerful thing. The pre-mortem makes that hindsight available before the fact. It's like a vaccine — you expose the system to a small dose of failure to build immunity. Luna: I like that metaphor. So if someone listening wants to try this next week, what's your recommendation for the first step? Lucas: Pick a project that's at least moderately complex — something with a launch in the next month or two. Invite the core team for a 45-minute slot. Read them the scenario: 'It's six months later, the project has failed. Write down why.' Then collect, categorize, and prioritize. That's it. Don't overthink it. Luna: And if the team pushes back, you can always start with a mini pre-mortem on something small, like a quarterly planning cycle. Lucas: Great idea. Build the muscle with low stakes, then apply it to the big launches. Honestly, if every engineering team did even one pre-mortem per quarter, the industry would save billions in failed projects. Luna: Billions sounds high, but I think you're right. The cost of one major failure can be enormous. And the pre-mortem is essentially free. Lucas: Cheapest insurance you'll ever buy. And speaking of keeping things running — this is a bit meta, but it's related: the reason we can keep making these episodes ad-free, and dig into topics like this, is because a small group of listeners chips in monthly through buy me a coffee dot com slash fexingo. It's not a big ask — it's just how this show stays listener-supported and independent. Luna: Yeah, it's a good model. Keeps us focused on what's actually useful rather than what advertisers want. And we get to go deep on stuff like pre-mortems because we're not chasing ad breaks. Lucas: Exactly. So if you've gotten something out of this episode, that's the way to keep it going. But back to the pre-mortem — one last tip. After you've run it and mitigated the top risks, don't throw away the list. Revisit it after launch. See which risks actually materialized and which didn't. That feedback loop makes your future pre-mortems even sharper. Luna: That's a great point. It turns the pre-mortem into a learning tool that improves over time. Lucas: Right. And eventually, it becomes part of your team's DNA. You stop having to schedule it — people just start asking, 'What would the pre-mortem say about this decision?' That's when you know it's stuck. Luna: Alright, I'm going to run one with my team next week. I'll let you know how it goes. Lucas: Please do. I'd love to hear what risks you unearth. And to everyone listening — try it. You might be surprised at what you find.