Hand over the keyboard before you leave: how FDEs teach customer engineers to run the system

Imagine this Friday is your last day at the customer. The pipeline is running, the runbook is written and the demo drew praise. Six weeks later a vendor renames a column in a data file, the pipeline breaks, and the first person the customer messages is you.

On paper, that is still a successful delivery. In practice, the customer has bought a system it cannot keep alive.

Ertas AI, describing its approach to forward deployment, writes that the goal is not only to build the pipeline but also to transfer the knowledge needed to maintain it, and that this level of transfer requires working side by side rather than handing over documents.

For you, this is a skill that can be practised, and it decides whether the customer has to call you back for every small fault. What follows is a four-week plan, a sample pairing conversation and a way to measure whether the customer has become self-sufficient.

A runbook records commands, not judgement

Go back to the file with the renamed column. A runbook can state exactly the input schema, the command to rerun the job and where to request access. Those are facts. They should be written down, and from the start of the engagement.

But a runbook struggles with the questions that arise when an alert fires in the middle of the night. Can this fault wait until morning? Will rerunning the job help, or only repeat the failure? That judgement forms only when the customer’s engineer handles the problem personally.

Tandem, a vendor writing about handovers between FDEs, also argues that judgement does not pass through documents but is rebuilt through repeated practice; this is an opinion, not a measurement.

The facts, however, must not be left until the end. Also according to Tandem, when the person who built a system changes, the memory of the engagement leaves with them unless it was stored elsewhere from the outset.

Before treating a document as handed over, apply the test Len Holgate set out in 2004 when writing about handover in consulting: it has value only if the customer can maintain it and get value from it.

Holgate held that pair programming and collective code ownership help make code the responsibility of the whole team, so sharing a screen also serves this test.

Good coders are not automatically good teachers

Picture the customer’s engineer stuck on a log line while you spot the fault in ten seconds. The customer is paying for your time, so the natural reflex is to reach for the keyboard. At that moment, the fastest fixer in the room is also the worst at transferring knowledge.

That reflex does not fade as your coding improves. A study of pair programming presented at Software Engineering und Software Management 2018 concluded that knowledge transfer skills do not emerge automatically from good software development skills, but can probably be learned.

For a pairing session to be effective, according to the study, the expert still has to transfer knowledge.

So train it the way you train debugging. Three habits are worth practising: say your reasoning aloud before typing, ask before answering, and keep your hands off the keyboard while the other person is stuck. The last is the hardest, precisely because of those ten seconds.

Four weeks with an invoice pipeline

Take a hypothetical case: you have built a pipeline that reads invoice files from vendors, and An, the customer’s engineer, will take it over.

GitScrum’s handover guide suggests 2-4 weeks of overlap between the two teams, combining documentation and pairing sessions, with the receiving team leading in the final stretch and the departing team only advising.

That is a reference point rather than a standard; An has never touched this system, so you choose the longest option. In this example, those are the final four weeks before you withdraw, while the preparation has been under way since the start of the engagement: the successor’s name is agreed and the decisions already sit in a shared repo.

Overlap week	Who holds the keyboard	Your job	Evidence to move on
1	You, while An asks questions and writes the runbook	Say aloud the reason for each decision	An explains the data flow back in An’s own words
2	An, with you leading	Ask questions instead of dictating commands	An fixes a real bug unaided and opens a PR
3	An and teammates, with An leading	Advise only when asked	An’s team handles alerts on its own
4	The customer’s team	Supervise the trial run and take notes	The team runs end to end and handles a fault it has never seen

Week 2 is when the plan is most likely to break. Suppose the job fails while An has the keyboard, and you have already guessed the cause from the first log line. The conversation should go like this:

An:  The job failed. Shall I restart it?
You: Before you restart, which step do you think broke?
An:  The parse step. The log says the tax_code column is missing.
You: If you restart, what will be different on the next run?
An:  Nothing, the file is the same. I need to find out where the file came from.
You: Open the file, then. The keyboard is still yours.
An:  The vendor renamed the column. I'll add a mapping and a test for this file.
You: Put it in the runbook: symptom, how to check, how to fix. In your own words.

Had you simply said “add a mapping”, the bug would have been fixed faster, but An would have learnt only that when something breaks, you ask you. After the exchange above, An has reasoned it through from start to finish, and the runbook entry follows the thinking of the very person who will have to open it during an incident.

Count how often you have to speak up

The feeling that “An seems to have got it” is not enough to justify leaving. Keep a simple intervention log: each time you have to point the way or take back the keyboard, write one line with the date, the situation and the type of intervention.

Suppose the log for week 2 has 14 lines, 9 of them about whether to rerun a job. The 14 says little by itself, but the 9 tells you what to teach in week 3.

Week 3 is down to 5 lines; the trial run has just 1, not knowing where to request access. That last line is a gap in facts, so you add to the runbook; had it been a gap in judgement, you would need another round of practice.

The trial run is the final gate. Ertas states outright a success criterion that the team designated by the customer can operate the pipeline on its own, and tests it with a supervised trial run.

To make the trial worth something, do not just run the happy path. Deliberately plant, in a staging environment, a fault the team has never seen, such as an invoice file sent twice, and watch how they track down the cause.

Handover starts on the day scope is agreed

When you agree the scope, write the self-operation criterion into the plan and ask for the specific names of the people who will take over, along with the time they really have available. Then save decisions, assumptions and reasons to the shared repo as they arise, so that the memory of the engagement remains after you have gone.

In the middle phase, save real incidents for the customer’s engineers rather than quietly fixing them while they are away. Reread the intervention log every week and decide what to teach next. Move to the customer-led stage only when the evidence from the previous stage is in hand.

Four ways to ruin a handover

Heroic fixing is the easiest trap to fall into. Imagine you patch the problem overnight and the customer is delighted the next morning, but An’s chance to learn has gone. Leaving the transfer to the last few days is just as damaging, because the customer’s team then has time only to sit through presentations, not to do the work.

Teaching just one person is a quieter risk. If An resigns, the customer is back at the starting point, so rotate until at least two people have handled incidents on their own, in keeping with the collective code ownership Holgate mentions.

The remaining trap is treating the demo as proof of handover. A demo shows only that the system runs, not that the customer can keep it alive.

Turn it into evidence on your record

This skill is hard to see on a CV if all you write is “handed over the system”. State who took over, what they handled on their own and which measure shows it; the intervention log gives you real numbers to cite, even when they are less tidy than the example above.

When reading FDE job descriptions, look for mentions of knowledge transfer or enablement, and in interviews ask how long their customers typically take to operate on their own. The answer tells you whether the company measures success by the capability left behind or only by the ship.

An exercise for this week

Pick a colleague who knows little about part of your code, then pair for 60 minutes while they fix a real bug. You do not touch the keyboard, and each time you blurt out an answer instead of asking a question, write one line in the log.

At the end of the session, ask them to write the runbook entry for that bug themselves, then read it to see what is missing. The first time, you will be uncomfortable at how much everything slows down. That slowness should happen while you are still sitting beside them, because after you withdraw, the customer’s team will have to manage alone.