A forward deployed engineer leaves a working system inside the customer’s business, where a consultant leaves a deck. Both can be excellent, and both get hired for the same hard problems. The difference is who is still there when the system breaks, and who answers for it.
Key takeaways
- How a forward deployed engineer’s deliverable, access and accountability differ from a consultant’s.
- Where the role came from, and why the two jobs are being confused.
- When to hire each, and a quick check that works whatever the job title says.
What a forward deployed engineer leaves behind that a consultant does not
A forward deployed engineer is a software engineer who embeds inside a customer’s organisation, writes production code there and answers for whether the system gets used. A consultant typically leaves analysis, a recommendation and a roadmap. The customer’s team then has to build it.
McKinsey draws the same line in its explainer. According to McKinsey, Martin Harrysson sees the traditional consultant as more incentivised around a recommendation or plan, while Holger Hürtgen notes that an engineer works inside the client’s system, so “you leave behind the product”.
Job titles are unreliable, so look at access instead. A write-up from Hayat suggests asking who has write access to production. On its account, a consultant gets read access, exported data and a room to present findings in. A forward deployed engineer holds credentials to the live environment and commits code that runs there.
Picture an insurer that wants an AI agent to triage incoming claims documents. The consultant interviews handlers, maps the process, assesses data readiness and writes a target architecture. The engineer sits with the handlers, builds a first version against real documents, watches where handlers overrule it, and is the person called when an upstream format changes. Both pieces of work are legitimate. Only one of them can fail at 7am.
Where the forward deployed engineer role came from
The role is older than the current AI hiring wave. According to The Pragmatic Engineer, the forward deployed software engineer role was created at Palantir in the early 2010s and named “Delta”, and until 2016 Palantir had more of them than software engineers.
Demand has since spread well beyond Palantir. Nasscom Community reports that postings for the title grew roughly 729% year on year by April 2026, with AWS, Microsoft, OpenAI, Anthropic, Google and Palantir all building units around it.
Rapid spread brings dilution. First Round Review distinguishes the engineer from a traditional solutions consultant or sales engineer because the engineer still writes and debugs production code. It also quotes Shilpa Balaji, a former FDE recruitment lead at Palantir, saying the role has drifted towards implementation work that is not forward deployed engineering in the original sense.
The Certified Forward Deployed Engineer (CFDE)™ exists because a role that has spread this quickly needs a common reference point for what the work involves, and what separates it from advice and configuration.
How each role is measured
Incentives explain most of the behaviour. According to Gainam, consulting is typically measured on time and deliverables, which turns effort itself into the product, while an FDE engagement ties success to a working deployment. Treat that as one vendor’s framing, but it matches how the two roles tend to feel from the customer’s side.
AIU teaches a specific set of measures for the role.
AIU teaches that Forward Deployed Engineers are measured on three things: deployment velocity, customer success and product feedback quality.
None of these is a billing metric. Deployment velocity asks how quickly working software reaches real users. Customer success asks whether the customer’s work changed. Product feedback quality is the one consultants rarely have a channel for: the engineer sees what a live environment teaches and carries it back to the product team.
Hours-based work can still be honest and useful. The problem arises when hours are the only measure and the plan is the only output. A deck can be delivered on time, accepted and never built. A deployment that is not used shows up in the measures above.
Where the engagement ends
A consultant engagement usually ends when the deliverable is accepted. An FDE engagement ends when the customer can run the system without the engineer. The shape of the work differs from the first week.
AIU teaches the deployment lifecycle in seven stages: post-sale handoff, discovery, scoping, build, deploy, iterate and hand-back.
Several of those stages sit before and after the code. Discovery and scoping look like consulting, and a good engineer does them properly, because a system built on a misread problem is still the wrong system. Build, deploy and iterate are where the paths separate: the engineer ships into live conditions and changes course on what users actually do.
Hand-back is the stage consultants rarely face. It is the point at which the people who will own the system must be able to operate, debug and extend it. An engineer who cannot hand back has created a dependency, not a deployment. That is also why the best engineers are slightly uncomfortable with being indispensable.
When to hire a consultant, an engineer, or both
Neither model wins every time. Phaedra Solutions suggests a consultant fits when the business needs strategy, assessment, vendor selection or a roadmap, and an FDE fits when the direction is reasonably clear but difficult technical execution still needs an owner. It adds that consulting works well when an internal team has the skills and capacity to build the recommendations.
The two jobs also overlap. In the McKinsey explainer, Nick Robson says the roles are merging and that a really good consultant makes a really good FDE. The same piece suggests the term may be a buzzword for a service consulting firms have offered for years. Hayat is blunter: it says the rebrand accusation holds for part of the market, citing Deloitte’s Forward Deployed Engineering service page and a Fujitsu bundle. Swiftwater adds that a consulting engagement can include forward deployed engineers alongside advisors.
So the title tells you little. A check that works whatever the contract says is the Signature Test.
Who signs the risk statement before go-live?
The answer shows who carries the risk, which is the practical difference between advising and delivering.
FDE vs Solutions Engineer vs AI Engineer: the ownership test
If you want to be assessed on this work rather than describe it, the next step is below.
Explore the CFDE Foundation programme →
Frequently asked questions
What is the difference between a forward deployed engineer and a consultant?+
A consultant typically delivers analysis, a recommendation and a roadmap, then leaves the customer’s team to build it. A forward deployed engineer embeds in the customer’s environment, writes production code and stays accountable until the system is live and the customer can run it.
Is a forward deployed engineer just a consultant with a new title?+
Sometimes, because some firms have renamed an advisory team without changing the engagement. A genuine forward deployed engineer has write access to production, ships code into the customer’s stack and is judged on whether the deployment works, not on the quality of a document.
Should a company hire a consultant or a forward deployed engineer first?+
Hire a consultant when the open question is what to build, buy or prioritise. Hire a forward deployed engineer when the direction is clear and the difficulty is building, integrating and running the system in production. Many organisations need both, in that order.
