What this document is. A 90 day plan for an engagement in which a forward deployed engineer takes one problem from discovery to production inside the client's systems, written from the client's side: what is delivered at the end of each phase, what the client has to provide, and the signs that the engagement is drifting. The phases are built from two published descriptions of how the role works in practice, one from the head of forward deployed engineering at an AI lab as reported by The Pragmatic Engineer (August 12, 2025), the other from the guide by the person who built the training program for the role at the company that created it (February 5, 2026). How we run it on our own engagements is described at the end and marked as ours.
1. Two published descriptions of how the role actually works
The Pragmatic Engineer's deep dive of August 12, 2025 describes the customer facing structure used by one AI lab's forward deployed engineering team in three phases. Early scoping: a couple of days onsite, sitting with users, mapping their processes, identifying the biggest value areas, prototyping with synthetic data. Validation: the team lands on the customer's site to answer one question, whether what was scoped is the most valuable thing they can do, and then agrees on validation criteria, with quality checks built from user input and a final report comparing results with the objectives. Delivery: onsite a few days per week, exact details of the problem, real data, solutions built and demonstrated, with a focus on "the smallest unit possible" that results in an end to end solution. The head of that team explains why validation comes before delivery: what the customer describes in scoping often does not match the data and the systems on the ground, so the team moves fast, finds the walls and adjusts the scope.
Vinoo Ganesh, who built the program that turned software engineers into forward deployed engineers at the company that created the role, from 2015 (more than 250 engineers went through it), gives the engineer's side of the same 90 days in his guide of February 5, 2026. Days 1 to 30: learn, absorb context, meet everyone, read all documentation, shadow every call, do not try to add value yet. Days 31 to 60: find the first win, one small thing owned completely, with a clear before and after, shipped and announced. Days 61 to 90: start forming opinions, engage harder problems, propose solutions. He names four traps: overengineering, retreating into code when a meeting gets tense, overpromising, and solving the wrong problem. His most important question for the role: "what are you trying to accomplish?"
The two descriptions agree on the order (understand, prove, deliver) and on the failure mode (building before understanding). What neither gives is the view from the buyer's chair. That is the rest of this document.
2. The plan from the client's side
| Phase | Days | What the engineer does | What you receive | What you provide |
|---|---|---|---|---|
| Discovery | 1 to 15 | Sits with the people who live the problem, reads the code and the systems, maps the process as it runs today, asks "what are you trying to accomplish?" until the answer is a measurable result | A discovery memo: the problem in one paragraph, the observable result that will define done, the systems and data involved, the constraints found (access, security, data quality), and the risks | Access to the repository, the systems and the people; one named owner on your side who can decide |
| Specification | 10 to 25 | Writes the spec with your team: behavior, interfaces, acceptance criteria that a test can check, what is out of scope | The spec, in your repository, reviewed and approved by your owner; a validation plan stating how you will both know it works before it is finished | Review within two working days; the decision on what is out of scope |
| Validation | 20 to 40 | Proves the risky part first: the integration nobody has done, the data nobody has looked at, the model behavior nobody has measured. Builds the checks that will define quality | A working slice of the hardest part against real data, and the quality checks that the final system will have to pass; if the slice fails, a revised scope with the reason | Real data, in the environment where the system will run; a decision if the scope has to move |
| Build | 35 to 75 | Directs and reviews the agents that write the code; every change passes tests, types, linters, structural checks and a review rubric before a person is assigned; ships the smallest unit that works end to end, then the next | Increments in production, each behind your gates, each demonstrated on your data; the pipeline that enforces those gates, in your CI | Reviews by exception (architecture, security boundaries, blast radius) and the go ahead for each increment |
| Operate and transfer | 60 to 90 | Runs the system in production, handles the first incident, writes the operating handbook, pairs with the people who will own it | The system in production with its handbook, its runbook for incidents, its tests in your CI, and a named person on your team who has operated it with the engineer beside them | The person who will own it, with time reserved to pair |
Organization by yaab Research. The order of the phases follows the sources in section 1; the deliverables and the client's obligations are ours.
3. Deliverables that should exist by day 30, 60 and 90
Day 30: the discovery memo and the spec, both in your repository, both approved by your owner. A first meeting with your security or infrastructure person has happened. The engineer can describe your system to your CTO without notes. Nothing has been built for production yet, and that is correct.
Day 60: the hardest part of the problem works against real data, with the quality checks written. At least one increment is in production behind your gates. The pipeline that enforces the gates exists in your CI and rejects a change that fails them. Your team has reviewed agent written code by exception and knows what the exceptions are.
Day 90: the system is in production and has survived its first incident or its first month, whichever came first. The operating handbook and the incident runbook exist. Someone on your team has run it with the engineer beside them and can run it alone. The spec, the tests and the pipeline stay in your repository whether or not the engagement continues.
4. Six signs the engagement is drifting
- Day 15 and there is no discovery memo, or the memo describes a solution instead of a result. The engineer is building before understanding.
- The spec is a document only the engineer has read. Your owner has not approved it, and acceptance criteria cannot be turned into tests.
- The first thing built is the easy part. Validation exists to find the walls early; if the risky integration is scheduled for day 70, the plan is backwards.
- Increments are demonstrated on synthetic data after day 40. Real data is where the sources say scoping breaks; if it has not been touched, the scope has not been tested.
- Code reaches production without passing through gates in your CI. If the checks live on the engineer's machine, they leave with the engineer.
- Day 75 and nobody on your team has operated the system. Transfer is a phase with time reserved, not a handover meeting on the last day.
5. How we run this on our own engagements
On our own work, discovery ends when the observable result is written in one sentence the client's owner has approved; we do not start the spec before that sentence exists. The spec lives in the client's repository from the first draft. Validation takes the part with the most unknowns first, on the client's real data, in the client's environment, and it has changed the scope of several engagements, always earlier and cheaper than it would have changed later. The agents that write the code do not open a pull request until the tests, the type checker, the linters, the structural test and the review rubric pass; the client's reviewers read what needs a human. Transfer starts by day 60 with a named person pairing on real operation, because the sign we watch for is the same one Ganesh names: a system that works and that only its author understands.
6. How to use this document
Before signing, ask the provider to fill in the "what you receive" column with dates. If the answer for day 30 is code, or the answer for day 90 does not include a named person on your team operating the system, you are buying development hours with a new title. The role exists to own an outcome inside your systems and to leave your team able to run it; the 90 day plan is how you check that both are happening while there is still time to correct.
Sources
- The Pragmatic Engineer (Gergely Orosz), What are Forward Deployed Engineers, and why are they so in demand?, August 12, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- Vinoo Ganesh, The Definitive Guide to Forward Deployed Engineering, published by Next Play, February 5, 2026. https://nextplayso.substack.com/p/the-definitive-guide-to-forward-deployed
About the sources. The descriptions in section 1 are cited from the sources listed above and restated in our own words beyond the short quotations marked as such; no chart, table or extended passage from those publications is reproduced here. The people and organizations cited did not take part in this document and do not endorse it; their names identify the sources and nothing more. The phase plan, the deliverables and the drift signs are our adaptation.