Forward deployed engineering: the complete guide / How an engagement runs
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.
Key takeaways
- By day ten: something shipped against real data, a written definition of correct, and a mapped path to production with names and historic durations attached.
- Access is the whole game. Provision repository, data and environment credentials before day one, not during week one.
- The customer must provide three things: access, one named person who can unblock, and one person who can say no to scope.
- The third is the one people forget, and its absence is why engagements sprawl.
Two weeks is enough to tell whether an engagement will work. Here is what should be true at the end of them, and what has to exist before they start.
Before day one: the customer's three
Access, provisioned and tested. Repository, the data the work touches, the development and staging environments, the identity provider, the ticketing system, the chat. Tested means somebody logged in as the new engineer and confirmed it works, rather than a ticket being marked done.
This sounds administrative and it is the single largest determinant of the first two weeks. An engineer with a laptop and no credentials costs the same as one shipping code. Our own staff augmentation page makes the same point about ordinary embedded work, and it matters more here, because a forward deployed engagement is measured on an outcome with a date attached.
One named person who can unblock. Not a committee, not a shared inbox. Somebody whose job includes answering "who owns this system" and "can I get read access to that table" within hours. Naming this person often halves the ramp.
One person who can say no. This is the one that gets forgotten, and its absence is why engagements sprawl. Requests will arrive from every direction, each reasonable. If nobody on the customer's side has the authority to decline one, the scope grows by consensus and the production date moves by drift.
Week one: get something running
The goal of week one is not planning. It is one small thing working against real data.
That could be a single transform, one screen reading live records, one integration returning a real response. It has to touch the actual systems, because that is what surfaces the truths a kickoff meeting hides: the data is dirtier than described, an API times out under real load, the permission model does not separate two roles the business treats as different.
What else week one produces:
A map of the path to production. What must be true for a change to reach live, who signs each step, and how long each signature has historically taken. Ask for real durations rather than published targets. This answer sets the schedule more than the build estimate does.
A first pass at what correct means. Not a full specification. The one outcome the first release moves, and how you will know it moved.
A list of what you were told that is not true. Every engagement generates one. Writing it down early is how the plan stays honest.
Week two: turn it into a plan you believe
With something running and the production path mapped, the second week is where the real scope gets set.
Write the specification properly. What the system does, what correct looks like, what is explicitly out of scope. In our engagements this is written to the level our tooling generates from, which is well past a normal requirements document, and the eval suite comes from it. Even without that, the document is what later phases check against.
Name the two dates. The production date and the handover date. If the contract already carries them, confirm week one did not invalidate them. If it does not carry them, that is a gap to fix now rather than in month three.
Identify the customer engineer who will inherit this. By name, and involve them from here. A system handed to somebody introduced at the end is a system that comes back.
Agree the weekly rhythm. What ships each week, who sees it, and where decisions get recorded.
The 20/80 check
First Round Review puts the healthy time split at roughly 20 percent customer-facing and 80 percent building. Check it at the end of week two.
If the engineer spent most of two weeks in meetings, one of three things is true: the scope is unclear, the organization is blocking and the engineer has become the person chasing approvals, or the role was presales all along. None of the three is fixed by the engineer working harder. The three jobs hiding behind the title covers the third case.
What a bad first two weeks looks like
Recognisable, and recoverable if named early.
Access arrived on day six. You have lost a week. Say so out loud and move the production date rather than absorbing it quietly.
Nothing has run against real data. Either access is incomplete or the work has drifted into planning. Both need intervention this week, not next month.
No named unblocker. Every question is going to a group chat and getting answered slowly or not at all.
The specification is still a conversation. Two weeks in, the absence of a written definition of correct means there is disagreement nobody has surfaced.
Scope grew twice already. Without somebody who can say no, this is the trajectory for the whole engagement.
For the customer: how to get more out of the first two weeks
Give context rather than tasks. An engineer who understands why the outcome matters makes better decisions than one working from a ticket.
Include them fully: standups, planning, the channels where problems get mentioned before they become tickets. People who see the whole picture catch problems earlier.
And expect to be told things you did not want to hear in week two. That is the value you are paying for. An engagement where the first two weeks produce no uncomfortable findings has not looked hard enough.
Next: what a forward deployed engineer ships in week one, or how to prepare your team.
Best for
- Preparing your side before an embedded engineer arrives
- Running a two-week checkpoint on an engagement that has just started
- Diagnosing an engagement that feels slow in its first month
Avoid if
- The engagement is already months in and the question is how it ends
Verify before you commit
- Confirm access was provisioned and tested before day one, by logging in as the new engineer
- Name the person who can unblock, and the person who can decline scope
- Check something has run against real data by the end of week one
- Check the path to production is mapped with names and historic durations
Common questions
What should happen in the first two weeks of an embedded engagement?
By day ten there should be something shipped against real data, a written first pass at what correct means, and a mapped path to production with names and historic durations attached. Week one is for getting something running, week two is for turning that into a scope you believe.
What does the customer need to provide before day one?
Three things. Access provisioned and tested, meaning somebody logged in as the new engineer and confirmed it works. One named person who can unblock questions within hours. And one person with the authority to decline scope requests. The third is most often missing and its absence is why engagements sprawl.
Why is access such a big deal?
Because an engineer with a laptop and no credentials costs the same as one shipping code. Waiting days for repository, data or environment access is the most common cause of a slow start, and in an engagement measured on an outcome with a date, that lost week does not come back.
Why ship something in week one rather than plan properly first?
Because shipping is the diagnostic. Touching the real systems surfaces what a kickoff meeting hides: the data is dirtier than described, an API times out under real load, the permission model does not separate two roles the business treats as different. Those findings should shape the plan rather than interrupt it.
What are the warning signs at the two-week mark?
Access arrived late, nothing has run against real data, no named unblocker exists, the specification is still a conversation rather than a document, or scope has already grown twice. Each is recoverable when named in week two and expensive when discovered in month three.
Should the first two weeks produce bad news?
Usually yes, and that is the value. An engagement whose first two weeks surface no uncomfortable findings has not looked hard enough at the environment. Expect a written list of things you were told that turned out not to be true.
Related reading
How to onboard engineers fast so they ship in week one
Slow onboarding is a hidden tax you pay on every hire. Here is how to get a new engineer shipping real work in their first week instead of their first month.
How to take over a codebase you did not write
Someone hands you a working system and leaves. The instinct is to read it. The better first move is to find out what it guarantees, because the code will tell you what it does and never what it was supposed to do.
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.
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.
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.
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.