Somewhere between the resignation email and the farewell lunch, every leader of a forward deployed engineering team does the same silent math: how much of what keeps our customers running exists only in this person's head, laptop, and password manager?
For most teams the honest answer is "more than we can say out loud." An FDE departure is not a normal engineering departure. A product engineer leaves behind code in a shared repo, reviewed by peers, deployed by pipelines. An FDE leaves behind customer-specific builds scattered across accounts, credentials collected from customers over years of trust, deployment procedures that were never written down because there was never time, and relationships where the customer's team calls this engineer, by name, when something breaks. Software engineering has a term for concentrated knowledge risk, the bus factor: the number of people who can disappear before a project stalls. On many FDE teams, the bus factor per account is exactly one.
This playbook is the 30-day procedure for the day the math becomes real, plus the compressed version for a two-week notice, plus the architecture that makes the whole exercise boring next time. It pairs with our operating guide for FDE teams, which covers the rituals that prevent the emergency this article handles.
What is an FDE handoff? An FDE handoff is the transfer of a departing engineer's customer estate to a successor: every customer-specific build, its running version, its credentials, its deployment procedure, and its context, moved with nothing breaking and the customer's confidence intact. Done well it is an operation with a checklist. Done late it is an incident with a deadline.
Why FDE departures hurt more than they should
Three properties make this departure class uniquely dangerous.
The work is production, but it never lived in production systems. Customer builds frequently run from places your ops org does not see: a laptop cron job, a personal cloud instance, a script the customer runs on the engineer's instructions. When RAND interviewed 65 experienced AI practitioners about why projects fail, the root causes were overwhelmingly organizational, with underinvestment in deployment infrastructure on the shortlist. Departure day is when that underinvestment presents its invoice.
The credentials are the customer's, not yours. An FDE accumulates customer API keys, database access, and service accounts the way field engineers always have: whatever channel the customer used, wherever it was convenient to store. Each of those credentials is a promise your company made about care and custody. A departure with credentials in personal storage is a security event you have to disclose to yourself, and possibly to the customer.
The market moved the replacement cost. Backfilling the seat is neither fast nor cheap: Indeed puts FDE pay at roughly $170,000 to over $200,000, Bloomberry's median base is $173,816, and AI-lab total compensation runs $350,000 to $550,000, in a market where Bloomberry counted 1,165 percent year-over-year posting growth. Your successor may be months away. The estate cannot wait months.
Which is why the playbook's first principle is unromantic: transfer the artifacts first, the wisdom second. Wisdom transfer is lovely and lossy; artifact transfer is checkable. A successor with the builds, versions, credentials paths, and one verified deploy under their belt can reconstruct wisdom. A successor with two weeks of well-meaning conversation and no artifact map cannot deploy a fix.
Week 1: inventory and freeze
The moment notice is given, the goal is a complete map before anything else. Memory is the only index of an unmanaged estate, and memory is what is leaving.
Enumerate the estate. With the departing FDE, list every customer touched, and for each: every build, where it runs, what triggers it, what systems it talks to, and what breaks downstream if it stops. Ask the four questions that surface the forgotten pieces: What runs on a schedule anywhere? What did we ever install inside the customer's environment? What still runs from your machine or personal accounts? What would page you, and how would it reach you?
Map every credential. For each build: what secrets it uses, where each is stored, who else can access it, and when it was last rotated. Flag anything in personal storage for migration this week, not at exit.
Snapshot versions. For every build, capture the running copy, not just the repo copy, and note divergence. The gap between "the code" and "the code that is actually running at the customer" is where post-departure incidents live.
Freeze prudently. No new customer builds from the departing engineer during the notice period unless a deal depends on it. Every new artifact created now is another item on this list, created by the person least available to support it.
If the estate already lives on a platform, week one is an afternoon: the inventory is a screen, the credentials are vaulted, and the versions are retained by construction. If it lives on laptops, week one is the hardest week, and also the exact argument for never doing it this way again.
Week 2: transfer
Assign successors by account, in writing. One name per customer, even if interim, even if it is the team lead. Ambiguity here becomes a dropped customer later. If the team is at capacity, this is the week to decide what temporarily downgrades, deliberately rather than by silence.
Move the artifacts to organizational custody. Builds to the team's platform or repos, credentials into vaulted storage, documentation into the shared system. The standard is simple: on the last day, nothing anyone needs lives anywhere personal.
Run walkthroughs per account, recorded. One session per major customer: the departing FDE walks the successor through each build against the live inventory, including the folklore, meaning the quirks, the fragile dependency, the contact who must be warned before restarts. Recording is not optional; successors reference these for months, and the recordings become the seed of the account runbooks that should have existed already. This is the highest-value knowledge capture your team will do all year, and the techniques in our tribal knowledge guide apply directly.
Tell the customers, correctly. Customers who work closely with an embedded FDE notice departures. The message that maintains confidence has three parts: the named successor, the custody fact (their integrations, history, and access live on your platform, and the successor is already assigned), and an early proof point, ideally the successor shipping something small within two weeks. What destroys confidence is silence followed by a stranger on the next incident call.
Week 3: verify
A handoff is not done when the documents are written; it is done when the successor has operated each account without the departing engineer in the loop.
The redeploy test, per account. The successor makes one small, safe change to a real build and ships it end to end: find the current version, modify, deploy, confirm. This single exercise validates the entire chain: inventory accuracy, access paths, deploy procedure, and the successor's practical readiness. Any account where the redeploy test fails gets escalated this week, while the departing engineer can still answer questions.
The failure drill, on the riskiest account. Simulate the most likely incident: the integration stops, the customer emails. Can the successor diagnose from logs and history alone? If the diagnosis requires calling the person who left, the handoff has a hole exactly where it will be tested first.
Close the credential loop. Rotate what should be rotated, revoke the departing engineer's access on both your side and, where applicable, the customer's side, and record it. If credentials sat in zero-access custody all along, this step is administrative. If they sat in personal storage, this step is the security review you are performing under deadline, which is the most expensive way to perform one.
Week 4: close and learn
Final knowledge sweep with the departing engineer against the open-questions list from weeks two and three. Update the account runbooks from the recordings. Then run the retro that matters, with one question on the agenda: how much of this month was transfer, and how much was archaeology? The archaeology fraction is your operational debt, measured precisely. Feed it into the estate review and the quarterly handoff drills described in the team operating guide, because the cheapest time to fix the next departure is now, while the cost is vivid.
When there was no notice at all
Sometimes the playbook starts after the person is gone: a same-day departure, a termination, or the discovery that the engineer who left last quarter still had things running. The cold-start variant changes the order of operations, because you no longer have the one resource every step above assumed, the departing engineer's memory.
Secure first, understand second. Rotate or revoke every credential the engineer could have touched, on your side and the customer's side, before mapping anything. In a cold start you cannot verify what personal storage held, so you assume exposure and reset. It is disruptive, and it is cheaper than the alternative disclosure conversation.
Reconstruct the estate from evidence, not memory. Four sources, in order of yield: the platform or repos, whatever was sanctioned; cloud billing and audit logs, which reveal compute nobody remembers; the customer's own team, who often know exactly what runs where because they live with it; and the departed engineer's calendar and messages for the accounts they touched most. Expect the customer conversation to be the most productive and the most delicate: frame it as a proactive continuity review, not an admission.
Triage by blast radius. You cannot verify forty builds at once. Rank accounts by revenue and by what fails visibly if a build stops, run the redeploy test on the top five first, and accept documented ignorance on the tail while working through it.
A team that has lived one cold start never argues about custody architecture again. It is the most expensive form of persuasion available.
The manager's one-page checklist
For the version that survives contact with a real week, the playbook compresses to fifteen boxes:
Week 1: estate enumerated per account · credentials mapped and personal storage flagged · running versions snapshotted · build freeze agreed. Week 2: successors named in writing · artifacts in org custody · walkthroughs recorded per major account · customers notified with successor and proof point. Week 3: redeploy test passed per major account · failure drill run on riskiest account · credentials rotated and access revoked, both sides. Week 4: runbooks updated from recordings · open-questions sweep done · retro held with archaeology fraction measured · risk register updated with what was not covered.
Print it, run it, and time it. The timing is the point: this checklist run against a managed estate takes days; against laptops it takes the whole month, and the difference is your operational debt expressed in calendar time.
Handoffs that are not departures
The resignation is only the loudest member of a family. Four quieter handoffs deserve the same machinery, and teams that treat them casually rehearse bad habits for the real one.
Promotions and role changes move an FDE off accounts with everyone smiling and nobody scheduling the transfer, because the person is still in the building. Six months later they are a senior leader still fielding deploy questions for accounts they nominally left. Run the playbook's weeks two and three exactly as if they had resigned; their continued presence just makes the walkthroughs easier to schedule.
Leaves of absence are handoffs with a return date. The difference is the freeze: builds keep evolving, so the returning engineer needs a reverse-handoff of what changed, which the estate review from the operating guide provides for free.
Planned rotations are the drill made routine: moving one account between FDEs annually keeps context spread and proves the machinery works while nothing is at stake.
Team-level events, an acquisition, a reorganization, a layoff, run the same playbook at multiplied scale, and they arrive with the least warning and the worst morale conditions for careful work. A team whose estate is organizationally owned can execute ten simultaneous handoffs as administration; a laptop-era team executing ten at once is having an outage in slow motion.
Scoring your readiness before you need it
The quarterly drill produces the only number that matters, but a five-question self-audit approximates it between drills. For your riskiest account: Can anyone but the owner list its builds in five minutes? Can a successor reach every credential without asking the owner? Does the running version match the retained version? Has anyone but the owner deployed a change in the last quarter? Would the customer recognize a second name from your team? Score a point each. Five is readiness; three is exposure; below three, the resignation email has already been written by someone, and you are betting the account on when it sends.
The two-week compression
Half the notice, same priorities, ruthless cuts. Days 1 and 2: full inventory and credential map, nothing else. Days 3 to 7: artifact migration and recorded walkthroughs for the top accounts by revenue and risk; written notes only for the tail. Days 8 to 10: redeploy tests on the top accounts, customer notifications with named successors. Days 11 to 14: credential rotation and revocation, final Q&A sweep, and an honest written list of what did not get covered, handed to the team lead as a risk register rather than discovered as a surprise.
What gets cut is depth on small accounts. What never gets cut: the inventory, the credential loop, and at least one verified redeploy per major account. Those three are the difference between a bumpy month and a customer-facing incident.
The customer's side of the transition
Everything above manages your half. The customer is running a parallel process you should make easy, because how you handle their half decides whether the departure costs you trust or banks it.
Their security team may need to re-verify. If the departing engineer held named accounts or credentials in the customer's systems, their side has its own revocation to do. Arrive with the list: here is every access our engineer held with you, here is what we recommend rotating, here is our confirmation of what we rotated on our side. Handing a customer their own cleanup checklist is a small gesture that reads as competence for years.
Their change calendar constrains your verification. The redeploy test from week three touches live systems, and enterprises have freeze windows, approval boards, and quarter-end lockdowns. Schedule verification with their calendar in week two, not against it in week three.
The introduction is a meeting, not an email. Put the successor in front of the customer's team while the departing engineer is still present to transfer trust explicitly. Thirty minutes, three agenda items: what is running today, what is planned next, and who to call for what. Trust transfers by demonstration, and this meeting is where the customer decides the transition is real.
Handled this way, a departure becomes a strange kind of proof point. The customer watched an engineer leave and nothing broke, nobody scrambled, and the new name shipped within two weeks. That story gets retold internally at renewal time, and it is a story about your organization rather than any individual, which is exactly the impression a vendor wants to leave.
The successor's first month
The playbook ends at verified transfer, but the successor's trajectory deserves its own paragraph, because how their first month goes decides whether the accounts merely survived or actually recovered. Three moves serve them. Ship something small into each inherited account within two weeks, even a minor improvement: it converts the walkthrough knowledge into operating confidence and shows the customer the machine still works. Re-run discovery lightly, one conversation per account asking what is working and what they have been waiting to ask for: departures create a natural moment to surface deferred requests, and successors who harvest it often close more new work in month one than the account saw in the prior quarter. And rewrite one runbook from scratch in their own words per major account: the act of rewriting is how inherited knowledge becomes owned knowledge, and it flushes out the gaps the recordings papered over while the departing engineer is still one polite message away.
Managers should protect the successor's capacity accordingly: an inherited book is a full plate for a month, and stacking new-deal work on top of it is how a clean handoff turns into a slow-motion drop anyway.
Prevention: make the playbook unnecessary
Everything above is the expensive version of a property you can simply buy: an estate that transfers because it was never personal in the first place.
That is the design argument for running FDE work on a platform. On Archway, every customer build is a bridge: a serverless function connecting the product to one customer's systems, deployed in minutes, credentials in an AES-256 vault with zero-access custody so engineers reference secrets but never see values, every version retained and owned by the organization. Handoff in the product is same-organization reassignment plus a note: you reassign the departing engineer's bridges, the versions stay, and the successor inherits the running estate with context attached. The 30-day playbook in this article is editorial advice, not a product package. Against an org-owned estate it collapses into an afternoon: reassign, leave a note, walk through the folklore, done. Week one's archaeology does not happen because there is nothing to excavate; week three's credential scramble does not happen because there was never personal custody to unwind.
Two related disciplines complete the prevention posture. Choose the ops backbone deliberately, using the full platform comparison, rather than inheriting whatever the first engineer improvised. And rotate one account between FDEs annually even without departures: rotation is a live-fire handoff drill that also spreads customer context, and teams that rotate discover their gaps on a calendar instead of a countdown.
The engineers who do this job are in the highest demand of their careers, which means departures are not a tail risk; they are a schedule. You do not get to choose whether handoffs happen. You only choose whether they are operations or emergencies. If you want them to be operations, see what Archway does; the first two bridges are free, and one real account moved this week is the whole proof.
Sources and notes
-
Wikipedia, "Bus factor": the standard term for concentrated key-person risk in software teams. https://en.wikipedia.org/wiki/Bus_factor
-
RAND, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed": 65-practitioner study; organizational root causes including underinvestment in deployment infrastructure. https://www.rand.org/pubs/research_reports/RRA2680-1.html
-
Business Insider (syndicated on AOL): Indeed pay range for forward deployed engineers. https://www.aol.com/articles/job-postings-tech-role-grown-185134480.html
-
Paraform, "How to hire a forward deployed engineer": Bloomberry median base salary of $173,816, Bloomberry posting growth of 1,165 percent year over year, and AI-lab total compensation of $350,000 to $550,000. https://www.paraform.com/blog/forward-deployed-engineer-demand-quadrupled
-
Archway product claims are first-party and match the published product facts at https://www.tryarchway.ai/llms.txt.
