Explain what a forward deployed engineer owns that no other customer-facing role owns
Place the FDE among consultants, sales engineers, and solutions architects without mixing them up
Describe why AI companies suddenly need this role, in one sentence you could say in an interview
Recognise the two failure modes the role was invented to avoid
Somewhere right now, an engineer is sitting in a customer's office, on the customer's network, writing code that will run on the customer's servers. Their badge says visitor. Their commit history says otherwise.
That engineer is forward deployed. This lesson is about what that means, why the role exploded, and why it might be the most interesting job in software right now.
A forward deployed engineer is a software engineer who embeds inside a customer's organisation and ships production software there, using their company's platform to solve that customer's specific problem.
Every word in that sentence is doing work. Embeds: not visits, lives there for weeks or months. Inside the customer's organisation: their network, their data, their security rules, their meeting rooms. Ships production software: not slides, not demos, running systems that people rely on. Their company's platform: the FDE is not a freelancer. The point is to make the product succeed in a place it could not succeed alone.
What Do You Think?
A large insurance company buys an AI platform. Six months later, nobody there uses it. The platform works fine in demos. What is the most likely reason?
Your Reflection
Saves automatically
What’s one thing you learned? What’s still confusing?
Palantir invented this job in the early 2010s. Their software analysed data for governments and huge enterprises, which meant their customers were exactly the organisations least able to adopt new software: bureaucratic, siloed, security-obsessed, sometimes literally air-gapped from the internet.
Palantir's answer was to send engineers to the customer. Not support staff, not consultants. Engineers with commit access, empowered to build whatever the deployment needed. Internally they called these engineers Deltas. Alongside them worked Echoes: strategists who understood the politics, the workflows, and the adoption barriers inside the customer.
The bet was enormous. The Pragmatic Engineer newsletter reported that by 2016, Palantir employed more forward deployed engineers than ordinary software engineers. The company built its entire delivery model, and eventually its Foundry platform, out of what those engineers learned in the field.
For a decade, forward deployment stayed mostly a Palantir thing. Then large language models arrived, and every enterprise on earth wanted AI, and almost none of them could make it work alone.
Think about what adopting an LLM actually requires. The model must connect to the company's own data, which is scattered and messy. Outputs must be evaluated, because a system that is right most of the time needs someone to measure exactly how often. It has to run inside security and compliance constraints written before AI existed. And the whole thing has to survive contact with employees who did not ask for it.
Model vendors discovered what Palantir discovered: you cannot ship that gap closed from headquarters. So OpenAI built an FDE team. Anthropic hires for the role. So do Palantir-alumni startups across fintech, defence, health, and logistics. The job listings grew so fast that entire prep industries appeared around the role.
The map above is worth internalising, because in interviews and in real orgs, these five jobs blur together. Two questions separate them cleanly.
First: does this person mostly build or mostly advise? Second: does their work live in the vendor's world or the customer's world?
A consultant advises in the customer's world and then leaves. A sales engineer builds demos in the vendor's world to help close deals. A solutions architect designs the implementation and hands the design over. A product engineer builds the platform itself and may never meet a customer. The FDE is alone in the top-right corner: building, in production, inside the customer's world, and staying accountable for the outcome.
Descriptions of the role from people inside it repeat the same phrase: it feels like being a startup CTO. Palantir uses those words in its own job descriptions. You get a high-stakes problem, a small team, direct access to the people who matter, and end-to-end ownership of the result.
A typical stretch mixes three kinds of work. Customer-facing days: on site, watching users, debugging in their environment, sometimes in places with no internet access at all. One Palantir engineer described working on the final assembly line at Airbus. Build days: heads down on pipelines, integrations, and fixes, like any other engineer. And product days: packaging what the field taught you into feedback the core engineering team can act on.
That third part matters more than it looks. At OpenAI, an FDE team working on call-centre automation found the voice model was not good enough, built evaluations proving exactly where it failed, and worked with the research team on improvements. The fixes shipped into the product for every customer. Field work became product work. That loop is the whole economic argument for the role.
Everything about how good FDE teams operate follows from avoiding two traps.
The first trap is shipping a product nobody can adopt. That is the world before FDEs: great demo, failed rollout, quiet churn a year later.
The second trap is becoming a consulting firm. If every customer needs bespoke engineering forever, revenue only grows by hiring more engineers, and the product never gets smarter. Palantir's escape was a discipline they describe as turning gravel roads into paved highways: the bespoke thing you hacked together for one customer becomes a pattern, the pattern becomes a feature, and the next customer gets it out of the box.
Hold onto both traps. The rest of this track, from exit criteria to productisation, is a set of tools for steering between them.
Quick Check1 / 4
What does an FDE leave behind at a customer that a solutions architect typically does not?
An FDE embeds inside a customer's organisation and ships production software there, using the vendor's platform, and owns the outcome.
Palantir invented the role for customers too complex to adopt software alone, and by 2016 had more FDEs than regular engineers, per The Pragmatic Engineer.
Two questions separate the confusable roles: build or advise, and vendor's world or customer's world. The FDE builds, in the customer's world, and stays.
LLMs made the adoption gap universal, which is why AI labs now hire FDEs aggressively.
The role steers between two traps: products nobody can adopt, and consulting that never becomes product.
Next: the shape of a real engagement, phase by phase, and the exit criteria that keep it from turning into open-ended consulting.