Handing Over

The pilot has become a production system, and in two weeks you move on to a new customer. From then on, if the nightly export goes missing at 2 a.m. or a carrier changes its rates, someone at Harbourline has to deal with it without calling you. The handover is the last thing you build, and it needs as much care as the first.

The rule

You're done when they can run it without you — and have proved it.

A handover has four parts:

• Documents. A runbook (how to check health, deploy, roll back and fix the common failures), the architecture note, the decision log, an access list and the list of open issues. An honest list of open issues is worth more than a polished page that hides them.
• Owners. Every part has a named owner. Harbourline IT owns the infrastructure and the night-time alerts. Farhan's team owns the review process and loading carriers' new rates. Loomwork support owns product bugs, with a clear way to reach them.
• Practice. Training is not reading. People learn to run a system by running it while someone who knows it watches.
• A clean exit. Remove your own access, and rotate any passwords or keys you knew. An engagement should not leave a back door open.

"Proved it" is the part most often skipped. A runbook nobody has followed is a guess.

The shortcut

Reverse the shadow. For each routine and emergency task, move through three steps: you do it while they watch; they do it while you watch; they do it alone. Every time they get stuck, fix the runbook, not just the moment.

The trap is declaring victory at the training call. Until they have done the tasks themselves, you do not know whether the handover worked.

Drills

Answer fast — trust the rule.

Remember

• You're done when they can run it without you — and have proved it.
• Shortcut: reverse the shadow. You do, they watch; they do, you watch; they do it alone.
• Trap: a runbook nobody has followed, and access left open after you leave.