How to Hand Off So the Customer Can Run It Themselves
When can an FDE actually leave? There are two ways to exit, and the outcomes couldn't be more differ…
Unhappy the land that needs heroes.
— Bertolt Brecht, Life of Galileo
When can an FDE actually leave? There are two ways to exit, and the outcomes couldn't be more different.
The first is a graceful exit: acceptance passes, the celebration dinner wraps up, the engineer withdraws. Three months later, nobody at the customer mentions the system anymore, and the monitoring dashboard is a wall of green — not because the system is running, but because nobody is using it anymore.
The second is also a graceful exit: the same process, but six months later, in the customer's internal quarterly meeting, the discussion is "let's have the agent take over two more steps next quarter" — nobody calls it "the AI project" anymore. It has grown into the work itself.
The two exits look identical on the day they happen. The difference only shows up later, and every action that decides which one you get happens before the exit itself. This chapter takes up delivery's final stretch: what does handing a system over for the customer to run on its own actually have to accomplish before delivery counts as done?
I. Delivery Has Three Stages — the Acceptance Sheet Only Covers One
Traditional project management defines "delivery complete" as one signed acceptance sheet. But delivery actually runs in three stages: acceptance — the system meets the agreed-upon criteria (Chapter 8); adoption — real users are actually using it (Chapter 15); handoff — the customer can run, maintain, and improve it on their own (this chapter). Only once all three stages are cleared does the capability actually stay inside the customer's organization; clear only the first, and what's left behind is a piece of software nobody is responsible for.
One long-time observer of this industry once wrote a line that sounds self-contradictory: the best forward-deployed organizations work to eliminate their own jobs — building templates, building tools, turning one-off customer code into configurable platform capability; the goal isn't to erase the role, it's to move it toward a more valuable problem.1 The line was originally about productization (unpacked in Chapter 21), but it holds up just as well applied to handoff — maybe even better: a delivery team that can never make itself unnecessary has turned every project into its own long-term meal ticket. That isn't dedication. It's failing to wean the customer off you.
The test for whether the customer has actually been weaned is simple: six months after you leave, do the system's small changes, small breakdowns, and new requirements still have to come back to you? If they do, it means the judgment and operational knowledge were never handed over. If they don't, then delivery is actually done.
II. The Three Exit Conditions
One practitioner summed up the conditions for a completed FDE exit as three things: business integration, knowledge governance, and system integration — "only once all three are done can he actually leave."2
The first: business integration. The system has to grow into the business process, stop being "that AI project." Three verifiable actions here: process documentation updated — the step the agent participates in gets written into the department's standard operating procedure, so replacing the system would require changing that document, and organizational inertia now protects the system instead of resisting it; embedded into daily use — the system gets used inside the interface users already work in (the embedding principle from Chapter 15), not as an island requiring a separate login; and metric ownership landed — the system's business metrics get recorded in the business department's own report, not in the IT department's project summary. The test for this item is the flip side of the line that opened this chapter: six months on, nobody says "this is the AI project" anymore. It's just part of the work.
The second: knowledge governance. The knowledge for running the system has to move out of the FDE's head and into the customer's organization. What has to move? Three assets, all of them outputs from earlier chapters: the operations manual (the one-page document from Chapter 14 — who watches which alert, which page to flip to when something goes wrong, when to hit the rollback); the eval set (that "compounding asset you can carry with you" from Chapter 12 — plus who maintains it: who adds new failure cases, how often regression gets run); and the incident playbook (the four-category failure triage from Chapter 13 — the first-response action for each type of incident). All three of these are line items on the handoff checklist, not the three words "we discussed it." The counterexample already showed up in Chapter 15: "the memory gets wiped and someone has to re-feed it" — operational knowledge that never gets written down degrades the moment the person who held it leaves.3
The third: system integration. Operations responsibility has to plug into the customer's own systems: monitoring alerts routed into the customer's own operations platform (not visible only to your company); upgrade paths made explicit — who approves changes, who executes them, where the maintenance window sits; and the vendor's boundary of responsibility written into the contract — who to call for what severity of incident, how fast the response time is, and under what conditions it's billable. This third item is the easiest one to skip when relations are good — and it's usually discovered the hard way, at 2 a.m. during the first real incident, that it was never agreed on at all.
What all three have in common: none of them is a technical action. All three are transfers of responsibility and knowledge. The technology was handed over long ago. The responsibility wasn't.
III. Delivery Is a Staircase Down, Not a Cliff Jump
The three exit conditions can't be checked off all at once on exit day — delivery has to descend a staircase, and every step has a duration and an exit criterion (see Figure 17-1).2
Figure 17-1: Handoff isn't a single handover — it's responsibility and capability moving to the customer one step at a time.
Step one: run alongside. The customer's team starts operating the system, with the FDE watching close by — errors get fixed, but the fixing happens where the customer can see it. By the end of this step, the customer can handle routine operations on their own. Exit criterion: a run of several consecutive weeks with no human intervention needed.
Step two: shadow. The customer operates, and the FDE only observes — recording, not touching, meeting once a week to compile a list of issues the customer missed on their own. What's really being delivered at this step is judgment: what counts as normal, what should raise a flag. Exit criterion: the customer's own decisions on handling anomalies match the FDE's after-the-fact judgment, several times running.
Step three: exit. Only escalation support remains — an agreed response tier, an agreed channel. Everything else belongs to the customer.
The staircase has a pitfall on each side: on one side is "never actually leaving" — every step gets extended indefinitely, shadowing turns into a permanent babysitter, and delivery has failed without anyone admitting it; on the other is "vanishing overnight" — jumping straight from acceptance to step three, so the customer faces their first real incident alone, with abandonment counting down from that day. How long to stay on each step, when to move to the next — that sense of pacing is exactly what separates a novice from a veteran.
IV. Three Wrong Turns
Handoff failure tends to take a few recurring shapes, each with its own correction.
Wrong turn one: handoff means sending documents. Package up the docs, get a signature, exit — three months later nobody has read past page two. Enterprise documentation that nobody reads is the default outcome, unless it does two things: gets organized around tasks rather than features ("how to handle an anomalous refund," not "refund module feature specification"), and gets embedded at the point of use rather than sitting on a shared drive (surfacing right where the user gets stuck).4 A small test during the handoff window works better: have the customer's incoming owner walk you through incident handling out loud, while you watch — they talk, you listen, and wherever they can't get through it is exactly where the documentation has a hole.
Wrong turn two: withholding the eval set. The operations manual can be handed over verbatim, but the eval set often gets kept back — it's an asset, and it's leverage for the next deal. This choice has to be settled at contract time, not haggled over at exit: hand over the eval set along with the responsibility for maintaining it, and the customer gets the ability to keep improving on their own while the vendor gets a reputation for "handing off cleanly" — this trade gets tallied again in Chapter 20's pricing models. The position here is worth stating plainly: a team that clings to the eval set is, at bottom, valuing "the right to keep charging" over "the obligation to finish delivery" — and the customer will eventually feel it.
Wrong turn three: handing over operation without handing over judgment. The customer can push the buttons, but can't adjust the parameters: whether to move a threshold, how to attribute a new failure case, whether to trigger a rollback — every small question ends up as another purchased service call. This one is the most hidden, because it doesn't show up during the contract term at all, and can even look great on revenue. There's a ready-made example of how to break it: a partnership between an AI company and a fintech firm wrote "train the trainers" into its core design — identifying the motivated people inside the customer's organization and developing them into internal instructors and internal go-to experts, giving them official certification, a dedicated support channel, and visibility in front of executives; the partnership's stated goal in one line: "transfer knowledge so the customer can build and extend their own agents independently." Delivered all the way to the end, that's teaching the customer to teach themselves.4
V. After Handoff: Five Mirrors
Exiting isn't the finish line. The quality of a handoff only becomes visible a year or two after you leave, looking back at it in the mirror. The reasons enterprise customers churn can be grouped into five categories, and every one of them traces back to a debt left unpaid at handoff.
- Value evaporation: the system is still running, but nobody remembers what problem it solved — the value narrative from when the project was launched has gone dark, and a newly arrived manager only sees a line-item for operations spend. The countermeasure belongs on the handoff checklist: hand over the value framework and the responsibility for measuring it along with the system, so there's always someone who can answer "what is this system actually worth."
- Sponsor departure: your internal ally gets promoted or transferred, their successor never lived through the original decision, and the system becomes "the previous guy's legacy project." Countermeasures: build a mesh of relationships (develop at least two more relationship lines beyond your one sponsor), and institutionalize the value (write the system into process documents and collective memory). The handoff window is exactly the window for building that mesh.
- Quality drift: the business changes, the data changes, the model gets updated, and output quality slides slowly downward until management notices too late. Countermeasure: this is where handing over the eval set really earns its keep — regression tests run by the customer themselves, so the moment quality starts to drift, the customer is the first one to catch it.
- Cost backlash: heavier usage means a bigger bill, and finance scrutinizes it harder. Countermeasure: hand over Chapter 14's cost dashboard and budget circuit breaker along with the system, so the customer can read it themselves and pull the brake themselves.
- Vendor withdrawal syndrome: the customer's own wariness about being "locked in" — the consulting industry has even forecast that most enterprises will eventually abandon this kind of solution because of high cost and insufficient internal skill.4 The countermeasure here is, precisely, a thorough handoff: what the customer fears is "being unable to live without you," not "you being present."
All five mirrors reflect the same conclusion: handoff isn't the tail end of delivery. It's delivery quality's own acceptance sheet — every debt you left unpaid while you were on site comes due, with interest, after you leave.
VI. When You Genuinely Can't Exit
Honestly, some engagements can't be exited: the customer either has no will to take over, or no ability to. What to do here isn't to force an exit (the system dies) or to linger indefinitely (a dependency on billable days) — it's to write that ambiguous state explicitly into the contract: managed operation, priced openly as its own line of service. The customer knows clearly they're buying ongoing managed operation, not completed delivery; the vendor knows clearly they're being paid for operations, not for delivery; and neither side has any illusion about who actually owns the system.2
The difference between managed operation and a faked handoff is, commercially, one contract, and ethically, one honest sentence. Under managed operation, the customer can decide at any time to "build our own team and take it back"; under a faked handoff, the customer thinks they own it when they're really only renting it — and on the day they find out the truth, what they lose isn't just one system, it's their trust in everything else you've ever promised.
One last note, from a business angle, bridging toward Part Five: the ability to hand off is itself a prerequisite for productization. Only a team that can hand off cleanly earns the right to talk about scaling and replicating — because every item on the handoff checklist (templates, manuals, eval sets, connectors) doubles as launch material for the next customer. A team that can't hand off is stacking billable days on top of billable days on every project, and it stops the moment the team hits its headcount ceiling.1 This logic gets built out into the full "declining customization" argument in Chapter 21.
Exit day can be a short meeting with a three-line agenda: run through the checklist for all three exit conditions item by item, with a customer-side signatory for each; finalize the weekly-report template for the shadow-run period; and schedule the next "escalation-only" meeting for six months out. Only once that meeting ends does the person actually leave.
This chapter has described the ideal case: the customer wants the system, and the organization cooperates with handoff. But turn the lens toward the Chinese market, and procurement structure, trust structure, and who defines the last mile all look different — adoption and handoff grow in a different soil altogether.
The next chapter takes up China's different playbook.