Illustrative. This lesson closes the composite engagement from Discovery through Adoption: the logistics company, the veteran, the flagging system now in daily use. The dialogue is invented to teach the move and contains no statistics.
The system works and people use it. An AI engineer would call that done. A forward deployed engineer knows the engagement isn't finished until it runs without them, and, done right, until the one deployment has become a capability the customer reuses elsewhere. Handover is the phase that separates a consultant who leaves a dependency behind from an FDE who leaves a team stronger.
The instinct that sabotages this phase is the one that felt like value the whole engagement: being the person who understands the system. If the flagging tool only works because you're around to babysit it, you didn't finish the job. You became a permanent cost the customer will eventually resent and cut.
Before reading on
The flagging system is live and trusted. The VP, happy, says: "Great — can you stay on to keep it running?"
That sounds like success. Why is "yes, forever" the wrong answer, and what do you propose instead?
"Yes, forever" makes you a dependency and caps the value at one deployment you personally maintain. The right answer transfers ownership to their team and points the proven pattern at the next problem. Watch.
Move 1 — transfer ownership, not just the code
Handover is not emailing a repository. It's making sure the customer's team can do the three things you can: operate it, debug it, and change it.
You: "My aim is to make your team the owners, so this never needs me as life support. Here's what I'll leave: the dashboard they already use to see it's healthy, a runbook for the two or three things that go wrong and how to fix them, and the eval set so that when they change a rule or the model, they can tell in a day whether it still works. I'll pair with your engineer on the next change so they make it, with me watching, instead of the reverse."
The tell of a real handover is that the customer's engineer makes the next change while you watch. You've moved from doing to enabling. What you leave behind is the observability, the evals, and the guardrails that let someone who isn't you keep it trustworthy. That's why those weren't optional engineering; they were the handover, built in from the start.
Move 2 — turn one deployment into a capability
Once the pattern is proven and owned, scale is generalization, not a rewrite:
VP: "The Northeast depot has the same problem. And honestly, so does our customs paperwork."
You: "Then we've built more than a tool. We've built a shape: watch a decision as it's made, flag the risky ones against rules that change, keep a human deciding, prove it with logs. The routing model is specific to hazmat, but that shape moves straight to the next region, and most of the way to customs. Your team owns the shape now, so the second one is a fraction of the work, and they can build it without me."
That is the forward-deployed endgame, and it's the cited pattern from Morgan Stanley: one deployment, run well enough that it generalizes into a capability the rest of the organization reuses. You didn't scale a system; you scaled a pattern, and you left a team who can apply it.
Bad / Good / Great — "can you stay on to run it?"
Bad — "sure, I'll keep maintaining it." You made yourself a permanent dependency, capped the value at what you can personally babysit, and guaranteed that the day you leave, it rots. It feels like job security; it's the opposite of the role.
Good — "I'll document everything and hand it off." The right intent. But documentation nobody's been trained on becomes shelfware, and a team that's never made a change under supervision won't make one confidently after you're gone.
Great — "I'll make your team the owners: the health dashboard, a runbook, the eval set so they can verify their own changes, and I'll pair with your engineer on the next change so they lead it. Then let's point the same proven pattern at the Northeast depot, which they can now build largely without me." You transferred real capability and turned the win into a repeatable shape the customer owns. That transfer is what makes the next engagement possible.
The probe to expect
VP: "Won't making yourself unnecessary put you out of a job?"
You: "The opposite. When your team can run this and wants the next one, that's the reference that brings me the next hard problem — here or somewhere else. An FDE who leaves dependencies gets one engagement per customer; one who leaves capability gets invited back for the harder thing. Making myself unnecessary here is how I stay valuable everywhere."
What "done" actually looks like
You're done with an engagement when: the customer's team operates and debugs it without you, they've made at least one real change under their own power, they can verify their own changes with the eval set, and the pattern has a clear next application they can reach. If any of those is missing, you've built a tool, not delivered a capability.
The transferable pattern
Finish by making yourself unnecessary: transfer the ability to operate, debug, and change the system, then generalize the proven pattern to the next problem a team you've enabled can own. One deployment maintained by you is a cost; one pattern owned by the customer is a capability. The forward-deployed job isn't done when the system works. It's done when it works without you and points at what's next.
Next: Build the Evidence. You've now walked the whole engagement cycle the engagements are graded against; now turn work like it into interview evidence.NextBuild the Evidence