What Forward-Deployed Engineering Actually Means.
Most companies claiming the label deliver something else entirely. The real practice has a five-part test.
The phrase forward-deployed has gone from a specific engagement practice to a widely-applied label in about four years. Every Fortune 500 buyer scoping AI work today has been pitched at least one team calling itself forward-deployed. The practice the phrase originally named remains specific. Most engagements bearing the label deliver something else.
If you are paying the premium for the original practice and receiving the standard one, you should know.
The original practice
Forward-deployed engineering meant something specific. Senior engineers placed inside the customer team. Same repo. Same CI/CD pipeline. Same standup. Code review with the people who will operate the system afterward.
The engagement model produced a different result. Knowledge transfer was not a final-week event. It was the entire shape of the work.
The label has since drifted from the practice. It is now applied to remote-first delivery with a weekly sync, to vendor-led builds that arrive at the customer finished, and to embedded teams whose embedding is mostly nominal. The premium is still charged. The model that earned the premium is missing.
Why this is not a vocabulary problem
Engagement model is where many transformation programs actually fail. McKinsey has placed the failure rate for business transformations around 70% in research dating back to at least 2019, and the figure has been consistent across multiple studies (McKinsey). The precise benchmark varies by methodology, but the lesson is stable: large enterprise programs underdeliver when the operating model cannot absorb the change.
When you read the post-mortems, the same pattern appears.
The team that built the system left. The team that has to operate it was never trained. The code lives in a repo the operations team cannot access. The CI/CD pipeline is bespoke and undocumented. There is no continuity from build to operations.
These are not technology failures. They are engagement-model failures. And every one of them is structurally invited by a delivery model where the people writing the code and the people running it never share a working surface.
The five tests
An engagement is forward-deployed if these five conditions are met. Anything less is a different engagement model wearing the same label.
Commit rights in your repo. Not a separate fork. Not a parallel project that ships as a tarball at the end. The engineers commit to your code, with code review and merge happening alongside your team.
Your CI/CD pipeline. Not a parallel pipeline. The same checks, the same deployment process, the same observability stack the operating team uses every day. If the system passes CI on the delivery team’s own pipeline but not on the customer’s, the engagement is not forward-deployed.
Your calendar. Standups, sprint planning, code review, retrospectives — on your schedule, in your tools, with your team. A weekly sync call is not this.
Reachable on your chat. Slack or Teams during your working hours. Not a separate channel that nobody monitors. Not “we will reply within 24 hours.”
Skills your team keeps. Pairing, written runbooks, and code review designed in from week one — not a final week of handoff that the operating team cannot attend because they are firefighting something else.
All five must be present. Four of five is a partial engagement. Three of five is a different model entirely. The full set is what earns the premium.
When not to pay for it
Forward-deployed engineering is not the right answer for every project. Do not pay the premium when the system is temporary, when the work is safely isolated from production operations, or when your team has no intention of owning the system after launch.
In those cases, buy a packaged product, hire a specialist vendor, or run a bounded consulting engagement with a clean deliverable. That is not failure. It is scope discipline.
Pay for forward-deployed engineering when the system will outlive the engagement and your own team must be able to operate, audit, and extend it. The premium only makes sense when capability transfer is part of the result.
The economics
The model carries a premium on per-hour rates. Senior engineers are expensive, embedding takes commitment on both sides, and the work is not leveraged across larger delivery teams the way commodity engagements are. The premium is earned over the engagement’s full lifecycle, not its first quarter.
The cost is paid back three ways.
Time-to-production can be shorter. DORA’s annual research on software-delivery performance supports the underlying delivery claim: teams with strong CI/CD, fast feedback, and recovery discipline deploy more frequently and recover from failures faster. Forward-deployed work is valuable when it lets the customer’s team participate in those same delivery practices rather than receiving a finished system after the fact.
Handoff costs go to near zero. There is no handoff because the team operating the system helped build it. The runbook is not a deliverable; it is a byproduct.
And the customer team levels up alongside the engagement. The next program runs faster because the previous program’s people are still there.
How we work
At Loom we use this model on Applied AI, Harness Frameworks, and Enterprise Transformation engagements where the deliverable is a system the customer will run for years. A typical shape: two weeks of design and embed, eight to twelve weeks of ship-and-pair, and a deliberate hand-off period where the runbook and the team’s own code review notes are the artifacts.
We do not take engagements that cannot support this model. The math does not work otherwise, and the engagement model is exactly the variable most likely to produce the failures we have been hired to prevent.
When to talk to us
The engagement model is what determines whether the system survives the team that built it. If you are scoping a program where the system will outlive the engagement — and in any production AI program, it will — talk to us about that first. This is the engagement model behind the build-vs-buy decision when “pairing” is on the table.
The technology decisions come second. The five tests above are the only definition of forward-deployed that survives a production audit.
References
- McKinsey & Company, Why do most transformations fail? A conversation with Harry Robinson (2019–2024). mckinsey.com
- DORA, State of DevOps / Software Delivery Performance Research (ongoing). dora.dev
About the author
Kevin Dickerson is a co-founder of Loom. His machine learning research predates the LLM era, and he has worked at the frontier of production AI across cloud platforms, semiconductor companies, and enterprise programs.
Continue reading
Build vs. Buy in the Agent Era: A Decision Framework.
The build-vs-buy decision is not about engineering capability. It is about whether you can sustain the thing you build.
Enterprise TransformationWhat Cloud Transformation Taught Me About Agentic Programs.
The hardest lessons of enterprise cloud transformation are about to be relearned in AI. Most of them are organisational, not technical.
CAIOThe Fractional CAIO Playbook.
Most full-time Chief AI Officer hires at this stage will fail. The work is real. The shape of the hire is wrong.