Forward deployed engineering: the complete guide / Buying the capability
How to prepare your team for an embedded engineer
Three things have to exist before an embedded engineer starts, and all three are yours to provide: access provisioned and tested, one named person who can unblock, and one person with the authority to decline scope. The third is the one everybody forgets, and its absence is why engagements sprawl. Beyond that, the difference between a fast engagement and a slow one is mostly about how much context you share and how completely you include the person. Nobody writes this page, and it decides more outcomes than the vendor's methodology does.
Key takeaways
- Access provisioned and tested before day one. Tested means somebody logged in as the new person and confirmed it works.
- Name one person who can unblock within hours, and one who can decline scope. The second is the one people forget.
- Share context rather than tasks. Senior people make better decisions when they know why the outcome matters.
- Expect uncomfortable findings in the first fortnight. An engagement that surfaces none has not looked hard enough.
Vendors write about their own methodology. Almost nobody writes about what the customer has to do, and it decides more outcomes.
Before day one
Access, provisioned and tested. Repository, the data the work touches, development and staging environments, identity provider, ticketing, chat.
Tested means somebody logged in as the new person and confirmed each one works, rather than a ticket being closed. The most common cause of a slow start is an engineer sitting for four days with a laptop and no credentials, which costs exactly the same as an engineer shipping code.
If your security process cannot provision an external engineer in under a week, start it before the contract is signed. That is not a suggestion to weaken the process. It is a scheduling fact.
A named unblocker. One person whose job includes answering "who owns this system" and "can I get read access to that table" within hours. Not a committee, not a shared inbox, not a rota.
A named decision-maker who can say no. This is the role people forget, and it is the reason engagements sprawl. Requests will arrive from every direction, each reasonable on its own. If nobody has the authority to decline one, scope grows by consensus and the production date moves by drift. The vendor cannot do this for you: a vendor declining your colleague's request is a vendor creating a political problem.
The first week
Give them the real data. A sanitised extract hides the exact things they need to find: the nulls in a required column, the three spellings of the same category, the records from a 2019 migration with a different shape. If regulation prevents it, say so on day one and agree what the substitute is, rather than letting them discover the substitute is fiction in week three.
Introduce the person who does the work, not only the manager who owns it. These are different people with different information. The manager knows the intended process; the operator knows the exception that covers 15 percent of cases.
Answer the production-path question honestly. They will ask what has to be true for a change to reach production, who signs each step, and how long each has historically taken. Give real durations rather than published targets. This answer sets the schedule more than the build estimate does.
Throughout
Share context, not tasks. An engineer who understands why the outcome matters makes better decisions than one working from a ticket. This is the single cheapest thing on the page and the most often skipped.
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 take more ownership. Keeping an external engineer at arm's length is the most reliable way to get arm's-length work.
Protect their building time. First Round Review puts the healthy split at roughly 20 percent customer-facing and 80 percent building. Your side controls this more than you think: every extra standing meeting comes out of the second number.
Read the findings. The list of things you were told that turned out not to be true is the most useful document of the first month and the most commonly skimmed.
Name the inheritor early
Whoever will own this system after the vendor leaves should be identified when the system goes to production, not in the final week.
They attend the reviews. They see the incidents. They make some of the changes while the people who built it are still available. A system handed to somebody introduced at the end comes back within a quarter, as an emergency. Handover and exit covers the test that proves it worked.
If you do not have anyone to name, that is important information about whether you should be buying an outcome or building a capability. Three routes covers the choice.
What to expect that will be uncomfortable
You will be told your data is worse than you think. It usually is. This is the finding with the highest value and the worst reception.
Somebody's process will be described accurately for the first time. Including the workaround they built and never mentioned. Handle that well, because the person who built the workaround is your best source of requirements and the easiest to alienate.
The plan will change. If a discovery process cannot change the plan, it is theatre and you have paid for theatre. When forward deployed engineering is the wrong answer covers the case where the plan genuinely cannot move, in which case buy something else.
An engagement that produces no uncomfortable findings in the first fortnight has not looked hard enough. Quiet early weeks are a warning rather than a comfort.
The one-page checklist
Before day one: access tested, unblocker named, decision-maker named.
Week one: real data, the operator introduced, the production path answered with real durations.
By production: inheriting engineer named and involved.
Throughout: context shared, the person included, building time protected, findings actually read.
That is the whole customer side. It costs almost nothing and it is the difference between a deployment that lands and one that becomes a story about a vendor who did not deliver.
Best for
- Preparing your organization before an embedded engagement starts
- Diagnosing why an engagement is slower than expected
- Deciding who on your side needs to be named in which role
Avoid if
- You are still choosing a vendor
Verify before you commit
- Log in as the new engineer to confirm every access actually works
- Name the unblocker and the person who can decline scope, in writing
- Give real historic durations for each approval step, not published targets
- Name the inheriting engineer at the production phase, not at the end
Common questions
What does a customer need to do before an embedded engineer starts?
Three things. Access provisioned and tested, where tested means somebody logged in as the new person and confirmed it works. One named person who can unblock questions within hours. And one person with the authority to decline scope requests, which is the role most often forgotten.
Why does someone need authority to say no?
Because requests arrive from every direction and each is reasonable on its own. Without someone empowered to decline, scope grows by consensus and the production date moves by drift. The vendor cannot do this for you, since a vendor declining your colleague's request creates a political problem rather than solving a scope one.
Should we give an external engineer our real data?
Yes where possible, because a sanitised extract hides exactly what they need to find: nulls in required columns, multiple spellings of the same category, records from an old migration with a different shape. If regulation prevents it, say so on day one and agree the substitute, rather than letting them discover in week three that the substitute is fiction.
How do we help the engagement go faster?
Share context rather than tasks, include the person fully in standups and planning and the channels where problems surface early, and protect their building time. The healthy split is roughly 20 percent customer-facing and 80 percent building, and your side controls that more than you think.
When should we name the person who will inherit the system?
When the system goes to production, not in the final week. They should attend reviews, see incidents, and make some changes while the people who built it are still available. A system handed to somebody introduced at the end comes back within a quarter, as an emergency.
What should we expect to hear that we will not like?
That your data is worse than you think, which is the highest-value finding and the worst received. That somebody's process is being described accurately for the first time, including a workaround they never mentioned. And that the plan will change. An engagement producing no uncomfortable findings in the first fortnight has not looked hard enough.
Related reading
How to manage an external development team so it feels like your own
Managing an outside team goes wrong when you count hours instead of outcomes. Here is how to steer a team that ships, instead of babysitting one that stalls.
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.
More in Buying the capability
When forward deployed engineering is the wrong answer
Forward deployed engineering is expensive and it is often the wrong tool. It does not fit when your contract values cannot carry an engineer's time, when every customer wants the same thing, when you hold a fixed product opinion you will not change, or when the scope is something you can already write down. Each of those has a cheaper alternative that works better. There is also one failure mode that disqualifies the model after you have already started: the engagement with no end date, which has stopped being a deployment and become a dependency.
Forward deployed engineering as a service
There are three ways to get this capability: build the function in-house, staff individual engineers through a partner, or engage a firm that takes the outcome. Building gives you the most control and takes a hiring cycle plus two or three engagements of learning. Staffing is fastest to a body in a seat and leaves the delivery risk with you. Engaging a firm moves the delivery risk across the table, which only helps if the contract names the production outcome rather than an hour count. Most companies should build eventually and cannot start there.
How to choose a forward deployed engineering partner
Judge a forward deployed engineering partner on five things, in this order: which of the three jobs their engineers actually do, whether they will put a production date and a handover date in writing, what proves the code correct, how they decline work that only serves one customer, and who is accountable by name. A vendor who will not name a handover date is selling a dependency. A vendor with no answer on declining customisation will say yes to everything, and everything they say yes to becomes something you maintain.
Questions to ask a forward deployed engineering vendor
Twelve questions, each with the answer you want and the answer that should worry you. Five of them come from a16z partner Marc Andrusko, who wrote them as pressure tests for investors evaluating companies using this model; they work at least as well from the buyer's side of the table. The most revealing question on the list is how the vendor systematically declines customisation requests, because a vendor with no answer will say yes to everything and you will maintain all of it.
Security and access for embedded engineers
Letting an outside engineer into your systems is a real risk and it is manageable with four rules: least privilege by default, repository access scoped to the repositories the work touches, production access as a named exception with an audit trail and an end date, and revocation on the handover date rather than whenever somebody remembers. What changes when a model writes the code is that the review gate before production matters more, not less, because generated code is not secure by default.