Forward deployed engineering: the complete guide / How an engagement runs
Handover and exit from a forward deployed engagement
The ending of a forward deployed engagement has to be designed at the start, with a date in the contract at signature. An engagement whose conclusion is decided later does not have one: it drifts, because there is always one more improvement and both sides find the arrangement comfortable. AWS named customer self-sufficiency after the engagement as a design goal of its own programme, and its partner model ends with the partner team working independently. The test of a handover is not whether documents were delivered. It is whether the customer's own engineer has changed the system, alone, before the vendor left.
Key takeaways
- Put the handover date in the contract at signature. A date agreed later is a date that moves.
- The handover artefact is a runbook plus a test suite the inheriting team can run, not a slide deck or an architecture document.
- The real test: the customer's engineer makes a change and ships it, unaided, while the vendor is still there to watch it fail.
- Name the inheriting engineer at phase three and involve them from that point. Somebody introduced at the end will hand the system back.
Most writing about this model covers how engagements start. The ending decides whether the whole thing was a deployment or a subscription.
Why the ending has to be designed
An open-ended embedded engagement is comfortable for both parties in the short term. The vendor has predictable revenue and a customer who values them. The customer has a capable team handling something they never had to staff. Nobody is behaving badly.
The result is still a dependency. The customer's own engineers never learn the system, the vendor's margin never recovers because the engineer never moves to a second account, and the arrangement gets described as a partnership by both sides.
When AWS announced its forward deployed engineering organization in June 2026, it named customer self-sufficiency once an engagement ends as a design goal, and its partner programme runs to a phase where the partner team works independently. Whatever else you take from the largest public programme in this space, take that.
Put the date in the contract
Not the production date. A separate, later date on which the vendor's people stop operating the system.
A handover date agreed during the engagement will move, because by then both sides have reasons to move it. A date agreed at signature, before anybody is invested, is the only version that holds.
Two things go with it. What the handover artefact is, specifically. And who on the customer's side is accountable for the system afterwards, by name.
Name the inheritor early
The most common handover failure is structural rather than documentary: the person who will own the system meets it at the end.
Name them at phase three, when the system is going to production, and involve them from that point. They attend the reviews. They see the incidents. They make some of the changes while the people who built it are still in the room.
A system handed to somebody introduced in the final week comes back within a quarter, and it comes back as an emergency.
What the handover artefact actually is
A slide deck is not a handover. An architecture diagram is not a handover. A recorded walkthrough is closer and still not it.
A runbook that answers operational questions. How to deploy it. How to roll it back. What the alerts mean and what to do about each. Where the credentials live and how to rotate them. What breaks when the upstream API is down. Our post on what belongs in a runbook nobody reads covers the shape.
A test suite the inheriting team can run. This is the part that matters most, and on an AI-native engagement it is the eval suite derived from the specification. The reason is simple: documentation tells the next team how the system works today, and a test suite tells them whether their change broke it. Only the second one lets them own it.
The specification, current. Not the version written in week two. The version that reflects what was built, including the decisions that changed. Keeping a spec alive after the build is the discipline.
The list of known compromises. Every system has them. Writing them down is the difference between a successor who is careful in the right places and one who discovers them at 2am.
Access, transferred and verified. The inheriting team's credentials work, and somebody proved it before the vendor's access was revoked. Then the vendor's access is actually revoked, on the date, which our page on security and access treats as a contract term rather than a courtesy.
The one test that matters
Everything above is inputs. Here is the test.
Before the vendor leaves, the customer's engineer makes a real change to the system and ships it to production, unaided.
Not a change the vendor pair-programmed. Not a configuration toggle. A real change, through the real release path, with the vendor present to watch what goes wrong and answer questions rather than to do it.
If that has not happened, the handover has not happened, whatever documents exist. Schedule it two to four weeks before the handover date so there is time to fix what it reveals.
What good tapering looks like
Handover works better as a slope than a cliff.
In the final stretch, the customer's engineer takes the work and the vendor reviews. Then the vendor stops reviewing and stays reachable. Then the vendor is not reachable. Each step should be a stated date rather than a vibe.
An optional last step worth pricing separately: a defined support window after the handover, with a fixed scope and a fixed end. This is honest when it is bounded and it is how open-ended dependency gets reintroduced when it is not. If a vendor proposes ongoing support, ask what it excludes and when it stops.
What to do if the ending was never designed
Common, and recoverable.
Pick a handover date now, in writing. Name the inheriting engineer. Run the one test above and let it fail, because the list of what it reveals is your actual handover plan. Then work backwards from the date.
The conversation is easier than people expect, because a vendor doing this well wants the reference more than the retainer, and a vendor who resists has told you something useful about what they were selling. When forward deployed engineering is the wrong answer covers that signal.
Our commitment on this
We name a production date and a handover date before an engagement starts, and the handover artefact is the eval suite plus the runbook, because the suite is what lets your team change the system and still know it works. The point of an engagement is that it ends.
Best for
- Designing the ending of an engagement before it starts
- Rescuing an engagement that has no agreed conclusion
- Judging whether a handover that already happened was real
Avoid if
- You are still deciding whether to start an engagement at all
Verify before you commit
- Confirm the handover date is in the contract, separate from the production date
- Name the inheriting engineer and confirm they were involved from the production phase
- Run the test: the customer's engineer ships a real change unaided, before the vendor leaves
- Confirm the handover artefact includes a runnable test suite, not only documents
Common questions
When should the handover date be agreed?
At signature, in the contract, separate from the production date. A handover date agreed during the engagement will move, because by then both sides have reasons to move it. A date fixed before anybody is invested is the only version that holds.
What should a handover include?
A runbook covering deployment, rollback, alerts and credential rotation. A test suite the inheriting team can run. The current specification rather than the week-two version. A written list of known compromises. And transferred access, verified working before the vendor's own access is revoked.
How do you know if a handover actually worked?
One test. Before the vendor leaves, the customer's own engineer makes a real change and ships it to production unaided, through the real release path, with the vendor present to watch rather than to help. If that has not happened, the handover has not happened regardless of what documents exist.
Why is a test suite more important than documentation?
Because documentation tells the next team how the system works today, and a test suite tells them whether their change broke it. Only the second one lets them own the system. On an AI-native engagement that suite is the evals derived from the specification.
Who should inherit the system?
A named engineer on the customer's side, identified when the system goes to production rather than in the final week. They should attend reviews, see incidents, and make some changes while the people who built it are still in the room. A system handed to somebody introduced at the end comes back within a quarter, as an emergency.
What if the engagement never had an agreed ending?
Set one now in writing, name the inheriting engineer, and run the unaided-change test immediately. Let it fail: the list of what it reveals is your real handover plan. A vendor doing this well wants the reference more than the retainer, and one who resists has told you what they were selling.
Related reading
What a good handover document actually contains
Most handover documents describe the architecture, which is the one thing the next team can work out for themselves. The valuable parts are the decisions, the unknowns, and the things only one person knew.
What belongs in a runbook nobody reads
Most runbooks are written for a calm reader who has time. The person who opens one is tired, frightened, and has about ninety seconds, and almost nothing in a normal runbook survives that.
More in How an engagement runs
How a forward deployed engagement runs
A forward deployed engagement runs in five phases: discovery inside the environment, a prototype against real data, deployment to production, productizing what turned out to be reusable, and scaling back so the customer's own team runs it. The first three are what everyone plans. The fourth is what turns one customer's work into a product. The fifth is the one that gets skipped, and skipping it is the difference between a deployment and a dependency. AWS describes a similar three-phase shape for its partner programme, ending with the partner working independently.
The first two weeks of a forward deployed engagement
The first two weeks decide the pace of everything after them. By day ten a working engagement has shipped something small against real data, written down what correct means, and mapped the path a change takes to production. The most common way to lose those two weeks is access: an engineer waiting on repository credentials is the most expensive idle resource in the building. Three things have to exist before day one, and all three are the customer's to provide.
Discovery inside the customer environment
A discovery call gives you what the customer can describe. Being inside the environment gives you what nobody thought to mention, and that second category is where deployments break. Marty Cagan's argument for the embedded model is that it is a product discovery technique rather than a delivery technique: engineers who visit multiple customer sites see the similarities and differences across a market, which is the essence of customer discovery. The practical version is that the environment is the instrument, and you cannot read it from outside.
What a forward deployed engineer ships in week one
A forward deployed engineer should ship something small and working against real data in the first week. Not a mockup and not a demo on a curated slice: one transform, one screen reading live records, one integration returning a real response. The point is diagnostic rather than promotional. What breaks when you try to ship something tiny tells you more about the engagement than any planning document, because it forces contact with the data, the permissions and the release path all at once.
What goes wrong in forward deployed engagements
Forward deployed engagements fail in a small number of recognisable ways, and most of them are visible by week three if you know the tell. The endless engagement. The demo that never hardens. The engineer who became an account manager. The bespoke fork nobody can upgrade. The pilot that was never going to production. And the handover that was a slide deck. Each has an early signal and a specific intervention, and none of them get fixed by the engineer working harder.