Forward deployed engineer: what the role actually is
A forward deployed engineer is a software engineer employed by a product company who works inside a customer’s organisation to make that product solve that customer’s real problem. They write code, but not on the product: they write it against the customer’s data, their systems and their constraints. The title was popularised by Palantir, which was using it for staff by 2009, and the phrase itself is borrowed from military usage: forward deployed means stationed where the work happens rather than at headquarters. The role spread far beyond its origin during the enterprise adoption of AI, because companies discovered that the distance between a model that works in a demo and a model that changes how an organisation operates is not a product gap. It is a deployment gap, and it has to be closed by somebody standing in the customer’s building with commit access.
The shortest accurate definition
Every other engineering role in a software company is pointed at the product. The forward deployed engineer is pointed at one customer. That single difference produces all the others.
A product engineer asks whether a change is right for every customer. An FDE asks whether it is right for this one, this quarter, given the data they actually have and the review board they actually have to get past. Work that a product engineer would refuse as unscalable (a one-off connector, a hand-tuned prompt for a single department, a migration script that will run exactly once) is often precisely the right answer for an FDE, because the thing being optimised is not the codebase. It is whether the customer’s work changed.
That does not make it a lower-rigour job. The code runs against production data in somebody else’s company, usually under their security review, frequently in a regulated industry, and the engineer is the only person from the vendor who will see the failure. The bar on judgement is higher than on a product team, not lower; the bar on generality is the one that moves.
Where the title came from
Palantir is where the term entered software. The company was using it for staff by 2009, and the structure it described was unusual at the time: rather than selling a platform and leaving integration to a systems integrator, the vendor sent its own engineers to live inside the customer and build on top of the platform there. The borrowed military phrasing was not decoration. It described a deliberate choice about where the engineer sits.
For roughly a decade the model stayed largely associated with that one company and with government and defence work. What changed is not the idea. What changed is that a great many more software companies suddenly had the same problem.
Why the role spread when it did
The enterprise adoption of AI exposed something uncomfortable. A model can be demonstrably capable and still produce nothing inside a company, and the reasons are almost never about the model. They are about data that lives in four systems with three different definitions of the same customer. About a process that exists in somebody’s head rather than in the documentation. About a security review that will not approve an outbound call. About a team whose bonus depends on the old way of working.
Software companies had historically handed exactly that category of problem to partners and systems integrators. When the product is a model, that arrangement breaks down, for a reason worth stating plainly: the person closing the gap has to be able to change the product’s behaviour, not only configure it. They need to write retrieval logic, adjust how the system is evaluated, and feed back what they learn to the people building the core. A partner cannot do that. An employee can.
So the vendors started doing it themselves. Frontier labs, cloud providers and enterprise software companies now all staff some version of this function, under a variety of names. The industry-analyst reading of the shift is that deployment has stopped being an aftermarket service and become part of the product organisation.
What the role is not
Three confusions come up constantly, and each one matters because it changes what the job is measured on.
It is not pre-sales. A solutions engineer proves in front of a prospect that the product can do what the account needs, and is judged on whether the deal closes. An FDE arrives after the signature and is judged on whether anything actually changed. The two roles often sit on the same account and are sometimes filled by the same person, which is where the confusion comes from. But a demo that impresses and a deployment that sticks are different achievements.
It is not consulting. The customer does not pay the FDE’s salary. This sounds like an administrative detail and is in fact the structural difference between the two jobs: a consultancy’s incentive is a renewed engagement, and a product company’s incentive is a customer who no longer needs anybody in the building. An FDE who has made themselves unnecessary has succeeded. A consultant who has done the same has lost an account.
It is not customer success with commit access. If the role never ships code, it is not this role, whatever the posting says. Job titles are not standardised across companies: the same work appears as forward deployed engineer, deployment engineer, field engineer, applied engineer or solutions architect depending on the employer. The only reliable way to read a posting is to look at what it says the person will build.
We keep a five-axis comparison of the role against the four it is most often confused with, because the differences are easier to see side by side than in prose.
What the work looks like from the inside
The shape of a deployment is fairly consistent even when the industry is not. It starts with a problem the customer has described in their own vocabulary, which usually has to be translated before it can be built against. The stated problem and the real one differ more often than not, and finding that out is the first week’s work, not a preliminary.
Then comes the part that consumes most of the calendar and appears in none of the marketing: getting at the data. It is in systems nobody documented, owned by people who were not consulted about this project, in formats that disagree with each other. An engineer who finds this beneath them will not last in the role, because it is the role.
Building comes next, and it is genuinely engineering: connectors, retrieval, evaluation against cases the customer recognises, and the unglamorous work of making a system fail safely in front of someone who does not trust it yet. Then adoption, which is the part that decides whether any of it counted. A system that is correct and unused has failed. Getting it used means sitting with the people whose work it changes, watching them not use it, and finding out why.
Last, and most easily skipped: handing back what was learned. The reason a product company pays for this role rather than outsourcing it is that the engineer sees, first-hand, which parts of the product do not survive contact with a real organisation. That observation is worth more than the deployment.
Who hires for it
The role is no longer confined to one company. Frontier AI labs, the large cloud providers and a widening set of enterprise software vendors all staff it, and major firms announced divisions organised around it during 2026. Postings grew sharply across 2024 and 2025 and kept growing into 2026.
We do not publish salary figures on this site, and it is worth explaining why rather than quietly omitting them. The public numbers for this title disagree with one another by a factor of four, because the aggregators are averaging postings that share a heading and nothing else. A deployment role at a frontier lab and a field support role at a mid-market vendor are not the same job. Publishing a single average would be easy, would rank, and would be misleading. We will publish compensation ranges when we maintain our own posting-level dataset and can show its method; until then, the honest answer is a range we have not earned the right to state.
Is the role right for you?
The people who do well in it tend to share one trait that is hard to interview for: they are not offended by unglamorous problems. The job contains a great deal of work that a strong product engineer would consider beneath their level, sitting directly next to work that requires genuine depth. Someone who needs the whole job to be interesting will be miserable.
The second filter is tolerance for being the only person from your company in the room. There is no team to escalate to in the moment, the customer is watching, and the judgement call is yours. Some engineers find that the best part of the job. Others find it exhausting, and there is no shame in being the second kind. The role is discussed unfavourably by some practitioners precisely on these grounds, along with the travel.
If it does suit you, the compounding is unusual. Few engineering roles put you in front of senior decision-makers at a dozen organisations in two years while still writing code. That combination is why the path out of the role is wide: deployment leadership, product management with field credibility that product managers rarely have, or founding something in a domain you have now seen from the inside.
