What Is a Forward Deployed Engineer?

A forward deployed engineer (FDE) is a software engineer who works inside a customer’s world instead of behind the product team’s walls. They sit with the customer’s people, get access to the customer’s systems and data, and write the code that turns a general product into something that solves that customer’s specific problem.

That is the short version. The longer version matters if you are about to hire one, because the title now covers several quite different jobs. This guide walks through where the role came from, what the work actually looks like, why AI companies made it famous, and how to tell a real FDE role from a renamed one.

Where the Role Came From

The job was invented at Palantir. Internally, Palantir calls its forward deployed software engineers “Deltas,” a nickname that dates back to when its business development teams were named after letters of the NATO alphabet. Palantir’s own blog post Dev versus Delta is still the clearest description of the split. A product engineer (“Dev”) owns a piece of the platform that ships to every customer. A Delta works with one customer and is measured by the impact on that customer’s goals.

Palantir sums it up in one line. A Dev builds one capability for many customers, while a Delta’s focus is “one customer, many capabilities.” If you remember nothing else from this guide, remember that line. It is the cleanest test of whether a role is truly forward deployed.

Why did Palantir need this? Its early customers were government agencies and large enterprises with sensitive data, slow procurement and complicated systems. As PostHog’s explainer on the role recounts, even a simple demo could take weeks of NDAs and clearances. Sending engineers to work on site, side by side with the customer, was faster than trying to do everything from headquarters.

The role was big at Palantir for a long time. The Pragmatic Engineer reports that until around 2016 Palantir had more FDEs than traditional software engineers, and that when Foundry launched, many of them moved into core product work and carried their field experience with them.

What an FDE Actually Does

The work changes week to week, but it tends to fall into five buckets.

• Scoping. Sitting with the customer to figure out what problem is worth solving first. The customer’s description of the problem is often not the real problem.
• Integration. Getting at the customer’s data and systems, which are usually messier than anyone admitted in the sales process. This is often the bulk of the work.
• Building. Writing the workflows, pipelines, apps and configurations that make the product useful in that environment. Real code, often in production.
• Running it. Monitoring, debugging and fixing things when they break. Palantir’s day in the life post describes an FDE maintaining a terabyte-scale pipeline and chasing down a production outage alongside product and customer teams.
• Feeding the product. Bringing patterns from the field back to the core product team, and sometimes contributing code to the product directly.

That last bucket is what separates an FDE from a consultant. Palantir is explicit about this: consultants tend to deliver a one-time analysis, while FDEs deploy software, stay with the customer, and build things that last. A good FDE also reuses what they build. If they solve a problem for one customer, they package it so the next deployment starts further ahead.

How the Time Splits

Expect a mix of on-site and off-site work. In the Palantir post, an FDE in Abu Dhabi describes spending a couple of days a week at customer premises and the rest of the week coding, reviewing and planning. The Pragmatic Engineer notes that the on-site share varies by company, from about a quarter of the time at Palantir to as much as half at others. Henley Wing Chiu’s analysis of about 1,000 FDE job postings found that 68% required travel.

Why AI Companies Made the Role Famous

For a decade the FDE was mostly a Palantir thing. Then AI changed the math.

In June 2025, a16z partner Joe Schmidt published Trading Margin for Moat, calling the FDE the hottest job in startups. His argument, in brief:

• Enterprises want AI, but they need someone to set it up for them.
• An AI agent is only useful once it is wired into a company’s real systems, data and permissions. Onboarding an agent looks a lot like onboarding an employee, and someone has to manage that.
• Doing that implementation work lowers gross margins early, but it lets a startup become the system the customer’s work actually runs through. Schmidt points to ServiceNow and Workday, which went public with margins well below typical software levels and improved them later.

The big labs followed. OpenAI built a dedicated FDE team in 2025. The Pragmatic Engineer describes how OpenAI distinguishes FDEs from its Solutions Architects: Solutions Architects are more advisory and usually prototype on offline or anonymized data, while FDEs write code directly on customer systems and deal with more ambiguity. OpenAI’s own FDE job posting asks for people who own delivery from first prototype to stable production, embed with customer teams, and feed field learnings back to Research and Product. Anthropic’s FDE postings read similarly, asking for engineers who build production applications inside customer systems and codify repeatable deployment patterns.

PostHog’s write-up adds a few reasons the fit is so good for AI specifically. Executives are skeptical until they see results on their own data. Getting that data means earning trust and access. And AI contracts are often large enough to justify sending engineers on site for months.

A Worked Example

Here is an illustrative scenario of a typical first deployment. It is not a real client story, but it is the shape most engagements take.

Imagine you sell an AI agent that handles customer support for insurance companies. You sign a mid-sized insurer. The sales team promised the agent would resolve policy questions automatically.

Week 1. Your FDE spends three days on site with the support team. They listen to calls, read tickets and sit with the people who handle escalations. They learn that “policy questions” really means two very different things: simple coverage lookups, and billing disputes that need a human.

Weeks 2 to 3. The FDE gets access to the policy database and the ticketing system. The database has three different customer ID formats. The ticketing system has no API for one of the fields the agent needs. The FDE writes the integration, builds a mapping layer for the IDs, and works around the missing API.

Week 4. The FDE builds an evaluation set from a few hundred real tickets labeled by the insurer’s own team. The agent is strong on coverage lookups and weak on anything involving billing. The FDE scopes the launch to coverage lookups only, with a clean handoff to humans for billing.

Week 6. The agent goes live on coverage questions. The FDE monitors it daily and fixes edge cases.

Week 8. The FDE writes up the ID mapping layer and the evaluation approach as reusable pieces, and tells the product team that billing disputes are a gap every insurer will hit.

Notice what happened. The FDE scoped, integrated, built, ran and fed the product. A solutions engineer would have stopped at the demo. A product engineer would never have seen the three ID formats.

How to Tell a Real FDE Role From a Renamed One

The title has become popular, and popular titles get stretched. The Bloomberry analysis found that “Forward Deployed Engineer” postings actually describe three different jobs. About 60% were builder roles that embed with customers and own production systems. About 30% were sales or solutions engineering roles under a new name, often with a quota. About 10% were internal tools or RevOps roles.

Natalie Meurer, who was an FDE at Palantir and now leads agent engineering at Sierra, made the same point in her talk The Dirty Secret of Forward Deployed Engineering. The label has become vague. Her suggestion is to ask candidates what vintage of FDE they are, because the Palantir role itself shifted over the years from infrastructure work, to data integration, to custom applications, to enabling customers to build for themselves.

A few questions cut through the noise:

• Does the person write production code that runs in the customer’s environment? If not, it is probably a sales or solutions role.
• Do they stay after the contract is signed? FDE work starts in earnest after the sale.
• Do they carry a quota? The Bloomberry analysis found that quota language showed up in sales engineer postings and none of the FDE postings in its sample.
• Do their learnings change the product? If field feedback goes nowhere, you have hired an implementation contractor, not an FDE.

For a side-by-side breakdown, see our guide on FDE vs Solutions Engineer vs Sales Engineer.

What Makes a Good FDE

Palantir’s list of Delta skills still holds up: breaking a fuzzy business problem into a concrete technical design, working autonomously, strong technical intuition, and good judgment about when to build something custom versus pushing for a product feature. Add empathy for users and a feel for the customer’s business.

In practice, the best FDEs share a few traits:

• They are real engineers. They can ship production code in an unfamiliar codebase without hand-holding.
• They are comfortable being wrong in front of customers. Scoping means asking naive questions and changing plans.
• They push back. A former Palantir FDE quoted by LeadDev describes the job as testing whether the customer’s proposed solution is actually right, then offering an evidence-backed alternative.
• They own outcomes. Not tickets, not hours. Whether the customer got value.

If you are hiring for this, our guide on how to hire your first FDE covers seniority, sourcing and the interview loop, and our interview questions for FDEs gives you questions to use.

Where We Come In

Forward Deployed Hiring only places FDEs, and it is run by a former FDE. Every candidate passes a technical screen and a live customer role-play before you meet them, and you run the final interviews yourself. Interviewing our candidates is free, so if you are ready to start hiring, we are happy to help.