Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Pre-Mortems to Avoid Failure Before It Happens
Transcript
- Lucas: There's this exercise I've seen a few CTOs use that sounds almost morbid at first, but it might be one of the most practical things you can do before a big project. Luna: Okay, I'm intrigued. What's the exercise? Lucas: It's called a pre-mortem. Instead of waiting for a project to fail and then doing a postmortem, you gather the team at the start and say: 'It's six months from now. The project launched, and it was a disaster. What went wrong?' Luna: So you're asking people to imagine failure before you've even started. That feels like it could be a downer. Lucas: It can feel that way, but the CTO who introduced me to this, she runs engineering at a mid-sized SaaS company—about 80 engineers—and she told me the pre-mortem actually reduces anxiety. Because the fears are already out in the open. You can address them instead of letting them fester. Luna: I can see that. So how does she actually run one? Is it a formal meeting, or more of a brainstorming session? Lucas: It's structured but informal. She does it over about 90 minutes, with the whole team that will work on the project. The rules are simple: everyone writes down, silently, three to five reasons the project failed. Then you go around the room and share. No debating, no defending—just capture everything on a whiteboard. Luna: Silent writing first. That's smart—prevents anchoring. If the most senior person speaks first, everyone else might just nod. Lucas: Exactly. And she's very deliberate about framing. She says: 'I'm not asking you to be negative. I'm asking you to be honest about what keeps you up at night.' That reframe makes a difference. People feel permission to raise concerns they'd otherwise suppress. Luna: What kind of things come up? Give me a concrete example from her team. Lucas: Sure. They were planning a major platform migration—moving from a monolithic database to a sharded architecture. The pre-mortem surfaced two things that hadn't been in any risk register. First, the team realized the migration would require running both the old and new databases in parallel for weeks, and nobody had costed the additional read replicas. That was going to blow the cloud budget by about 40 percent. Luna: Ouch. And the second thing? Lucas: A junior engineer recalled that one of their core third-party APIs had a rate limit of 100 requests per second, and the migration plan assumed 500. That would have caused a six-week delay while they negotiated a new contract. Both issues were caught in the pre-mortem, before a single line of migration code was written. Luna: That's exactly the kind of thing that would only surface three months in, under pressure. So the pre-mortem basically gave them a free six-week insurance policy. Lucas: Right. And the CTO told me that after that experience, the team started doing pre-mortems for every project that had any meaningful risk. Not just big migrations—even feature launches with new dependencies. Luna: Does it work for every team dynamic? I'm thinking about a team where the culture is very 'can-do' and people might see this as questioning their competence. Lucas: That's a real risk. She told me the first time she ran it, one of her senior engineers said, 'This feels like we're planning to fail.' Her response was: 'We're planning to succeed by knowing what could go wrong.' She also made sure to lead by example—she shared her own fears first. That set the tone. Luna: So it's about psychological safety. The leader has to model vulnerability. Lucas: Absolutely. And she also follows up with a concrete action plan. After the pre-mortem, they categorize each risk by likelihood and impact, then assign owners and mitigation steps. It's not just a venting session—it produces a documented risk response. Luna: That makes it more than a thought experiment. It becomes a project management tool. Lucas: Exactly. And I think that's why it's more effective than a standard risk register. A risk register is usually filled out by one person—the PM—and it lives in a spreadsheet nobody reads. A pre-mortem is collaborative, specific, and emotionally engaging. People remember the risks because they came up with them. Luna: If today's tech conversation gave you something usable, the show stays ad-free thanks to listener support. You can find the link at buy me a coffee dot com slash fexingo. Every bit helps. Lucas: Yeah, and honestly, if today was worth a coffee to you, that's the link—buy me a coffee dot com slash fexingo. And we're not asking for much, just that if you find value here, you toss something in the jar. Luna: Alright, back to pre-mortems. One thing I'm curious about: how do you prevent the exercise from becoming a laundry list of everything that could possibly go wrong? You want signal, not noise. Lucas: That's a great question. The CTO I spoke with uses a simple constraint: each person can only write down three reasons. And she times the silent writing—five minutes, max. That forces people to prioritize. Also, after sharing, she has the group vote on the top three risks using dot voting. That narrows the focus quickly. Luna: So you get the breadth of ideas, but then you converge. That's a classic design thinking move. Lucas: Exactly. And she told me that the voting phase often surfaces risks that the most senior people wouldn't have thought of. In that migration pre-mortem, the rate-limit issue only got three votes initially, but after the junior engineer explained the impact, it jumped to the top. If they'd just gone with senior intuition, they would have missed it. Luna: That's a powerful argument for including junior voices early. So how often should a team run pre-mortems? Is it just for big projects, or can it be a regular cadence? Lucas: She runs them for any project with a budget over $50,000 or a timeline longer than three months. But she also does a lighter version—what she calls a 'pre-mortem lite'—for smaller features. That's just 30 minutes, with everyone writing down one risk each. It keeps the muscle memory alive. Luna: Pre-mortem lite. I like that. It's like a fire drill for project failure. Lucas: That's a great analogy. And like fire drills, the more you practice, the less awkward it feels. The first time, people are uncomfortable. By the third time, they're volunteering risks before you even ask. Luna: I want to push on one more thing. There's research that shows that imagining failure can actually reduce overconfidence—it's called prospective hindsight. Does she see that effect? Lucas: She does. She told me that after the pre-mortem, the team's estimates actually became more realistic. They stopped padding every timeline by 50 percent, because they had concrete risks to plan for instead of a vague sense of doom. The pre-mortem gave them a specific list of things to mitigate, so the buffer could be smaller and more targeted. Luna: So it's not just about catching problems—it changes how you plan. Lucas: Exactly. And I think that's the deeper value. A pre-mortem is a tool for building a culture where failure is discussable before it happens. That's rare in engineering teams, where the pressure is often to project confidence. Luna: Right. And it's a low-cost intervention. An hour and a half versus potentially months of rework. The ROI is almost always positive. Lucas: Absolutely. And to close, I'll leave you with something that CTO said: 'The projects that fail are rarely the ones where we saw the risks coming. They're the ones where we didn't look.' A pre-mortem is just a structured way to look. Luna: That's a good note to end on. Thanks, Lucas. Lucas: Thanks, Luna.