💀 Pre-Mortem for Major Project

Pre-Mortem Report

The Scene 6 Months From Now (Project Failed)

It's October 2026. The Q2 migration plan formally wrapped at the end of July — 4 weeks late. Linear adoption plateaued at 68% after week 12. Four of the five engineering teams fully migrated; one team, led by Marcus, never did. They argued that Linear's issue model didn't fit their embedded-systems work, and nobody overruled them. By October, that team is operating in a split reality with shared dependencies (half the dependencies tracked in Linear, half still in Notion), which is causing 2-3 missed handoffs per sprint.

The Slab doc migration stalled at 54% migrated. The Notion→Slab script lost formatting on embedded databases — the team discovered this at week 6 and there was no fallback plan. Engineers have quietly kept using Notion for 'important' docs and Slab for 'new' docs, which means institutional knowledge is now split across two systems. The retrospective, when it eventually happens in November, identifies 'lack of executive enforcement' as the root cause. Priya takes the hit. Nobody mentions that the CTO never said 'no' to Marcus's team's push-back.

Top 5 Failure Modes, Ranked by Probability

1. Partial adoption: one team refuses to fully migrate (~65% probability)

• Root cause today: Two of five team leads have pushed back informally. Nobody has forced a resolution. The team lead most likely to opt out is the one whose push-back is quietest right now.
• Pre-emptive fix: Force the conversation in week 1. 'Migration is mandatory for all engineering teams by week 8. If you have a blocker, we're solving it this week, not at week 7.' Get commitment or escalation, not silence.

2. Migration script fails at volume (~55% probability)

• Root cause today: Untested on actual content volume. Most Notion→Slab migrations we've seen handle 100-500 pages. You have ~3,000+.
• Pre-emptive fix: Run the script this week on a 100-page test corpus that includes your most complex docs (embedded databases, nested pages). Budget 1 engineering week to fix formatting issues BEFORE announcing the migration timeline publicly.

3. Change management fails at the team-lead level (~50% probability)

• Root cause today: 'Change management communication: TBD' is the most dangerous phrase in the project brief. Tool migrations fail at the 'why should I care' layer, not the 'which button do I click' layer.
• Pre-emptive fix: Draft the communication THIS WEEK. Specifically: what changes, what doesn't, why now, what happens if someone doesn't migrate. Dry-run with 1 skeptical engineer, not the sponsor.

4. Historical Notion content is lost or buggy post-migration (~40% probability)

• Root cause today: No defined 'what happens to old Notion' plan. Will Notion workspace stay read-only for 12 months? 6 months? Deleted?
• Pre-emptive fix: Decide now: Notion stays read-only for 12 months minimum. Announced in writing. This is cheap and eliminates the fear-of-loss that kills migrations.

5. Productivity dips > 10% during weeks 4-7 (~35% probability)

• Root cause today: Dual-tool period is always painful. Engineering velocity typically drops 15-25% during real tool migrations — not 10%.
• Pre-emptive fix: Set expectations that velocity WILL drop during weeks 4-7 and protect that in quarterly planning. Don't promise the CEO zero-drop; budget for 15% and overperform.

The Organizational Pattern This Project Risks Repeating

Your last 2 tool migrations ran 2x over schedule. The specific pattern: the project plan assumes authority that the sponsor doesn't exercise. The CTO 'backs this publicly' but is historically conflict-averse about adoption. When the reluctant team pushes back, he won't force the issue — so the project lead (Priya) ends up trying to enforce CTO-level decisions without CTO-level authority. That always fails. Every time.

This is not a tool migration risk. This is a culture pattern. If not named and broken, it breaks the project.

The Single Point of Person-Failure

Priya. Not because she's weak — because she's carrying too much. If she's out for 2 weeks at week 5-7 (for any reason — illness, family, vacation that gets rescheduled) this project stalls and won't recover.

Mitigation: pair her with a deputy from day 1. Someone whose name gets added to every project meeting. Not 'backup' — co-owner. Lower the single-point risk at the cost of some coordination overhead.

The Hand-Wave That Will Actually Matter

You listed three hand-waves. The actual killer is: change management is 'TBD'. The migration script risk is solvable with engineering time. The reluctant team is solvable with explicit authority. But TBD change management means the 'why' of this migration never lands with the people who have to change behavior. Without that, 100 status updates won't save adoption.

The Cheapest Experiment to De-Risk

This week: conduct a 30-minute interview with Marcus (the quietly-reluctant team lead). Ask one question: 'If I told you your team had to be fully on Linear by July 15, would that work? If not, what specifically doesn't?' His answer — the detail, the hesitation, the specifics — reveals whether this project has a path or a landmine.

Cost: 30 minutes. Value: potentially saves the project.

What to Change Before Starting

1. Assign a deputy to Priya (reduce single-point-person risk).

2. Run the migration script on a 100-page test corpus this week (reduce tech risk).

3. Draft and circulate the change management plan before the public project announcement (reduce adoption risk).

4. Force a yes/no from all 5 team leads in writing before kickoff (reduce phantom-dissent risk).

5. Budget 15% velocity drop in quarterly planning (reduce pressure-to-lie-about-metrics risk).

The Question to Force Before Kickoff

'What does the CTO do if one team refuses to migrate by week 8?' Get an answer in writing, from the CTO. 'We'll figure it out then' is not an answer — that's exactly the phrase that causes the 65%-likely failure mode. Make him commit to what he'll actually do. If he can't, the project doesn't have executive sponsorship — it has executive well-wishing. Those are different.