The Handoff Knowledge Gap
You're leaving a project — transferring to a new team, going on leave, or changing roles. You write a handoff email that lists the project status, the key contacts, and the next steps. You feel thorough. The person receiving it feels lost.
The gap isn't information — it's context. Handoff emails typically transfer WHAT is happening without transferring WHY things are done a certain way, WHERE the landmines are, and WHO actually makes decisions versus who's listed as the decision-maker on paper.
A good handoff email saves the next person weeks of painful discovery. A bad one just moves the burden of confusion from you to them.
The Complete Handoff Template
Subject: [Project name] handoff — everything you need
Hi [Name], Here's everything for [project name]: STATUS: [Current state in 2-3 sentences. Where things are, not where they should be.] KEY DECISIONS MADE: [3-5 bullets of decisions that shaped the current approach — and WHY they were made, not just what was decided.] OPEN ITEMS: [Specific tasks remaining with deadlines and owners.] LANDMINES: [Things that look fine but aren't. Stakeholders with strong opinions. Technical debt that will surface. Dependencies that might slip.] KEY CONTACTS: [Names + what they actually do, not just titles. 'Sarah — she's the real decision maker on timeline even though Tom is listed as PM.'] WHERE EVERYTHING LIVES: [Links to docs, repos, Slack channels, dashboards.] I'm available for questions through [date]. After that, [backup person] can help. [Your name]
The 'landmines' section is the most important part. Every project has them. The previous owner knows them intuitively. The new owner will discover them painfully — unless you write them down.
The Quick Handoff (For Smaller Projects)
Subject: Quick handoff — [task/project]
Hi [Name], Handing off [project]. Three things you need to know: 1. [Most important context — the thing that isn't obvious from the docs] 2. [The next critical deadline and what needs to happen] 3. [The person to call when things get confusing] All docs are in [location]. I've added you as [owner/editor]. Questions? I'm around until [date]. [Your name]
For small projects, over-documenting feels patronizing. Three things that matter beats twenty things that might. The person receiving the handoff can always ask for more — the priority is giving them the right starting point.
What Most Handoffs Miss
Verbal agreements that never got documented. Every project has them. 'We agreed with the client that...' but it's in no email, no ticket, no document. Write these down during handoff or they become the next person's surprise.
Relationship context. 'The engineering team is sensitive about timeline changes because last quarter they were blindsided twice.' This kind of context doesn't live in project docs, but it determines whether the next person succeeds or fails in their first week.
Your honest assessment of the project's health. Not the status update version — the real version. 'Officially we're on track. Realistically, the API integration is going to slip by two weeks because the vendor is unresponsive.' Your successor deserves the truth, not the presentation.
Top comments (0)