TL;DR: An engagement survives a change of builder when the handoff is a pointer to living account state, not a document. Handoff docs are snapshots that can't be verified once the author leaves, and by a 2018 estimate 42 percent of institutional knowledge is unique to the individual holding it. The runbook below covers the three handoff types (planned, pool graduation, acquisition) in seven steps. Spendesk shows the end state: an engineer picks up any account and knows in five minutes what was promised and what's at risk.
The head of an FDE team at a finance-software company told us what a handoff looks like when it goes wrong: "the person who was building had to go on paternity leave before they finished the build," leaving behind "all these handoff notes that we actually don't really know yet. We have to go in back and rediscover them." The engagement didn't fail. It just quietly restarted, with a customer who thought they were halfway done.
That's the real cost of an FDE handoff. Not the transition meeting, but the weeks of rediscovery afterward, where the successor rebuilds decisions the team already made and the customer repeats things they already said. A forward deployed engineer's account knowledge is concentrated by design, half their job is being on the calls. So when the builder changes, the engagement's memory walks out with them unless it was held somewhere else all along.
This runbook treats that as the design constraint. You can't make handoffs rare (leave, rotation, growth, and acquisitions guarantee them). You can make them cheap, by making the handoff a pointer to living account state instead of a package assembled at the end.
The three handoffs every FDE team eventually runs
Handoffs get planned for as if they were one event. They're three, and they fail differently.
The planned handoff
Parental leave, a rotation, a resignation with notice. You have weeks of warning, which is why teams over-invest in the document: there's time to write one. But the same head of FDE described where the account state actually lived on her team: "it kind of all lives in a bunch of, like, weird cloud chats or, like, half baked" documents and "Slack kind of things." The notice period gets spent packaging that sprawl, and the package still can't be trusted later.
The structural handoff
Some teams run 90-day ownership followed by pool graduation: one FDE lands the account, then a shared pool operates it. This handoff is scheduled from day one, and it's the model's whole bet. If graduation means re-ramping a pool engineer from a summary doc, the model caps out. If it means the pool queries the same account state the owner used, it scales. The same problem shows up when onboarding a second FDE onto a live account, which is a handoff in slow motion.
The inorganic handoff
An FDE team lead at a roughly 50-person AI company described a run of new initiatives arriving through acquisition. Acquisitions hand you accounts where the original builder isn't just busy, they're often gone, along with their tools and conventions. There's no notice period and no shared vocabulary. Whatever context transfers is whatever was externalized before the deal closed.
Why does the handoff document always fail?
Every team's first answer is a better template. The template isn't the problem.
It's a snapshot of a moving system
A handoff doc describes the account on the day it was written. Live engagements change weekly, and staleness is silent: the doc still reads confidently. The freshness research on knowledge systems makes the general point, a system can score well on every metric while returning information superseded for weeks. A static doc is the degenerate case, superseded and unaware of it. The same failure applies to meeting notes standing in for account state.
It's written by the person with the least time
The leaver writes the doc during their busiest weeks, on top of finishing the build. Manual reporting already eats FDE teams' time, 72% of project professionals spend half a day or more collating reports every month, and a handoff pack is that same collation with higher stakes. Predictably, it covers what was easy to remember, not what the successor will need.
It can't be verified after they're gone
This is the one that killed the paternity-leave build. Notes without sources are claims. Once the author is unreachable, the successor can't tell a current fact from a stale one, so they re-verify everything with the customer. That re-verification is the "rediscovery" phase, and it's the part that damages customer confidence. With 42 percent of institutional knowledge unique to the individual, the doc was always going to be a partial export.
What a handoff actually has to transfer
Strip it down and a successor needs current answers to four questions, each with the source attached. What was promised, in the contract and on calls. What was decided, and why, including the decisions made mid-build in coding sessions, which never make it into handoff docs at all. What's at risk right now. What happens next, and who owes whom what.
Notice what's not on the list: judgment. How hard to push this customer, which stakeholder needs warming up before a change lands. Judgment doesn't transfer through any artifact, it rebuilds through reps. That's fine if the context half transfers cleanly, and catastrophic if the successor is rebuilding both halves at once, which is how you get engineer re-ramps in the 3-to-9-month range on an account the team supposedly already knew.
There's a precedent for fixing this class of problem. Most teams already learned that the sales-to-implementation handoff fails as a one-time briefing. The FDE-to-FDE handoff fails the same way, for the same reason.
The handoff runbook
Seven steps, and the first one matters more than the other six combined.
- Start the handoff before you know you need one. The only handoff that works is the one already running. Keep account state in a team memory from kickoff, synced from calls, Slack, and tickets, so "prepare the handoff" is never a project. Everything below assumes some version of this exists.
- Point, don't package. The handoff artifact is a pointer to the living account state plus a short delta: what the state can't hold. If you're packaging, you're transcribing things a system should have been holding all along.
- Walk the risks, not the history. In the handoff conversation, the leaver and successor go through open risks one by one. In Tandem, a risk check returns the list with an explanation, the reason, and the sources behind each, so the conversation starts from evidence instead of recollection. The leaver's job is to add what the sources can't show.
- Transfer the decision log with the why attached. Decisions without rationale get relitigated, usually in front of the customer. If build decisions happened in Claude Code sessions, sync the ones that matter to the team memory before the leaver goes. Honestly: the sync is something the leaver triggers and chooses, it doesn't happen by itself.
- Run one paired call, then cut over. One call where the successor leads and the leaver observes. More than one signals to the customer that the transition isn't real, and keeps the leaver on the hook indefinitely.
- Take the leaver out of the lookup path. After cutover, questions go to the account state, not the person. Every "quick question" to someone on leave or in a new role costs them 23 minutes and 15 seconds to recover their focus, and every answered question trains the team to keep asking. If the state can't answer it, that's a gap to fix in the state.
- Test with the same-question check. Before cutover, the successor answers the customer's most likely questions from the account state alone, no leaver in the room. What they can't answer with a source is the remaining handoff work, made visible while the leaver can still fill it.
Handoff by document vs handoff by living state
- Spreadsheets + Slack. What the successor gets: Scroll-back archaeology across channels and trackers. Leaver's prep cost: None, which is the trap. Verifiable after departure?: Barely, threads lack conclusions. Freshness: Varies by team, decays silently.
- Handoff document. What the successor gets: A snapshot narrative. Leaver's prep cost: Hours to days during their busiest weeks. Verifiable after departure?: No, claims without sources. Freshness: Stale within weeks.
- Recorded walkthrough. What the successor gets: The leaver's narration on video. Leaver's prep cost: Hours. Verifiable after departure?: No, and it can't be queried. Freshness: Frozen at recording time.
- Living account state. What the successor gets: Source-linked answers to promised, decided, at risk, next. Leaver's prep cost: Marginal, state was maintained all along. Verifiable after departure?: Yes, every fact carries sources. Freshness: Synced from the event stream.
The bottom row is the one FDE teams using an account brain report. At Spendesk, "an engineer picks up any account and knows in five minutes what was promised and what's at risk. Nobody maintains anything," per Mathilde Hamy, Head of Customer Success and Account Management. Aircall describes the successor side: "We're seeing engineers confidently run rollouts they've never been on a call for. The memory belongs to the team, not the person," per Tom Chen, CPO at Aircall.
What stays manual
The relationship transfers by earned trust, not by runbook. The customer's confidence in the leaver took months to build, and the successor starts that from the paired call, not from zero, but not from parity either.
Judgment stays with people. The account state tells the successor a date is at risk. Whether to hold it, trade it, or escalate is theirs to learn, ideally with a senior nearby for the first hard call.
Curation stays human too. The leaver chooses what syncs from their sessions and notes into team memory, and anything an agent drafts (a brief, a risk summary) gets human approval before the successor or the customer relies on it. And the goodbye matters: the leaver telling the customer "you're in good hands, here's why" does more for continuity than any artifact.
The handoff is a pointer, not a package
Teams that treat handoffs as documents get rediscovery projects. Teams that keep account state alive from day one get handoffs that take a walkthrough and one paired call, whether the trigger is leave, pool graduation, or an acquisition. The runbook is short because the real work happens continuously, before anyone resigns or books leave. That continuous half belongs in your FDE operating system rather than in anyone's personal workflow.
See what a handoff looks like when the state is already live: book a demo and watch Tandem answer the successor's first ten questions, with sources, on one of your real accounts.
Before the FDE handoff comes the sales handoff. The five promises that fall out of the CRM before the SOW covers what to recover at kickoff.
FAQs
What should an FDE handoff document include?
Less than you think: a pointer to the living account state, a short delta of what the state can't hold (relationship texture, unwritten history), and open judgment calls with the leaver's recommendation. If the document exceeds a couple of pages, it's transcribing what a system should hold. The four questions (promised, decided, at risk, next) belong in queryable, source-linked form, not prose.
How long should an engagement handoff take?
With living account state, about a week: a risk walkthrough, a decision-log review, one paired call, and the same-question check. Without it, plan for weeks of overlap plus a rediscovery tail after the leaver goes. The duration is set by how much state was externalized before the handoff started.
How do we hand off accounts we inherited through an acquisition?
Treat it as a reconstruction, not a handoff, because the original builders are often gone. Pull whatever event stream survived (calls, tickets, email threads) into one account state, then have the inheriting FDE run the same-question check against it to find the gaps. Verify with the customer once, deliberately, instead of piecemeal over months.
What if the FDE has already left?
Then you're in the paternity-leave case: notes you can't verify. Rebuild from sources rather than from the notes, and use the notes only as a map of what to look for. It's slower than a real handoff, which is the argument for keeping account state alive on every engagement, starting now.
Can the successor trust AI-assembled account state in front of a customer?
Trust the sources, not the summary. A well-built account brain links every fact to where it came from, so the successor can verify before repeating anything to the customer. That's the practical difference between it and a handoff doc, which asks for trust without offering evidence.
Key terms
Engagement handoff: The transfer of a live customer engagement from one builder to another, triggered by leave, rotation, team structure, or acquisition. It fails when the engagement's memory lives in the leaver's head.
Bus factor: The number of people who can leave before a project stalls. On single-FDE accounts the bus factor is one, which is what a living account state exists to fix.
Pool graduation: The structural handoff in a 90-day ownership model, where a landed account moves from its founding FDE to a shared operating pool.
Handoff runbook: The repeatable procedure for a handoff. In this version: point at living state, walk the risks, transfer decisions with rationale, pair once, cut over, and test with the same-question check.
Living account state: Account context that's continuously synced from calls, Slack, and tickets, with every fact source-linked, rather than assembled into a document at handoff time.
Rediscovery: The weeks a successor spends re-deriving decisions and re-verifying facts after inheriting an account through unverifiable notes. The cost that makes document-based handoffs expensive.