A forward deployed engineer (FDE) is an engineer who embeds with a customer and owns getting the software to produce a real result inside that customer's environment. Not a demo, not a recommendation, not a handover document: a working system in a messy real business, with the engineer accountable for whether it works. The title comes from Palantir, and it has spread across the AI industry for one reason — the hard part of AI is no longer building the capability. It is deploying it.
In short
- FDEs write code and sit with the customer. Both halves are the job.
- The title originated at Palantir, where the role is Forward Deployed Software Engineer and was known internally as Delta.
- The role is growing because deployment, not capability, is the bottleneck in enterprise AI.
- The skill stack is unusual: domain fluency, diagnosis, integration engineering, measurement and handoff.
- You can build proof of these skills before anyone gives you the title.
Where the title comes from
Palantir created the role. In The Pragmatic Engineer, Gergely Orosz reports that Palantir established the forward deployed engineer position in the early 2010s, originally calling it "Delta," and that hiring for the role has since expanded to companies including OpenAI, Ramp and Salesforce. The reason it was invented is instructive: powerful software kept failing to turn into operational results at the customer, so the company started sending engineers to the customer instead of sending documentation.
Palantir's own current Forward Deployed Software Engineer posting describes the model as embedding engineers directly with customers to tackle their most pressing challenges, and asks the engineer to own the end-to-end execution and implementation of high-stakes projects: collaborating on architecture, managing large-scale data with AI, developing custom applications, and engaging directly with customer stakeholders. The stated requirements are notably plain — at least one year of relevant post-college experience, strong coding in a language such as Python, Java, C++ or TypeScript, an analytical approach, and the ability to work in teams of technical and non-technical people.
On a typical week, Orosz reports FDEs splitting their time between working at customer premises, meetings with stakeholders, and monitoring, debugging, deploying and configuring software — plus pushing fixes back into the core product when it gets in the way of the customer's implementation.
That last part is the quiet superpower of the role. The FDE is the only person who sees, at the same time, what the product promises and what the customer's reality does to it.
Why the role exploded with AI
Every company now has access to roughly the same models. Almost none of them have their processes, data and permissions in a state where those models can produce revenue.
The gap is not intelligence. It is that a model does not know your pipeline stages, does not know that two of your fields contradict each other, does not know which branch manager will refuse to use a tool, and cannot tell that your compliance constraint makes the obvious design illegal. Someone has to sit inside the business and close that distance — writing the integration, mapping the real process, choosing where a human must stay in the loop, and proving the result with a number.
That job description is the forward deployed engineer. It is also, almost exactly, what MitHub teaches in the Revenue Reverse Engineering faculty: trace the money backwards, diagnose, prove value fast, operate, publish the case study.
FDE vs the roles it gets confused with
| Role | Primary output | Who owns the result | Typical failure mode |
|---|---|---|---|
| Forward deployed engineer | Working system in the customer's environment | The FDE | Builds what was requested instead of what produces the outcome |
| Solutions / sales engineer | A convincing demo and technical answer in the sales cycle | Sales | Demo works, deployment does not |
| Consultant | Analysis, recommendations, a plan | The client | Great plan, nobody implements it |
| GTM engineer | Revenue systems inside their own company | The GTM team | Optimizes tooling, not pipeline |
| Platform / product engineer | One capability used by many customers | Product | Ships features no customer operationalizes |
The cleanest distinction is scope of loyalty. A product engineer builds one capability for many customers. A forward deployed engineer builds many capabilities for one customer. Everything about the role — the ambiguity, the travel, the direct exposure to whether it actually worked — follows from that inversion.
The MitHub FDE Stack
Five layers. Most people who want this job have one or two and assume the rest are soft skills. They are not; they are the job.
1. Customer fluency. Learn a domain fast enough to challenge it. You should be able to describe how the customer makes money, what their week looks like, and which three numbers their boss is judged on — within your first week. Without this, you build technically correct things nobody uses.
2. Diagnosis. Map the real process, with numbers, and find the constraint before proposing anything. This is the discipline in process mapping before automation, and it is what separates an FDE from a contractor taking orders.
3. Integration engineering. APIs, webhooks, authentication, data shapes, idempotency, retries, error handling. Not glamorous. It is where deployments actually die — usually at the seam between two systems, at 4pm on a Friday, on the 3% of records that are malformed.
4. Measurement. Define the number before you build, instrument the system so every run leaves a signal, and be willing to report that the number did not move. An FDE who cannot prove the result is a contractor with a laptop.
5. Handoff. Document, train, and make yourself unnecessary at this account so you can go be necessary at the next one. The instinct to become indispensable is the single most common career-limiting move in this role.
Underneath all five is one trait that shows up in every FDE job description in some form: tolerance for ambiguity. You will routinely be the only technical person in a room full of operators, with an underspecified problem and a customer who cannot articulate what they want until they see something wrong.
Where the FDE sits on MitHub's ladder
MitHub describes capability in four steps: Doer → Director → Designer → Owner, explained in Director vs Doer.
A forward deployed engineer operates as a Designer — building the systems and workflows — while being held to an Owner's standard, because they are accountable for the business result in someone else's building. That is why the role pays and travels well: it is one of the few jobs where a single person is measured on an outcome, not on output.
How to build proof before you have the title
You do not need permission to practise this. You need one real environment and three artifacts.
- Find a real operator with a real problem. A small business, a nonprofit, a friend's agency, your current employer's ugliest internal process. Real beats hypothetical every time.
- Produce a diagnosis document. The current process, mapped, with numbers and the constraint identified. This alone puts you ahead of most applicants.
- Build the smallest system that moves one number. Integrated with their real tools, logging every run, with a human approval where the mistake would cost something.
- Measure for 30 days and report honestly, including what did not work.
- Write it up as a case study — situation, path, result, evidence — using the structure in Your case study.
Three of those and you can hold a conversation with any hiring manager for this role, degree or no degree.
What makes FDEs fail
- Building what was asked instead of what produces the result. The customer's request is a hypothesis, not a specification.
- Skipping the baseline. Without a before, there is no after, and your work becomes a matter of opinion at renewal time.
- Going native. You are there to change how the work happens. If you end up doing the work by hand because it is faster, the deployment has failed quietly.
- No documentation. Knowledge stuck in one head is a system failure, not job security.
- Treating a green run as a result. The workflow executing successfully is not the same as the business result appearing in the customer's system. Go look at the record.
On pay
Compensation for FDE roles varies widely by company, level and location, and public aggregate figures for a title this new are unreliable. The honest advice: read the ranges published on actual postings at the companies you are targeting, and compare against adjacent roles — see GTM engineer salary for how to research this properly rather than trusting a single number.
Where to go next
The adjacent roles share most of this stack, so read them before you pick a lane — the closest is how to become a GTM engineer, which covers the same diagnosis-and-integration work aimed at a company's own revenue systems. Then stop reading and go build the first artifact: Learn, build, prove, earn.