Hand-off to the Customer Team

Hand-off is a discipline, not an event

The most consistent FDE-engagement failure mode in year two is: the FDE left, and three months later the customer is stuck. The platform is live, operators use it, the business outcome is real — but every change request requires a call back to the FDE’s company. The ontology can’t be safely extended. The agent’s prompt can’t be tuned. A new datasource takes a quarter to onboard.

That is hand-off done wrong. It looks fine at month 1 (“they’re calling us less!”) and looks bad at month 6 (“they’re calling us for everything important again”).

A well-handed-off engagement looks different. At month 6, the customer’s engineers have shipped three of their own ontology changes, the agent’s eval set is being updated by the customer’s analyst, and a new operator was trained without the FDE on the call. The FDE’s role has shifted to consultation on the hard problems, not the default destination for every question.

Getting there is the work of this lesson.

Four hand-off targets

Hand-off is not one thing. There are four distinct capabilities the customer needs to operate the platform without you:

Each target requires different artifacts and different training. Trying to hand off all four with one set of docs and one training session is the canonical failure mode.

For Northbound:

• Operate: customer SRE inherits the on-call rotation, the runbooks, the alerting setup
• Extend: Raj (analyst) and the senior engineer on the customer side own ontology and workshop extensions
• Govern: the ops VP chairs a monthly steering committee that prioritizes the backlog
• Evolve: an FDE retainer covers the first year, transitioning to the customer’s senior engineer in year 2

Naming the four owners is itself a hand-off step. You produce a one-page ownership document by mid-engagement; everyone signs.

Documentation that survives

Most engagement documentation does not survive a quarter. The wiki page stops being updated; the README is wrong by month 3; the runbook references a service that was renamed.

Documentation that survives shares specific properties:

It lives where the work lives

A runbook in the customer’s wiki, next to other runbooks, has a chance. A document in a personal Google Drive does not. A README in the platform’s repo, in the same place as the code, has the best chance — it gets noticed when the code changes.

It is short

A 40-page architecture document does not get read. A one-page architecture overview, with three diagrams and a “for more detail, see…” footer, does. Length kills documentation.

It has an owner

Every document names the person responsible for keeping it current. When the document is stale, you know who to ask. Without an owner, every document is everyone’s responsibility, which is no one’s.

It has a “last verified” stamp

Not “last edited” — last verified. The owner runs through the doc on a schedule (quarterly works) and writes the date they confirmed it’s still accurate. A doc with a last-verified date in the last 90 days is trusted; one without isn’t.

It is small enough to fit in a notebook

The platform documentation should fit in a printed binder no thicker than 100 pages. If it doesn’t, you’ve written too much, and the customer’s team will use none of it.

The right Northbound documentation set:

Roughly 30 pages, total. Every one has an owner. Every one has a last-verified discipline.

What does not survive

Things FDEs write that do not last and should be deprioritized:

• Comprehensive architecture decision records that nobody reads. ADRs are for the team that wrote them; a customer six months in won’t read the historical “why we picked X over Y” docs.
• Code comments describing why the code was written this way. Replace with tests that demonstrate the intent.
• PowerPoint summaries of the platform. Beautiful in week 4, forgotten by month 6.
• Wiki pages that depend on knowing the wiki exists. Centralize doc into the platform repo / portal.
• Chat history. Slack DMs, recorded Zoom calls, ephemeral channels. None survive.

If you find yourself spending hand-off time writing something that won’t be read in six months, stop. Write something shorter and more useful.

Training that transfers ownership

The training in the change-management lesson was for operators. Hand-off training is for the customer engineers and ops team who will own the platform.

A useful pattern: pair-programming sessions, on real work.

For Northbound, the hand-off training plan might include:

Eight sessions, roughly two per week, spanning month 1 and month 2 post-cutover. By session 8, the customer’s engineer has done — with their hands — every operation they need to be able to do without you.

This is dramatically more effective than any walkthrough video, any written guide, any classroom training. Hands-on with feedback is how skill transfers.

On-call and incident response

After hand-off, who carries the pager?

A staged plan that has worked at most customers:

The progression is explicit. The customer’s SRE knows when their ownership starts. The FDE knows when their pager stops ringing.

The progression also has a rollback path: if month 3 incident review shows the customer’s team is genuinely struggling, the FDE extends the previous phase. This is rare in well-handed-off engagements but happens. Plan for it; don’t be ashamed of it.

Governance after hand-off

Operate and Extend are concrete capabilities. Govern is harder to transfer because it is a meeting, not a skill.

A workable governance model for Northbound year 1:

• Monthly steering committee (60 min): ops VP, IT director, customer senior eng, FDE retainer rep. Reviews:
  • The 30-day adoption metrics
  • Any outstanding incidents
  • The backlog: what’s queued, what should be prioritized
  • The platform roadmap: any architectural changes coming
• Weekly operational sync (15 min): customer ops + customer SRE + FDE retainer rep. Reviews:
  • Any active issues
  • Any planned changes for the week
  • Any new requests from operators
• Quarterly business review (90 min): ops VP + CEO sponsor + FDE retainer rep. Reviews:
  • The original engagement outcomes (on-time delivery, etc.)
  • The platform’s economic impact (saved hours, cost avoidance)
  • The plan for the next quarter

The customer chairs each meeting after month 3. The FDE retainer rep is a participant, not the driver. This is a deliberate transfer of governance authority.

The retainer question

Most FDE engagements bridge full hand-off with a retainer — a smaller, ongoing engagement (often a fraction of a senior FDE’s time) that covers consultation, escalations, agent tuning, and occasional architectural work.

A healthy retainer:

• Is time-bounded. Year 1 retainer is standard; year 2 should be a deliberate, not default, renewal.
• Has explicit scope. “20% of one senior FDE’s time, on-call for severity-1, monthly steering attendance, agent prompt tuning, two major changes per quarter.” Not “we’ll be there when you need us.”
• Has a sunset plan. The retainer’s purpose is to make itself unnecessary. By month 9, the customer’s team should be ready for year 2 without it (or for a much smaller retainer).

An unhealthy retainer:

• Becomes the default destination for any question
• Quietly funds maintenance work the customer should be doing
• Has no defined scope; both sides feel mildly resentful
• Renews indefinitely without anyone noticing

The customer benefits from retiring you. Help them retire you.

The departure week

Even with retainers, there is a departure week — the last week the FDE is on-site primarily for this engagement. Make it count.

A workable departure-week agenda:

Things to leave behind:

• A working WhatsApp / Signal / Slack DM to the FDE retainer (a person, not an alias)
• A documented escalation tree: which FDE for which kind of issue
• A list of “things I’d build next” if budget were unlimited — your gift to the next FDE or the customer’s team

Things to take with you:

• Lessons captured for your company’s playbook — what worked, what didn’t, what to do differently
• A short retro with your team about what was hard — so the next engagement at a similar customer starts smarter
• The customer’s commitments verbatim about the ongoing relationship (renewal timing, reference call willingness)
• The relationships. You’ll see Maria at a conference in three years and she’ll remember you.

Anti-patterns

The “everything important” hand-off doc

A 200-page document that captures “everything.” Nobody reads it. It is stale by month 2. Replace with the targeted, owned, short docs described above.

Hand-off as the engagement’s last sprint

The FDE crams hand-off into the final two weeks. The customer’s team doesn’t have time to absorb. Spread hand-off over the final 8 weeks; bake it into the iteration loop from week 4 onward.

Indispensability as a comfort

A subtle one. The FDE consciously or unconsciously keeps the system slightly too complex for the customer to fully own — because being needed feels good. Resist. The most senior FDEs aim aggressively at being unneeded; it is the strongest signal of having done the job well.

Hand-off without a steering structure

You hand off Operate and Extend but neglect Govern. Six months in, the platform drifts because no one is making the prioritization calls. Always hand off all four.

Skipping the simulated incident

You never had the customer’s SRE drive a real incident with you on backup. The first real incident after hand-off is also their first dry run. Bad. Always simulate an incident with the customer-owner driving, before they own the pager.

The retainer that grows

Year 1 retainer goes well; year 2 the customer asks for more; year 3 you’re effectively the operations team. Resist. Negotiate firmly downward at each renewal. The customer’s team should grow into the work, not be permanently relieved of it.

Closing Phase 5

By the end of Phase 5, the Northbound engagement looks like this:

• The platform is in production, the system of record for the dispatch workflows
• Three dispatchers, two hub managers, and an analyst are using it daily
• Adoption metrics are trending in the right direction; the trough was navigated
• The customer’s senior engineer has shipped two changes independently
• The on-call rotation has transitioned to the customer’s SRE
• The steering committee meets monthly with the customer chairing
• The FDE has flown home; a quarter-time retainer covers the first year

The engagement is no longer “your engagement.” It is the customer’s platform, with your fingerprints on the foundation, and a relationship that will renew on the strength of demonstrated outcomes, not on dependency.

That is the goal of FDE work. The technical artifacts are the tangible output. The transfer of capability is the durable one.

Key terms to remember

• Hand-off targets — operate, extend, govern, evolve — each requires distinct work
• Documentation that survives — short, owned, lives where work lives, has a last-verified date
• Pair-programming hand-off training — the customer engineer ships real changes with you observing
• Staged on-call transition — explicit phases from FDE-primary to customer-primary
• Retainer with a sunset plan — bridges hand-off without becoming permanent
• Indispensability as a comfort — the anti-pattern of unconsciously preserving need for yourself

What’s next

You can run an engagement from cold start to clean hand-off. The technical and operational discipline is in your hands. The last work to learn — the work that often decides whether the technical work ever gets to ship — is the off-keyboard work: executive communication and navigating procurement, security, and legal. Phase 6 covers both, and is where FDEs most often under-invest.