Lesson 5.4: Handing over without being on call forever
A solution only you can run is a dependency, not a delivery. Learn to plan the handover from week one, transfer skills in stages and set the support terms.
By the end of this lesson you will be able to plan the handover of a customer system from the first week of the project, build a package of what the customer's team needs, move responsibility to them in four stages, agree a support model that says who does what and for how long, and test that the handover has worked. You will learn a checklist of what to hand over, a way to spot the knowledge that lives only in one head and a plain method of stepping back without leaving the customer exposed. You will see three handovers, including one that left a gap, and use a simulator to estimate how long it takes to reduce your involvement to a sustainable level. This lesson closes Module 5, on deploying and operating. It follows 5.3, where you made the system visible and wrote runbooks. Here you decide who runs it afterwards. You need no special background.
Every forward deployed engineer eventually faces a quiet temptation. The system works, the customer is happy, and you are the person who understands it best. When something goes wrong, they call you, and you fix it in ten minutes, to general delight. It feels like success. It is a slow trap. Each fix teaches the customer that the system is yours, not theirs. Your time fills with small requests, you cannot take on the next customer and, if you leave, the system becomes a risk. Lesson 1.1 listed "becoming the permanent operator" among the common mistakes. This lesson is how to avoid it.
What handover is for
The aim of a handover is simple to state and hard to do: the customer's own people can run, fix and improve the system without you, and they know when and how to call for help. It is not about disappearing. Your company may still provide support, fixes and new features. It is about moving day-to-day ownership to the people who will live with the system for years.
There are three reasons to take it seriously.
It is part of the result. In Lesson 1.1 you learned that the engineer is finished when the customer's people are getting value from something running in production. A system that the customer cannot keep running is not a result. It is a loan.
It protects the customer. If the only person who understands the system leaves, falls ill or moves to another project, the customer is left with something nobody can operate.
It protects you and your company. An engineer tied to one customer cannot start the next, and a company that must send a person for every small issue cannot grow. Good handovers are what let the model scale.
Why handovers fail
Handovers fail for understandable reasons, and knowing them helps you plan against them.
Knowledge lives in one head. The most important facts, such as why a field is handled in a particular way or how to restart the job after a failure, were never written down.
The customer's team has no time. They have their own work, and training on a new system is the first thing to be postponed.
No one is named. "The IT team will look after it" means nobody in particular. A system with no named owner is, in practice, owned by whoever built it.
It is left to the end. Handover planned in the last week is rushed, and the customer receives a pile of documents and a day of training.
The incentives point the other way. Being the indispensable expert is comfortable. It takes a conscious decision to make yourself less needed.
The system is too complex for the team. A design that needed skills the customer does not have was, in hindsight, a design error, as Lesson 4.2 warned when it asked who will keep it running.
The common cure is to treat handover as part of the project from the first week, not an activity at the end.
Plan it from week one
In the first week, when you write the one-page plan, add a short handover section. It should answer four questions.
1. Who will own this? Name a person or a team on the customer's side who will run it day to day. If there is nobody, that is a project risk to raise with the sponsor now.
2. What will they need to be able to do? List the tasks: deploy a release, restart a failed job, read the dashboard, handle an alert, add a user, change a rule, restore from backup.
3. What do they need to know? The skills and the knowledge, such as the architecture, the data, the runbooks and the access arrangements.
4. What does "done" look like? A test that shows the handover has worked, such as "the customer's team has performed a release and handled a practice incident without help".
Revisit this section every few weeks. As the design settles, the list of tasks becomes clear, and you can begin to teach them while you build. A useful habit is to involve the future owner from the start: have them sit in on demos, review the code and the runbooks and take on small tasks early. People learn a system best by working on it, and someone who helped to build it is far better placed to run it.
Spotting knowledge that lives in one head
Before handover, look for what only you know. A simple exercise finds it. List everything that might go wrong or need doing, and next to each write who could do it today if you were unavailable for a month. A row with only your name is a gap. Typical gaps include:
a manual step in a monthly process that nobody else has done;
the reason behind an odd rule, such as a hard-coded exception;
the location of a password, a certificate and its renewal date;
how to restore from a backup, which nobody has ever tried;
the contact at a partner who can resolve a problem quickly.
Close each gap by writing it down, teaching it to someone else, or both, and by testing that the other person can do it. This idea is often called the bus factor: how many people could be lost before the project stops. A bus factor of one, with you as the one, is exactly what a handover must remove.
Predict first: two weeks before go-live, you learn that the one analyst on the customer's side who understands the data is about to go on three months' leave, and she is the person you had planned to hand over to. What do you do? Decide before reading on.
Treat it as a project risk and act at once. Tell the sponsor, plainly and early, what the leave means for the handover. Identify a second person who can learn the system, and pair them with the analyst for the two remaining weeks, with the analyst walking through the data and the checks while someone records it. Update the runbooks with what she explains, and ask her for a list of contacts and rules that nobody else knows. If the date cannot move, agree a temporary arrangement, such as a longer support period from your side, with a written end date. The error to avoid is to proceed on the original plan and hope.
The bus factor can be put in numbers. If each person who can run the system has some chance of being unavailable in a given month, the chance that nobody can run it in at least one month of the year falls steeply as you add people. Try it.
At the defaults, with one trained person who is unavailable in 8 per cent of months, there is about a 63 per cent chance of at least one month in a year with nobody able to run the system. With a second trained person it falls to about 7 per cent, and with a third to under 1 per cent.
What to hand over
A good handover package has a few well-chosen items. Resist the urge to hand over everything, as a heap of documents helps nobody. Each item should be short, current and useful to someone running the system.
Item · What it contains · Who uses itOne-page overview · What the system does, who uses it, the main parts and how they connect · Everyone
Architecture and data map · The diagram from Lesson 3.1, with the systems, owners and flows · Platform team
Runbooks · One per important alert or task, from Lesson 5.3 · The on-call person
Release guide · How to build, release and roll back, from Lesson 5.2 · Engineers
Access and secrets list · Who has access to what, how secrets are stored and rotated and when certificates expire · Security and platform team
Monitoring and dashboards · What is watched, what the alerts mean, and the target and its budget · The on-call person
Known issues and shortcuts · The list from Lesson 4.1, updated, with what remains to be hardened · Engineers and the sponsor
Decision log · Why key choices were made, such as build or buy, so they are not repeated · Everyone
Contacts and escalation · Names for each kind of problem on both sides · Everyone
Keep the package in a single place the customer owns, such as their document system or code repository, not on your laptop. And date every document, so that people can tell when it was last checked.
Four stages of handing over responsibility
Responsibility should move in steps, with each one tested before the next. A common and effective sequence has four stages.
1. You do it, they watch. You perform each task, for example a release or the handling of an alert, while the customer's team observes and asks questions. They see the real thing, on the real system.
2. You do it with them. They do the task with you beside them, following the runbook. You correct and add what is missing from the written guide.
3. They do it, you watch. They perform the task alone while you observe, intervening only if something would go wrong. This is where confidence forms and gaps appear.
4. They do it alone. You are available for questions but do not take part. You check afterwards, reading what they did and the results.
Move through the stages task by task. They might be at stage four for restarting a job and at stage two for a release. A schedule that sets out which tasks reach which stage in which week keeps everyone honest and makes progress visible to the sponsor.
The final test of the handover is a drill without you: the customer's team performs a real release, handles a rehearsed incident and restores from a backup, with you absent or silent. What they cannot do shows what is missing. It is better to find out in a drill than in a real incident.
The support model
Handing over does not mean that nobody helps again. It means agreeing in advance who helps with what. A support model describes this in a short document, and a customer who has one feels safer than one who has only a promise to "be in touch".
A typical model has three levels.
Level one: the customer's users and local contact. Questions about how to use the system, access requests, simple issues. Handled by a named person in the customer's team, using the guide.
Level two: the customer's platform or technology team. Operating the system: alerts, restarts, releases, configuration, data problems. This is the team you handed over to.
Level three: your company. Defects in the product itself, issues beyond the customer's team's reach and new development. Contacted through an agreed channel, with agreed response times.
For each level, write who it is, what it covers, how to reach it, the hours and the expected response. Add how problems are escalated up the levels, and when. If your company provides support under a contract, state what is included and what is not. If there is a warranty period after go-live, in which you fix defects at no extra charge, state its length and its end date.
A clear model protects both sides. The customer knows where to go, and you know what you have promised. It is also your answer to the question "can you just have a quick look at this?" which arrives, in various forms, for as long as you let it. The answer is "yes, through the support route, which gets you a response within the agreed time" and not "yes, I will do it now". Politely and consistently pointing to the route is how you stop being on call forever.
Stepping back gradually
You will not go from full involvement to none overnight, and you should not. A planned step-down works better.
Taper the hours. Reduce your involvement in steps, from full-time to a few days a week, to a few hours a week, to on-call only for defects.
Set the end date early. Agree the point at which day-to-day support moves to the customer's team, and say it in the plan. A date that is known gives everyone a reason to prepare.
Keep a short tail. For a period after handover, such as a month, be reachable for questions and check in weekly, then monthly. Most problems after handover come in the first weeks.
Measure the questions. If the customer's questions to you are falling and getting more advanced, the handover is working. If the same questions repeat, the documentation or training has a gap.
Automate the repeat requests. If you find yourself doing the same manual task for the customer every week, automate it or write a runbook for it. Anything you do repeatedly is a candidate for a tool.
The pace of the step-down depends on the system's complexity and the customer's skills, but its shape is usually a steady fall that levels off. The simulator below helps you plan it.
How long will the step-down take?
You can estimate the time it takes to reduce your involvement. Suppose that each week your hours fall by a fixed share as the customer team takes over more, such as a quarter of the previous week's figure. Your hours then decline in a curve that begins steeply and levels out, and you can calculate the week at which you reach a sustainable level.
The simulator below does the sum. Set your current weekly hours on the system, the share by which they fall each week, the sustainable weekly level you aim for and your cost per hour. It shows the weeks to reach the target, the total hours you spend on the way and the cost, and plots the curve against the target.
The model assumes a steady proportional fall, which real handovers only roughly follow. They come in steps, with pauses and setbacks. But it gives you a defensible estimate for the sponsor, and it shows an important fact: the pace of the fall matters much more than the starting point. A handover that reduces hours by 10 per cent a week takes far longer than one that reduces them by 30 per cent.
Try three experiments. First, keep the defaults and read the weeks and total hours. Second, change the weekly fall from 25 to 10 per cent and see how the time doubles or more. Third, lower the target from 2 to 1 hour a week and see how a small change in the target adds weeks.
At the defaults, hours of 30 a week falling by a quarter each week reach 2 hours a week in about 9.4 weeks, and the total spent on the way is about 112 hours. If the fall is only 10 per cent a week, it takes about 26 weeks and 280 hours. The practical message is to invest early in the customer's team, because every week of delay compounds.
Worked example 1: the lender's four weeks
The lender's reminder system goes live, and the engineer's handover plan, written in week one, now runs. The owner is the collections operations team leader, with one analyst as the second person. The task list has six items: release a new version, restart the nightly load, read the dashboard, handle the "no reminders sent" alert, add or remove a user and restore from backup.
In week one, the engineer does all six while the team watches, and records the steps. In week two the team does the first three with the engineer beside them, and the runbooks are corrected where steps were missing. In week three they do the first four alone while the engineer watches, and the engineer does the others. In week four the team runs a drill without the engineer: a release, a simulated late file and a restore. The restore step fails, because a permission was missing, and it is fixed the same day.
By week six the engineer is spending two hours a week on the system, mostly answering questions, and the customer team has handled two real alerts alone. The handover plan, the drill and the early start are what made it work. The same system handed over in the last week would have left a team that had never touched it.
Worked example 2: the hospital's IT team
The hospital group's central IT team will run the bed screen. They are capable, but their experience is with their own electronic records system, not with the reporting tool or the pipeline the engineer built.
The engineer's handover begins with a two-day workshop, in the third week of the pilot, on the architecture and the data, using the map from Lesson 3.1. Two members of the IT team then join the weekly demos and review each change before release. The runbooks are written with them, in their words, and one of them performs the first real release under supervision in week six.
A potential gap appears. The monthly release window, on the first Sunday, means that the team gets only one chance a month to practise a release. The engineer agrees with them to rehearse each release in the test environment the week before, so that the real one is the second time they do it. The monthly rhythm also becomes part of the support model: urgent fixes follow an emergency procedure with the change board's approval.
Worked example 3: the handover with a gap
A retailer's order suggestion system is handed over to the replenishment team. The engineer writes a good guide and trains the team leader, a capable analyst, in two sessions. At go-live, everything is documented.
Two months later, the team leader is promoted into another role. Nobody else was trained, and the guide, though accurate, was written for the analyst who knew the ordering process. A routine failure of the nightly job goes unnoticed for four days, since no one is watching the alert, and stores order from stale suggestions. By the time the engineer is called, the retailer's regional managers are angry.
The review finds the gap: the handover was complete on paper and had a bus factor of one. No second person was trained, no named successor was agreed, and the support model had no rule for what happens when the owner changes. The fix is a second trained person, a quarterly check of who owns the system and an alert that goes to a shared mailbox, not to one person. The lesson is that a handover is a state to maintain, not an event to complete. The ownership must be checked from time to time, because people change roles.
Feeding back to the product
One more thing happens at handover, and it connects to the loop in Lesson 1.1. Before you leave, record what you learned for your own company: the custom pieces you built, the workarounds, the problems that came up more than once and what the customer valued most. This is the "feed back" step of the loop, and it is the point of the whole model.
Write a short account for the product team: what the customer needed, what you built, which parts could be general features and what you would do differently. Offer your custom code for review, with a note on what is specific to this customer. The best forward deployed engineers leave behind not only a working system, but a clearer view for the company of what to build next, and in the next project, they spend less time rebuilding what is now a feature.
Common mistakes
Planning handover last. Start in week one, with a named owner and a definition of done.
No named owner. "The IT team" is nobody. Name a person and a second person.
A bus factor of one. Find what only you know, and write it down and teach it.
A heap of documents. Hand over a short, current, useful package in a place the customer owns.
Handing over in one go. Move responsibility in four stages, task by task.
Skipping the drill. Test the handover by having the customer's team perform a release, an incident and a restore without you.
A vague support promise. Write a support model with levels, contacts, hours and an end date for any warranty.
Being the hero. Quick personal fixes teach the customer that the system is yours. Point to the support route.
Treating handover as finished. Check ownership from time to time, because people change roles.
Leaving without feeding back. Tell the product team what you learned.
Key takeaways
The aim is that the customer's own people can run, fix and improve the system, and know when and how to call for help.
Plan handover from week one: a named owner, the tasks they must do, what they need to know and a test that shows it has worked.
Find knowledge that lives in one head, close each gap by writing and teaching, and aim for a bus factor above one.
Hand over a short package: overview, architecture and data map, runbooks, release guide, access list, monitoring, known issues, decision log and contacts.
Move responsibility in four stages: you do it, you do it with them, they do it with you watching and they do it alone. Test with a drill without you.
Agree a support model with levels and response times, taper your hours with an end date, and feed what you learned back to the product team.
Check yourself
1. State the aim of a handover in one sentence.
The customer's own people can run, fix and improve the system without you, and know when and how to call for help.
2. What is the bus factor, and why must a handover raise it above one?
The number of people who could be lost before the project stops. With you as the only person who knows, the customer is at risk if you leave.
3. Name the four stages of moving a task to the customer's team.
You do it and they watch, you do it with them, they do it with you watching, and they do it alone.
4. Your hours are 40 a week, falling 20 per cent a week, with a target of 4. Roughly how many weeks, and how many total hours?
Weeks: ln(4 ÷ 40) ÷ ln(0.8) is about 10.3. Total hours: (40 − 4) ÷ 0.20 = 180.
5. A customer asks you to "just have a quick look" at a small issue. What is the best response, and why?
Point to the agreed support route, which gets a response within the agreed time. Quick personal fixes teach the customer that the system is yours and keep you on call.
Try this
This exercise takes about forty minutes and gives you a handover plan. Use a system you built, a project you know or an imagined one such as a nightly data load for a small company.
1. Name the owner and a second person on the customer's side. If you cannot, write who you would ask and what you would say to the sponsor.
2. List the six to ten tasks they must be able to do, such as release, restart, read the dashboard, handle the main alert, restore from backup and add a user.
3. For each task, write who could do it today if you were away for a month. Mark every row with only your name.
4. Close the three most important gaps: write the steps, name who will learn it and how you will test it.
5. Write a four-stage schedule showing which stage each task reaches in which week.
6. Draft the support model in a table: three levels, who, what, how to reach and expected response.
7. Use the simulator to estimate the weeks and hours of your step-down, and write the end date.
8. Design a drill: the three things the customer's team will do without you to prove the handover worked.
A good result is a one-page handover plan with named owners, a task list, a gap list with fixes, a four-stage schedule, a support model and a drill. It completes Module 5: you can now decide where a system runs, release changes safely, see what it is doing and hand it over. Module 6 turns to the other half of the role, communicating with customers.
Sources
The three handovers, the hours, the schedule and the simulator's figures are the author's illustrations for teaching, not data from real projects. The four stages of handing over, the handover package and the support levels are practical methods written for this lesson. The idea of the bus factor and of blameless accounts is widely used in software teams and is explained here in the author's own words.
Tags: Forward Deployed Engineer Handover Support model Documentation Customer success