Forward deployed engineer: what an FDE really is

This page gathers what you need to know about the forward deployed engineer, starting with where the term comes from and what it means today. It then looks at the actual work: a typical day, what the role is not, and the skills it requires. Next come the reasons the model is back, what it changes for a mid-sized organisation, and the functions where it gets deployed. The last part covers the buying questions: how an engagement unfolds, the tooling, how it compares with other ways of buying software, whether to hire or buy it as a service, how to measure results, and when it is the wrong model. Each part links to a dedicated article.

Where the term comes from, and what it means today

Forward deployed is military vocabulary. To be forward deployed is to operate at the point of action rather than command from a rear base. Palantir borrowed the phrase in the early 2010s, out of operational necessity rather than organisational theory.

Its first customers were US government agencies. Their data never left their walls. Exporting a sample to a remote team to build against was impossible. So was running normal user interviews, because the customer could not openly state what it needed. Classic product development, which assumes a need that can be expressed and users who can be questioned, simply did not work.

Palantir did the opposite. Instead of bringing the need to the engineers, it sent the engineers to the need. They moved into customer offices for weeks or months, wrote production code on site, debugged pipelines on classified hardware, and sat in the customer's team meetings as if they belonged there.

Deltas and Echos

Internally these engineers were called Deltas. The definition fits in one sentence: a developer focuses on one capability for many customers, a Delta on many capabilities for one customer. Alongside the Deltas, Echo teams brought in people from the customer's own world, military, medical, financial, whose job was to identify the right problem before anyone wrote code.

The model became central to the company. Until around 2016, Palantir had more forward deployed engineers than conventional software engineers. It was not a service activity beside the product, it was the company's main discovery mechanism.

From gravel road to paved highway

That is the second thing separating the model from one-off consulting. Each FDE built a solution tailored to one customer with whatever was at hand. Product teams then turned the patterns recurring across customers into standard platform features. A gravel road cut in the field, paved by the product once the traffic justified it.

The word has since left the classified context. It describes a way of delivering software built on four traits. The code runs on real data, not a test fixture. The provider answers for an outcome, not for a version matching a spec. The specification emerges from observing real work instead of preceding it. And the presence lasts long enough for the engineer to understand the business, not just the request.

What an FDE actually does

An FDE owns a solution end to end: understand the problem, build it, integrate it, put it into production under real constraints, and stay long enough to see whether people use it. There is no handover to an integration team after design, because design and integration are the same work.

A typical day

An hour or two in the morning at a user's desk. Not a formal interview, not a workshop with sticky notes: the real work, interruptions included. You note the detours, the copy and paste, the questions asked to a colleague because the answer is written nowhere, the steps the person always skips that no official procedure mentions.

The middle of the day goes to building. A version running on the customer's data, not a mockup. Incomplete, one case, no polished interface, but a verifiable result on a file the user recognises.

Late in the day or the next morning, you show it. The useful signal is not the opinion, it is what happens when the person puts their hands on the keyboard. Hesitation means the mental model is wrong. A workaround means they handle a different case from the one you coded. Opening the old spreadsheet alongside means something essential is missing.

The rest goes into invisible work: getting access, working out why an export carries three date formats, negotiating a connector with the IT department, writing down what will let someone else pick up the code. None of that shows in a demo, and it usually settles the project's fate.

What it is not

The term is starting to circulate. Four neighbouring models get confused with it regularly.

It is not consulting. A consultant produces analysis and recommendations. The engagement ends when the document is handed over, and execution belongs to someone else. An FDE delivers code running in production. The document, if any, is a by-product and never the deliverable.

It is not a fixed-price project. Scope is frozen before day one and anything discovered afterwards becomes a change request. A coherent model when the need is stable, an expensive one when it is poorly understood at the start, because discovery is treated as a contractual incident.

It is not staff augmentation. There you rent engineering hours to execute a specification written elsewhere, and the customer carries the responsibility of saying what to build. In a forward deployed model the provider helps define what to build, because it has seen the real work, and answers for the outcome arriving.

It is not support. Support handles incidents on an existing tool. An FDE builds. A provider spending its days answering tickets is not doing this work, whatever the invoice line says.

Four questions to check

Faced with a provider claiming to do forward deployed work, four questions are enough to tell a practice from a label:

• Where will the code be written: on your real data, or on a simplified test set that will never resemble your production ?
• Who carries the risk if the outcome does not arrive: does the provider answer for a result, or only for delivering a version matching a spec ?
• Who writes the specification: you, alone, before any observation, or a team that spent time with your users before proposing anything ?
• What stays with you at the end: an internal team able to evolve the tool, or complete dependence on the engineer who left ?

A provider without a clear answer to all four is probably selling staff augmentation under a more attractive name. The detailed differences, contracts and billing included, are covered further down and in the article devoted to them.

The skills the role really requires

Palantir's job posting gives the technical floor: solid command of a general-purpose language such as Python, Java, C++ or TypeScript, a scientific background, ease with large scale data, and willingness to travel to customer sites. One year of experience is enough to enter, which says something important: the barrier is not technical seniority.

It sits elsewhere. A good FDE combines qualities that rarely live in the same person.

• Broad engineering rather than deep. You need to connect a database, write a usable interface, build a connector, ship and monitor. A specialist in one layer of the stack stalls at the first obstacle outside their field.
• The ability to read an unfamiliar business. Understanding within days why a department books entries that way, why a sales rep fills that field last, and what the in-house vocabulary actually covers.
• Interviewing, without calling it that. Asking open questions of someone who did not ask for your visit, and spotting the gap between what you are told and what you see.
• Product judgement. Deciding what not to build. This is the rarest skill, because it means saying no to a legitimate request in the name of a more important outcome.
• Composure in meetings. An FDE talks to a director, a user and the IT department on the same day, with three vocabularies and three sets of stakes.
• Writing. What is not written down does not survive the engineer's departure.

That list explains why the profile is hard to hire: each quality on its own is common, the combination is not. We come back to it below, when choosing between hiring an FDE and buying the skill as a service.

Why the model is back now

The shift has been clear since early 2025. OpenAI built an FDE team at that point: starting with two engineers, it now exceeds ten, spread across eight cities and three continents. Ramp runs around fifteen, organised in small pods. The fund a16z called the role the hottest job in tech.

The underlying reason is the same as in 2010, with a different trigger. Back then the obstacle was confidentiality: data did not leave the building. Today the obstacle is the nature of the work itself. Connecting a language model to an organisation means knowing its vocabulary, its edge cases, its tolerated exceptions and what it is not allowed to say. None of that appears in a specification, because nobody knows it consciously enough to write it down.

A model connected to generic data gives generic answers. A model confronted with real files, real exchanges and real exceptions answers with the nuance teams expect. The difference is not settled by the choice of model, it is settled by time spent close to the real work. That is exactly what on-site presence enables and what remote delivery almost always misses.

What it changes for a mid-sized organisation

The model was born at very large customers, but nothing in its principle requires size. It requires a real problem, real data and accessible users. An organisation of a hundred people often meets those three conditions better than a large group, because the distance between leadership and the floor is short and access gets unblocked in one conversation.

The first change is organisational before it is technical. You have to accept that an outside engineer spends time sitting next to your teams before producing anything visible, and that a manager cannot hand over a closed specification on day one. It is closer to the trust you extend to a senior hire than to a supplier.

The second concerns who says what to build. In a classic project a user expresses a need, a project manager translates it, a provider implements it, and each translation loses information. Here the engineer sees directly what the user does. The shortcut is abrupt for organisations used to the long circuit, and it is where the value comes from.

The third is cost. Starting is more expensive than a classic engagement, because it begins with observation that produces no deliverable. What you get in exchange is a tool people use rather than a tool delivered to spec and abandoned. It also avoids the most common failure in business software: a prototype approved in a steering committee that never reaches production because it never met real conditions. We covered those conditions in our article on the prerequisites for moving a business POC into production.

The functions where it gets deployed

The model is not tied to a technical domain. It is tied to the presence of repetitive work, governed by unwritten rules, done by people you can go and watch. So it shows up in very different functions. We treat them separately on our FDE as a Service pages, because the constraints differ.

• Finance: reconciliation, closing, management control, reporting. Document-heavy processes where the business rule lives in a spreadsheet maintained by one person. Traceability matters as much as time saved.
• Marketing: content production, asset management, campaign tracking, qualifying inbound requests. High volume, subjective quality criteria, and a permanent need to keep control of what goes out.
• RevOps: CRM hygiene, deal routing, forecasting, the joints between sales, marketing and customer service. The issue is rarely the tool and almost always data consistency across teams. We wrote about the difference between a sales-facing FDE and a RevOps profile.
• Data: collection, cleaning, reconciliation across systems, making things available for analysis. The historic ground for the role, and where the gap between the theoretical schema and the reality of exports is widest.
• Project management: progress tracking, consolidating information across teams, alerting. A lot of time goes into manually collecting statuses the systems already know.

Depending on the need, the work takes the shape of a complete business application, an AI agent plugged into existing tools, a targeted automation of one process, or training run alongside the build.

How an engagement unfolds

A forward deployed engagement almost always follows the same sequence, even if the length of each step varies a lot.

• Short framing. Identify the process to observe and obtain access. It looks administrative, it conditions everything else.
• Observation. The engineer settles in and watches the real work. It ends when they can mentally reproduce a user's day, exceptions included.
• First useful version. A deliberately narrow scope, running on real data, handling one complete case rather than ten half cases.
• Short loops. Build, show, correct, in cycles of a few days. The longest part, and the one producing most of the value.
• Production. Permissions, monitoring, historical migration, fallback procedure. Not an end-of-project formality.
• Handover. It does not start at the end. An internal counterpart follows the build from day one and takes the tool over when the engineer leaves.

The detail of each step, with what triggers it and what ends it, is in our article on the forward deployed engagement method.

The tooling, briefly

Tooling comes up early in most conversations, and it matters less than people think. An FDE uses whatever is already in place at the customer as far as possible, because every added tool becomes a burden on the internal team the day the engineer leaves.

The tooling splits into a few families: data access and connectors to existing systems, the build environment and version control, coding assistants, the runtime for models when AI is involved, monitoring of what runs in production, and the written record. The selection rule is simple: prefer what the internal team will be able to pick up, even when a more powerful tool exists. The detail, and the criteria for choosing between an off-the-shelf solution and custom work, are in our article on the forward deployed engineer toolkit.

FDE or another buying model

The right model depends on one question: do you already know precisely what to build ?

If yes, if the need is stable and documented and the difficulty is purely execution, a fixed-price project or a staffing engagement does the job and often costs less. If the need is an off-the-shelf product to configure, a specialist integrator is better placed. If the question is strategic and no code is expected, that is consulting.

The forward deployed model wins when the uncertainty is about the what and not only the how: when users cannot explain their own process, when business rules live in unofficial files, when previous attempts produced a compliant tool nobody uses. The full comparison, billing and reversibility included, is in FDE, consultant, agency, staffing.

Hiring or buying it as a service

Once the model is chosen, the question is who carries it. Hiring an FDE internally has a decisive advantage: the accumulated business knowledge stays in the company, and the person gets better every year. It assumes you can find the profile, pay it at market level, and above all give it enough varied work that it does not stagnate once the first project ends.

Buying it as a service gives access to a team rather than a person, so to a wider range of skills, and removes the single-role risk. The cost is vigilance on handover: without a serious internal counterpart, the knowledge leaves with the provider.

Many organisations do both in sequence: an external service for the first projects, during which the future internal lead learns the practice, then a hire once the volume justifies it. The criteria are detailed in hiring an FDE or buying it as a service.

FDE and generative AI

Generative AI has two opposite effects on the role, which is what makes the subject interesting.

On one side it makes the FDE faster. Writing a first connector, exploring a poorly documented export, producing a throwaway interface to test a hypothesis: all of that now takes hours where it took days. The observe, build, show loop tightens, which mechanically increases how many round trips fit in a week.

On the other side it makes the role more necessary. A system producing text or decisions has to be bounded, and the bounds come from the business: what is acceptable, what never is, what must be verified before display. We apply a constant rule here: anything that commits the company, a price, an availability, a reference, an address, is computed by the system and verified before being shown, never produced freely by the model. Setting those rules requires having seen the edge cases, which means having been on site. The full analysis is in FDE and generative AI, why now.

How to measure that it works

A forward deployed project measures badly with the usual software project indicators. Schedule adherence and conformity to the initial scope say nothing, since the scope is meant to change with what you learn. A few signals hold up better.

• Spontaneous use. Do people open the tool without being asked, including in weeks when nobody is watching ? The hardest indicator to fake.
• Workarounds abandoned. Is the parallel spreadsheet everyone kept open now closed ? As long as it is there, the tool does not cover the real case.
• Time for the whole path. Not the time for one isolated step, but for the case end to end, reworks and exceptions included. The only measure the business recognises.
• Share of exceptions handled. A tool that covers the simple cases and pushes the rest back to manual moves work around more than it reduces it.
• Time to first internal change. How long after the engineer leaves does the internal team make its first change alone ? If the answer is never, the handover failed whatever the code quality.

These measures are taken after go-live, not at delivery. Which is why the baseline belongs in the observation phase. Without a starting point, nobody can honestly say what the project changed.

Success conditions, and when it is the wrong model

Three conditions come back systematically in engagements that land. Real access to users, not only to their manager. An identified internal counterpart who knows the business in detail, has time, and will take the tool over. And a sponsor who accepts that scope moves when observation reveals the initial problem was not the right one.

Three mistakes come back just as often. Treating observation as wasted time and jumping straight to building, which recreates the problem the model exists to avoid. Keeping the engineer remote to save travel. Planning no handover, which turns the project into permanent dependence.

One signal deserves particular attention. If, after several weeks, the provider still asks for formal approval before every step without ever showing code running on your real data, it is not doing forward deployed work. The simplest test is to ask, at short intervals, to see what actually runs at your place.

When to choose something else

The model is a bad fit in several situations, and saying so avoids disappointment. When the need is an off-the-shelf product to configure, a specialist integrator will be better and cheaper. When the constraint is regulatory and already formalised, there is little to discover in the field. When users are not accessible, for workload or internal political reasons, the model loses its raw material. When the organisation is going through a reorganisation that will change processes within months, it is better to wait for the work to settle. And when leadership wants a firm price on a firm scope, a fixed-price contract is more honest than promising an adaptive model on a contract that is not.

If you are weighing these options, an AI diagnostic settles it before any commitment: we look at the process concerned, check whether the model's conditions are met, and tell you if another approach fits better. The other articles in this series, on the method, the tooling, the buying models and generative AI, complete this page for anyone who wants the detail.

Sources

• What are Forward Deployed Engineers, and why are they so in demand?, The Pragmatic Engineer
• How Palantir Invented the Forward Deployed Engineer Model, FDE Academy
• Forward Deployed Software Engineer, Palantir Technologies job posting

Frequently asked questions

Does the engineer work at our offices every day?

No, and it would not be desirable. On-site presence is concentrated where it adds something: observing real work, demonstrations, going live. The rest happens remotely with no loss, once the business is understood.

Do we need to buy tools before starting?

Usually not. The principle is to start from what you already have, because every added tool becomes a burden on your teams afterwards. If a purchase does prove necessary, it comes after observation, when the need has been verified, not at framing time.

Our data is a mess. Should we clean it up first?

No. Messy data is the normal situation rather than an exception, and waiting for it to be clean amounts to never starting. Cleaning is part of the work and happens through real cases, not in a preliminary project that produces nothing usable.

Our users have no time to spend on a project.

Observation happens during their work, not in workshops or meetings. What is asked is that they accept someone sitting beside them and answer questions as they come. The real load falls on the internal counterpart, who should be chosen accordingly.

Can we stop partway through?

Yes, and the short-loop structure exists for that. At each cycle, whatever went into production stays in production and keeps being useful. There is no point of no return where everything only counts if the project runs to the end.