# When an FDE changes mid-project: hand over the client's trust, not just the repo

> Code can change hands in an afternoon, but a client trusts the new engineer only once that person has proved themselves, and the handover has to be designed around that.

Original: https://fdetimes.net/en/guides/fde-mid-project-handover-client-trust/

Picture the scene. You are six weeks into a data integration project when your company moves you to another client. You push your code, write a long README and post a goodbye in the shared Slack channel. Three weeks later, your successor is asking the client the questions you asked in week one.

Tandem's piece on its FDE handover runbook describes exactly this failure. The project does not collapse. It quietly restarts, while the client still believes it is halfway there. To the client, it feels as though their money and time have just been charged twice.

You do not always get to choose when you leave a project. So the skill is not avoiding a change of engineer; it is handing over in a way that does not leave the client feeling pushed back to the start. The hardest part of that is not in the code.

## Why a long document won't save you

The engineer's first instinct is to write a lot. But Tandem points to a weakness: a handover document is a snapshot of one moment, and once its author has gone, nobody can verify it. A week later, half its lines may be wrong, and the newcomer has no way of knowing which half.

Their alternative: hand over a link to an account record that stays current, plus a short delta. The links point to the ticket board, the account record and the repo, the places that keep being updated after you leave. The delta is what exists only in your head.

PostHog's handbook sets a similar rule for any information others will need to find again. It belongs in a durable deliverable, not in a private Slack message or a thread nobody can trace later. Work still to be done goes down as explicit tasks, not buried in paragraphs of prose.

## Who really owns the relationship?

Before writing the delta, you need to know what you are handing over. According to PostHog's handbook, the FDE owns the technical outcome, while the commercial relationship stays with sales and CS. When the technical work is complete, the FDE hands the relationship back to the account owner and records what was built and why.

That rule covers the end of a project, but it suggests something useful for a mid-project change too: the account owner holds the commercial relationship throughout.

So a mid-project handover usually involves three parties, not two: you, your successor and the account owner. If the account owner is missing, the client can easily hear two different versions of who is looking after them.

## What does a delta look like?

Back to a hypothetical example. Lan is an FDE integrating a logistics company's warehouse management system with her company's product. Minh takes over the project next Monday. Lan's handover has two parts.

The links section is only a few lines: the account's ticket board, the account record in the CRM that CS manages, the repo and the page that logs technical decisions. Lan does not copy the contents of any of these, because copying them would create one more snapshot that will soon go stale.

The delta follows Rocketlane's advice for handovers between CSMs: record commitments, blockers and risks. Then come the tasks.

| Item | Example from Lan's delta |
|---|---|
| Commitments made | Promised the head of operations a trial run of the inventory sync before the end of the month |
| Blockers | The client's IT team has not yet granted read access to the returns table; the person to chase is the system administrator |
| Risks | The head of operations was once let down by a previous vendor's missed deadline, so is very sensitive to schedule slips |
| Next tasks | Three tickets created, each with an owner and a due date |

The "risks" row matters most. The code will never tell Minh that the main user dreads delays, yet that detail decides how Minh should open the first call.

## The call the newcomer must lead

Documents transfer only information. Tandem's piece says that relationships are transferred through earned trust, not through a runbook. So they advise introducing the successor on a single call, in which the incoming engineer leads and the departing one only observes.

At first this sounds backwards, since the client knows the departing engineer. But if Lan talks throughout the call, the client will keep treating Lan as the point of contact and message her privately afterwards. When Minh restates the end-of-month commitment himself, the client sees that the newcomer has a grip on the work. That is the moment trust starts to build.

An opening script for Minh might go like this:

> **Lan:** "From next week Minh will be running the integration. I'm moving to another project, and Ha in CS remains your contact for the contract, as before."
>
> **Minh:** "I've gone back through all the tickets. As I understand it, the goal is a trial run of the inventory sync before the end of the month, and we're blocked on read access to the returns table. Have I got that right?"

Lan's line does what Rocketlane recommends: tell the client why there is a change. Minh's confirming question turns the delta into something the client can verify on the spot, which is exactly what a document alone cannot do.

## Steps to take

Start by telling the client early. ClientSuccess advises introducing the new person as soon as possible to avoid confusion later, because the way a handover is done shapes the whole long-term relationship. A week's notice beats an email sent on your last day.

Next, the departing engineer writes the delta personally. Rocketlane stresses that the document must be prepared by the person handing over. Then clear out your Slack DMs and move every promise into a ticket. Then hold the three-way call with the newcomer leading. Finally, confirm with the account owner that they know who is handling the technical work.

**Key point:** Documents transfer information, but the newcomer has to earn trust in front of the client.

## Common mistakes

The most common mistake is treating the handover as done once the code is merged. Next comes the departing engineer dominating the introduction call to avoid silence, making the newcomer look like an assistant. Harder to spot is the departing engineer still answering the client's private messages after moving on, so the relationship never really changes hands.

One more mistake is forgetting the account owner. FDEs easily treat a handover as a matter between two engineers, when the person holding the commercial relationship needs to know first.

## How this skill shows up on your record

Have a concrete story ready in case an interview asks how you once left a client mid-project: how you wrote the delta, who led the call, and whether the project kept to schedule.

On a CV, a line such as "handed over an account mid-project to a successor without slipping any committed milestone" shows you understand a part of the job few people teach.

When reading job descriptions, look for phrases such as "ownership", "handover" or "working with CS". They hint at whether the company separates technical work from the commercial relationship. Ask about it directly in the interview.

When a project is handed over well, the client barely notices the change of engineer. They simply see that the end-of-month milestone is still intact.

**Try this week:**

- Pick a project you are working on and draft a handover delta under four headings: commitments made, blockers, risks, next tasks. No more than five lines per heading.
- Go through your Slack DMs with the client from the past two weeks and move every decision or promise in them into a ticket or the account record.
- Rehearse the opening of an introduction call with a colleague: you play the incoming engineer and speak first for the first five minutes.

## Sources

- [FDE handoffs: keeping an engagement alive when the builder changes](https://usetandem.ai/blog/fde-handoff-runbook)

- [Working with customers - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/working-with-customers)

- [Working with sales and CS - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/working-with-sales-and-cs)

- [Transitioning clients between CSMs](https://www.rocketlane.com/blogs/transitioning-clients-between-csms)

- [How Customer Success Teams Should Navigate the Complexities of Customer Handoffs](https://clientsuccess.com/blog/customer-success-teams-navigate-complexities-customer-handoffs/)