The Premortem: Failing Forward Before You Even Start
We've all been there. The project launches, something breaks spectacularly, and someone in the postmortem says, "You know, I had a feeling this might happen." Why do we only get comfortable voicing our doubts after everything falls apart?
Enter the premortem—a practice borrowed from psychology that flips our relationship with failure on its head. Instead of waiting for disaster to strike, you assume it already has, then work backward to figure out why.
The Core Idea
In 1989, psychologist Gary Klein introduced the premortem technique as a way to combat groupthink and overconfidence. The premise is elegantly simple: imagine your project has failed catastrophically. Now explain why.
This small shift in perspective does something remarkable to your brain. By assuming failure as a fact rather than a possibility, you give yourself permission to think critically without seeming negative or unsupportive. The psychological safety to voice concerns increases dramatically when you're asked "Why did this fail?" instead of "What could go wrong?"
Why Traditional Risk Assessment Falls Short
Most teams approach risk assessment by asking, "What might go wrong?" This invites a laundry list of unlikely edge cases while the elephants in the room go unmentioned. Nobody wants to be the person who kills team morale by pointing out the fundamental flaws in the beloved plan.
Research shows that teams using traditional risk assessment identify about 40% of the problems that eventually occur. Teams using premortems? They catch closer to 70%. The difference isn't in the team's competence—it's in the psychological framing.
Running an Effective Premortem
Follow these steps to run a successful premortem:
1. Set the scene properly.
Start with this exact framing: "It's [date six months from now]. Our project has failed spectacularly. It's been a disaster. Write down every reason why it failed." The specificity matters.
"Spectacular failure" and "disaster" give people permission to think big about what went wrong.
2. Make it individual first.
Give everyone 5-10 minutes to write down their reasons independently. This prevents the most senior or vocal person from anchoring everyone else's thinking. The quiet team member often sees the critical flaw everyone else missed.
3. Share without judgment.
Go around the room and have each person share one reason at a time. No debating, no defending, no "actually that won't happen because..." Just capture everything.
The Goal: psychological safety, not immediate solutions.
4. Look for patterns.
After you've exhausted the list, step back. Which failure modes came up repeatedly? Those are your genuine risks, not the edge cases you typically obsess over.
One person mentioning a risk might be paranoia; five people mentioning it independently is a signal.
5. Prioritize and act.
Not every imagined failure deserves mitigation. Focus on the high-probability, high-impact scenarios that multiple people identified. These become your pre-launch action items or monitoring focus areas.
Real-World Applications
Premortems work across contexts. Before a major deployment, one team imagined their failure:
"The migration took down the entire checkout flow during Black Friday."This led them to discover their rollback plan assumed the database would be in a consistent state—an assumption that wouldn't hold if the migration partially completed. They added safeguards they never would have considered in a traditional risk assessment.
A product team ran a premortem before launching a new feature. Multiple engineers independently wrote "Users didn't understand what the feature does." This redundancy forced the team to seriously reconsider their microcopy and onboarding flow, even though leadership was confident it was "obvious."
Beyond Launch Day
The power of premortems extends beyond project kickoffs. Run them before major refactors, before switching technologies, before organizational changes. Any time you're about to do something with significant stakes and uncertainty, pause and imagine it's already failed.
The technique also works for career decisions, technical designs, and hiring plans. Imagine you hired that candidate and six months later it's clearly not working out—why? Imagine you chose that architecture and a year later you're rewriting everything—what happened?
The Uncomfortable Truth
Premortems work because they force us to confront something we naturally resist: our plans might be wrong. Not in small, fixable ways, but fundamentally, catastrophically wrong. This is uncomfortable, especially in cultures that reward confidence and decisiveness.
But here's the thing about software engineering: reality doesn't care about your confidence. The database will fail during your demo whether you acknowledged the risk or not. The API you're depending on will have breaking changes whether you planned for them or not. The code you're shipping has bugs whether you want to admit it or not.
The premortem isn't about being negative. It's about being honest before honesty becomes expensive. It's about creating the space to voice doubts when they can still inform decisions rather than just populate postmortem documents.
Making It Stick
Start small. Try a 15-minute premortem before your next significant deployment or feature launch. Make it psychologically safe by going first—share your own concerns about what could go wrong. Show the team that naming failure modes is valuable, not disloyal.
Over time, premortems become less about discovering new risks and more about building a culture where people feel safe raising concerns before they become crises. That cultural shift is worth more than any risk register.
The projects that succeed spectacularly aren't the ones where nothing went wrong. They're the ones where the team saw the problems coming and did something about them. Sometimes the best way to fail forward is to fail backward first—while you still can.
Your Premortem Template
Copy this template for your next session. Share it with your team beforehand so they know what to expect.
Setup (Share with team 24 hours before)
Session Details:
- Duration: 30-45 minutes
- Date: [Insert date 6 months in the future]
- Project/Initiative: [Name]
- Scenario: "It's [date]. Our [project] has failed spectacularly."
What to bring: Your honest concerns, no filter needed.
Facilitator Script
Opening (2 min): "It's [date]. Our [project] has been a disaster. Complete failure. We're here to figure out exactly what went wrong. Remember: failure is already a fact in this exercise. We're not debating if it could happen—we're explaining why it did."
Individual Writing (10 min): "Take 10 minutes. Write down every reason our project failed. Be specific. Think about technical failures, communication breakdowns, wrong assumptions, external factors—everything. No idea is too obvious or too pessimistic."
Round-Robin Sharing (15-20 min): "We'll go around the room. Each person shares one failure reason at a time. I'll capture everything on the board. No debating, no 'that won't happen because...' Just listen and add to the list."
Pattern Recognition (5-10 min): "Let's step back. Which failures came up multiple times? What themes do we see? Circle the repeated concerns—those are our real risks."
Action Planning (10 min): "For our top 3-5 risks: What can we do now to prevent them? What monitoring would catch them early? Who owns each mitigation?"
Capture Template
PROJECT: ________________
DATE OF PREMORTEM: ________________
IMAGINED FAILURE DATE: ________________
FAILURE SCENARIOS IDENTIFIED:
□ [Reason 1] - mentioned by: [names/count]
□ [Reason 2] - mentioned by: [names/count]
□ [Reason 3] - mentioned by: [names/count]
[Continue...]
TOP RISKS (mentioned by 3+ people):
1. ________________
2. ________________
3. ________________
MITIGATION ACTIONS:
Risk: ________________
Action: ________________
Owner: ________________
Due: ________________
[Repeat for each top risk]
MONITORING PLAN:
What we'll watch: ________________
How we'll know early: ________________
Who's watching: ________________