Guide

Forward deployed engineering: the complete guide

A forward deployed engineer is a software engineer who works inside the customer's environment, on the customer's real data, and stays responsible until the system runs in production. The role exists because software that works in a demo and software that keeps working inside a real company are two different pieces of work, and somebody has to do the second one.

Published September 8, 2026. Editorial.

Key takeaways

A forward deployed engineer (FDE) embeds with a customer, writes production code against that customer's real systems, and owns the deployment through to it running. The defining feature is ownership of the outcome, not the job title or the travel.
Palantir created the role because its first customers could not describe what they needed until they saw a working version in their own environment. Every later version of the model inherits that assumption.
The role is spreading because enterprise AI has a problem at the final step before production. MIT NANDA's July 2025 study of 300 public deployments found 95 percent of generative AI pilots produced no measurable profit-and-loss impact, and the gap it describes is an integration gap.
A solutions architect designs it, a sales engineer sells it, and a forward deployed engineer releases it into production and stays with it. If nobody on your side merges code, you do not have an FDE.
Forward deployed engineering gives up gross margin to win a position that competitors find hard to copy. That is the whole argument, and it is only worth the cost when contract values are large and customer environments differ from each other.

A forward deployed engineer is a software engineer who is placed inside a customer's organization to build and release software there, against that customer's real data and real constraints, and who stays accountable until the system is running in production.

That is the definition. The rest of this guide is about why the role exists, why it is suddenly common, how it differs from the four or five adjacent jobs people confuse it with, how to hire for it or buy it, and what it pays. We wrote it because the role is being described in a lot of places by people who are selling something and citing nothing, and a buyer or a candidate trying to understand it deserves better than numbers copied from other articles with no source.

Where the name comes from

The term is borrowed from the military, where a forward deployed unit is stationed in the field rather than at home base. Palantir Technologies popularised it in software, and the reason it invented the role is the most useful thing to understand about it.

Palantir's early customers had problems nobody could specify in advance. The customer could not write a requirements document, because the customer did not know what the software should do until they saw something working against their own data. A traditional delivery model fails in that situation. You cannot run discovery, write a spec, go away for six months, and come back, when the discovery itself is only possible inside the environment.

So the engineer moved to where the problem was. Not an analyst who reports back, and not a consultant who writes a recommendation. An engineer who commits code, attends the customer's daily team meetings, and finds out what is true by building against the actual systems.

Wikipedia's entry on the forward deployed engineer records the same origin and notes that the responsibilities overlap with solutions architects, sales engineers, customer engineers, professional services engineers, systems integrators and IT consultants [1]. That overlap is real, and it is why half of this guide is comparison pages. The tasks overlap, but the accountability differs, and that difference decides everything else.

What actually distinguishes the role

Three things separate a forward deployed engineer from the roles that look like it.

They write production code. Not diagrams, not runbooks, not a proof of concept that someone else turns into a production system. Code that goes into a repository and runs.

They work in the customer's environment. The customer's data, the customer's authentication, the customer's approval process, the customer's staging environment that does not match production. Working from the outside means working from a description of the environment, and the description is always wrong in the places that matter most.

They are responsible for the outcome. The deployment either runs or it does not, and the FDE does not get to hand the failure to an implementation team. This is the part that cannot be faked, and it is the fastest way to tell a real FDE function from a professional services team with a new name.

Our page on what a forward deployed engineer is goes through the definition properly, and what a forward deployed engineer does describes a normal week.

Why the role is spreading now

The role existed for twenty years with little attention. Then, over about eighteen months, it became one of the most-discussed jobs in the industry. Three things happened at once.

The first is a gap between AI demos and AI in production. MIT NANDA's July 2025 study, "The GenAI Divide: State of AI in Business 2025", drew on 52 executive interviews, 153 leader surveys and 300 public deployments, and reported that 95 percent of generative AI pilots delivered no measurable profit-and-loss impact [2]. That number gets quoted everywhere, usually without the sample size, and it deserves the caveat. What it describes, though, matches what anyone selling AI into a large company sees: the model works, the pilot impresses people, and then it stops before it becomes part of the daily work.

The second is that investors started arguing for it in public. In June 2025, a16z partner Joe Schmidt published "Trading Margin for Moat", which argued that AI companies should hire teams focused on implementation instead of trying to grow through the product alone, and called the forward deployed engineer the most in-demand job in startups [3]. His evidence is the previous generation: ServiceNow's gross margin at IPO was 63.2 percent and Workday's was 54.1 percent, well below the 80 percent that software investors treat as normal, and both later rose, to 79 percent and 75 percent in 2024. The services work was the first step into each customer. The software was the business model.

The third is that the largest cloud provider made it a product. In June 2026, AWS announced a Forward Deployed Engineering organization backed by a $1 billion investment, embedding thousands of engineers with customers to build production AI systems, and said the work would be structured around shared goals and business results rather than billable hours [4]. A $1 billion commitment is a long-term commitment in enterprise software. When the largest existing cloud provider starts selling embedded engineers, the model is no longer an unusual Palantir practice.

Why forward deployed engineering is growing covers all three in detail, and the verified numbers collects every figure we could trace to a source, with its sample size. If you need the version to show somebody who approves budget, the executive briefing is one page.

The four roles people confuse it with

This is where most of the confusion is, and the distinctions are worth being exact about.

A sales engineer works before the contract. They demo, they answer technical objections, they build the proof of concept that gets the deal signed, and their compensation usually rises and falls with signed sales. When the contract is signed, they leave.

A solutions architect designs the implementation. They produce the architecture, the integration plan, the reference pattern that makes the deployment repeatable. Someone else builds it.

A consultant or professional services engineer delivers an agreed scope. The scope is the contract, the statement of work defines done, and the engagement ends when the scope is delivered, whether or not the thing produces value.

A forward deployed engineer does the part after all of those. They own the build and the production rollout, they change the plan when the environment shows the plan was wrong, and they finish when the system runs.

Six comparison pages in this guide take each one properly: FDE vs solutions architect, FDE vs sales engineer, FDE vs solutions engineer, FDE vs consultant, FDE vs systems integrator, and FDE vs staff augmentation, which is the choice most buyers actually face.

The economics, stated plainly

Forward deployed engineering is expensive. An engineer assigned to one customer is an engineer not building the product, and the cost reduces gross margin, which every investor can see. Anyone who tells you the model is free is selling it.

What you buy with that margin is threefold. You get deployments that reach production instead of stopping partway. You get a view of the customer's real workflow that no discovery call produces. And you get to see which customer-specific work repeats across accounts, which is how services work turns back into product.

That last part is the most important. First Round Review's February 2026 piece on hiring FDEs makes the point that the discipline is knowing when to stop: expand scope when the work creates something reusable, and stop when the iteration only ever serves one customer [5]. It also gives a rough allocation for how the time should split, around 20 percent facing the customer and 80 percent building, which is a useful quick check on whether you have hired engineers or account managers.

How to price forward deployed engineering works through the models, and measuring forward deployed engineering covers what to track so the function does not become a cost centre without anyone noticing.

When it is the wrong answer

We are a consultancy that works this way, so treat the following as the part we have the least incentive to write.

Forward deployed engineering is the wrong model when your customers are small, when your product does the same thing for everyone, when your contract values cannot carry an engineer's time, or when you already know exactly what the product should be and are not willing to change it based on what one customer needs. First Round's diagnostic is blunt about the last one: if you hold strong opinions about product direction and do not want them changed, FDEs are a bad fit [5].

There is also a failure mode worth naming. An FDE engagement that never ends has stopped being a deployment and become a dependency. The customer's team never learns the system, the vendor's margin never recovers, and both sides call it a partnership. AWS's own framing puts self-sufficiency at the end of the engagement as a design goal [4], and that is the right test: at some agreed point, the customer's engineers run this without you.

When forward deployed engineering is the wrong answer is the page for that conversation.

What it costs

Whether you build the function or buy it, the number that matters is what one embedded engineer costs you for a quarter, against what the deployment is worth.

Two figures are checkable. Levels.fyi, read on 8 September 2026, puts self-reported Palantir forward deployed engineer compensation in the United States at a median total package of $278,000, with a range from $185,000 to $631,000 [7]. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816 [8]. Add benefits, travel and the time the engineer is not on another account to either one, and you have the real input.

Almost everything else published about this is unsourced. The confident salary ranges for leading AI labs in the search results come from blog posts citing each other, and Levels.fyi does not yet have enough submissions to show a level breakdown for OpenAI's forward deployed engineer title. What forward deployed engineering costs works the model through from the buyer's side and names what is not knowable.

Travel is the other real cost, and the engineers doing the work pay it in time away from home. OpenAI's own postings for forward deployed software engineers state that up to 50 percent travel is required [6], and 68 percent of the 1,000 postings analysed required travel at all, with 50 to 75 percent typical where a figure was given [8].

Three routes to the capability

You can build the function, staff individual engineers through a partner, or engage a firm that takes the outcome. Forward deployed engineering as a service compares the three on cost, speed and where the delivery risk sits.

If you are building it yourself, start with how to build the team, then the job description and how to hire. One decision matters more than the rest, and it is where the function reports.

If you are buying it, how to choose a partner and the questions to ask a vendor are the two pages to read before you speak to a vendor, and what to put in the contract is the one to read before you sign.

What the first two weeks actually look like

The gap between a discovery call and a real engagement shows up fastest in the first two weeks, because that is when the assumptions made during sales meet the customer's actual systems.

Access is usually the first surprise. An engineer who was promised a working login on day one often spends the first several days waiting on a security review, a data-sharing agreement, or a laptop that meets the customer's device policy. None of that is wasted time if it is planned for, and all of it derails a schedule that assumed coding would start immediately. The second surprise is that the requirements gathered during the sales process describe what the customer's team believes the system does, and the environment usually contradicts some part of that belief within the first week of real access.

The engagements that go well treat this as expected rather than as a setback. They plan the first two weeks around finding out what is true, not around shipping a feature, and they set that expectation with the customer before the engagement starts so a quiet first stretch does not read as a stalled one. The first two weeks of a forward deployed engagement covers what a well-run start looks like in practice, and discovery inside the customer environment covers the specific technique: building small, disposable things against the real system rather than interviewing people about it, because the environment answers questions a person's memory of the environment gets wrong.

Why customer-specific work has to feed back into the product

An engagement that only ever produces something for one customer is a services business wearing a software company's pricing. The economics only work if some share of what gets built for customer one also helps with customer two, and that does not happen automatically.

The mechanism that makes it happen is deliberate. When an engineer notices they have solved the same integration problem, written the same data transformation, or built the same kind of dashboard for a second customer, that pattern gets pulled out of the customer-specific codebase and turned into something the product team can offer directly. The next customer who needs it gets a supported feature instead of another custom build, and the forward deployed team's time goes back to solving problems that have not been solved yet.

This does not happen by accident, and a team that never asks the question stays a services team indefinitely, no matter what the org chart calls it. The productization loop covers how a company reviews its custom work on a schedule and decides what graduates into the product, and the forward deployed to product engineer ratio covers a related warning sign: a ratio that keeps growing toward embedded engineers, with no counterweight on the product side, is a company that has stopped building leverage and started scaling headcount that only ever serves the account it sits on.

The dependency trap, named plainly

The most common way a forward deployed engagement goes wrong is an engagement that succeeds at everything except ending.

The pattern is easy to fall into because it feels like success from inside the relationship. The customer is happy, the engineer is productive, the invoices get paid, and neither side notices that the customer's own team has stopped learning the system, because the embedded engineer is faster at every change than anyone would be picking it up cold. Years later, the customer cannot run their own system without the vendor, and the vendor's margin never improves, because the entire point of embedded engineering, that it eventually produces a product a customer's own team can run, never happened.

This has a name in the industry: the Palantirization problem, after the company that popularized the model and the criticism that its own margins never followed the software business's usual pattern despite decades of embedded delivery. The Palantirization problem covers what causes it and the specific commercial terms that prevent it, and handover and exit from a forward deployed engagement covers what a real exit requires: not a slide deck, but a customer engineer who can make a real change to the system while the original team watches and says nothing.

What actually goes wrong, and how often

Every model of delivery has a failure mode, and pretending otherwise is how buyers end up surprised.

The failure that shows up most is scope that never stops moving. Because the engineer is embedded and responsive, it becomes easy for the customer to ask for one more thing every week, and an engagement with no stated boundary on scope has no way to say no that does not damage the relationship. A close second is an engineer placed without the authority to make decisions, so every choice routes back through a home-office team that is not in the room and the speed advantage of being embedded disappears into approval delays. What goes wrong in forward deployed engagements works through these and the rest of the list, with what a contract and a working agreement can do about each one before it happens rather than after.

Whether the role survives what it made possible

A fair question, given how much of this guide is about AI: does a coding agent replace the need for a person embedded in the customer's environment.

The honest answer is that AI changes what the engineer spends time on without removing the reason the role exists. A model can write the integration code once the requirement is clear. It cannot sit in the customer's meeting, notice that the stated requirement contradicts what three other people in the room just said, or decide which of two conflicting priorities the customer actually cares about more. Those are the parts of the job that were never about typing, and they are also the parts that made the role valuable in the first place. What changes is that the typing gets faster, which means more of the engagement's time goes toward the judgment calls that were always the scarce resource. Is the forward deployed engineer role being automated? covers this in more detail, including where the automation argument is strongest and where it breaks down.

Getting the customer's own team ready

The customer's own team has real work to do before an engineer arrives, and skipping it is one of the more common reasons an engagement starts slower than either side expected.

That preparation is mostly about access and ownership: who on the customer's side owns the relationship, what data the engineer is allowed to see and under what agreement, which systems need a security review before anyone outside the company touches them, and who is available in the first weeks to answer the questions that discovery inside the environment will surface immediately. A customer that has answered these before the engagement starts gets a faster, calmer first month than one that answers them for the first time when the engineer asks. How to prepare your team for an embedded engineer is written for the customer's side of that conversation.

Where this connects to the rest of our work

Forward deployed engineering and the way we build are the same argument, made from two starting points. An engineer inside your environment finds out what is actually true. A specification written from what they find, and an eval suite derived from that specification, is what keeps the code correct once a model is writing most of it. One without the other gives you either fast code nobody trusts or trustworthy code that solves the wrong problem.

If that is the part you care about, eval-driven development covers the verification method, AI-native delivery covers how the work is organised, and building AI products covers the product side. If you are choosing who to work with, choosing a software development partner is the buyer's guide.

And if you want this done rather than read about, that is what we do: tell us what you are building.

Explore the guide

Start here

What is a forward deployed engineer?

A forward deployed engineer is a software engineer placed inside a customer's organization to build and release production software there, against that customer's real data and real systems, and who stays accountable for the deployment until it is running. The title is often written FDE, and the variant FDSE means forward deployed software engineer. Palantir popularised the role and AWS, OpenAI, Anthropic and Google now use the title. Three tests separate it from the roles that resemble it: production code, the customer's environment, and ownership of the outcome.

What does a forward deployed engineer do?

A forward deployed engineer spends most of the week writing production code inside the customer's systems, and the rest of it finding out what the code should do by sitting with the people who will use it. A useful guideline from teams that run the model well is about 20 percent of the time facing the customer and 80 percent building. When that ratio inverts, the engineer has become an account manager and the deployment has stopped moving. Across 1,000 job postings, the three duties named most often were working directly with customers, building and deploying AI systems, and integrating systems and APIs.

The three jobs hiding behind the FDE title

Forward deployed engineer is one title covering at least three different jobs. An analysis of 1,000 postings carrying the title, published by Henley Wing Chiu in November 2025 using Revealera data, split them into a production engineer embedded with customers (60 percent), a sales engineer with implementation duties (30 percent), and an internal tools builder who faces no customer at all (10 percent). The three differ in how much of the week is spent writing code, how pay is structured, and who is accountable for production. Anyone hiring for the title, taking the job, or buying the service needs to know which one is being offered.

Forward deployed engineering explained for executives

Forward deployed engineering means putting engineers inside your organization, or your customer's, to build and run a system rather than to advise on one. It costs more per engineer than any other delivery model and it is the only one that reliably gets an AI pilot to a production system. Three questions decide whether you should buy it: is the contract value large enough to pay for an engineer, do the environments differ from each other, and will anyone change the plan based on what the engineers find. Two noes means buy something else.

Why forward deployed engineering is growing

Forward deployed engineering grew because enterprise AI has an integration problem that nobody can solve from outside the customer's building. Three things happened close together: MIT NANDA reported in July 2025 that 95 percent of generative AI pilots produced no measurable profit-and-loss impact, a16z argued publicly in June 2025 that AI companies should hire teams focused on implementation, and in June 2026 AWS committed $1 billion to a forward deployed engineering organization. Job postings carrying the title grew 1,165 percent year over year. Each of those numbers deserves its caveat, and this page gives them.

Forward deployed engineering: the verified numbers

This page collects every statistic about forward deployed engineering that we could trace to a primary source, with the sample size, the date, and a link to the original. It also names the numbers that are repeated widely and have no traceable source, because on this topic those outnumber the real ones. Job postings grew 1,165 percent year over year. The title covers three different jobs at a 60/30/10 split. Median advertised salary was $173,816. AWS committed $1 billion. Each of those has a source below, and each has a caveat worth reading before you quote it.

Where the model came from

The Palantir forward deployed engineer model

Palantir popularised the forward deployed engineer, and it did so for one reason: its early customers could not describe what they needed until they saw software working against their own data. That made discovery impossible from outside the environment, so the engineer moved inside it. Every later version of the model, at AWS, OpenAI, Anthropic and hundreds of startups, inherits that assumption whether or not the company adopting it has the same problem. Understanding the original condition is how you tell whether the model will work for you or just cost you margin.

How AWS, OpenAI and Anthropic run forward deployed engineering

Four companies run public forward deployed engineering programmes: Palantir, which created the model, and AWS, OpenAI and Anthropic, which adopted it. Everything below comes from what each company published about itself, and is labelled as such, because a company describing its own delivery model is making a claim rather than reporting a fact. AWS is the one worth studying closely: it made two commitments in writing that the others did not, pricing on business results rather than billable hours, and customer self-sufficiency once the engagement ends.

The Palantirization problem

In January 2026 a16z partner Marc Andrusko published an argument against the model his own firm had popularised: most companies copying Palantir end up with an expensive services business presented as software. He names four conditions Palantir met that most startups do not, describes the services problem as thousands of bespoke deployments nobody can maintain, and offers five questions that test whether a company has a platform or a business that only profits from the difference in labour costs. This is the most useful critique of forward deployed engineering published, and it is worth reading before you adopt the model or buy from someone who has.

Is the forward deployed engineer role being automated?

Palantir now sells a product called AI FDE: an agent that operates Foundry through conversational commands, builds pipelines, edits ontologies, writes and tests functions, and builds applications in a closed loop. A company naming a product after its own best-known role is making a statement about which part of that role was routine. The platform operation is being automated. Deciding which problem is worth solving inside an organization that cannot describe it, and being answerable when the answer is wrong, are not. That split is the whole answer, and it is the same split that applies to any AI-native team.

How an engagement runs

How a forward deployed engagement runs

A forward deployed engagement runs in five phases: discovery inside the environment, a prototype against real data, deployment to production, productizing what turned out to be reusable, and scaling back so the customer's own team runs it. The first three are what everyone plans. The fourth is what turns one customer's work into a product. The fifth is the one that gets skipped, and skipping it is the difference between a deployment and a dependency. AWS describes a similar three-phase structure for its partner programme, ending with the partner working independently.

The first two weeks of a forward deployed engagement

The first two weeks decide the pace of everything after them. By day ten a working engagement has released something small against real data, written down what correct means, and mapped the path a change takes to production. The most common way to lose those two weeks is access: an engineer waiting on repository credentials is the most expensive unused resource in the company. Three things have to exist before day one, and all three are the customer's to provide.

Discovery inside the customer environment

A discovery call gives you what the customer can describe. Being inside the environment gives you what nobody thought to mention, and that second category is where deployments fail. Marty Cagan's argument for the embedded model is that it is a product discovery technique rather than a delivery technique: engineers who visit multiple customer sites see the similarities and differences across a market, which is the essence of customer discovery. The practical version is that the environment is the source of the information, and you cannot study it from outside.

What a forward deployed engineer ships in week one

A forward deployed engineer should ship (release into real use) something small and working against real data in the first week. Not a mockup and not a demo on a small, selected set of data: one transform, one screen reading live records, one integration returning a real response. The point is diagnostic rather than promotional. What breaks when you try to release something tiny tells you more about the engagement than any planning document, because it makes you work with the data, the permissions and the release path all at once.

Handover and exit from a forward deployed engagement

The ending of a forward deployed engagement has to be designed at the start, with a date in the contract at signature. An engagement whose conclusion is decided later does not have one: it keeps going, because there is always one more improvement and both sides find the arrangement comfortable. AWS named customer self-sufficiency after the engagement as a design goal of its own programme, and its partner model ends with the partner team working independently. The test of a handover is not whether documents were delivered. It is whether the customer's own engineer has changed the system, alone, before the vendor left.

What goes wrong in forward deployed engagements

Forward deployed engagements fail in a small number of recognisable ways, and most of them are visible by week three if you know the warning sign. The endless engagement. The demo that never becomes ready for production. The engineer who became an account manager. The bespoke fork nobody can upgrade. The pilot that was never going to production. And the handover that was a slide deck. Each has an early signal and a specific intervention, and none of them get fixed by the engineer working harder.

Compared with other roles

Forward deployed engineer vs solutions architect

A solutions architect designs how a system should be implemented and hands that design to someone else to build. A forward deployed engineer writes the implementation themselves, inside the customer's environment, and stays accountable until it runs in production. The single test that separates them is who merges the pull request. Both roles are senior, both are customer-facing, and both can hold the same technical opinions. Only one of them is answerable when the deployment does not work.

Forward deployed engineer vs sales engineer

A sales engineer works before the contract is signed and is measured on whether the deal is signed. A forward deployed engineer works after it is signed and is measured on whether the system reaches production. The test is the compensation plan: across 1,000 job postings carrying the forward deployed title, 70 percent mentioned equity, 8 percent mentioned commission or on-target earnings, and none were quota-carrying. Where a role does carry a sales target, the incentive ends at signature, and knowing that before you hire or buy is worth more than any duty list.

Forward deployed engineer vs solutions engineer

A solutions engineer is tied to a specific product: they configure it, extend it within the features it supports, and make it fit the customer. A forward deployed engineer is tied to the customer's problem and builds whatever is missing, including parts the product does not cover. The test is what happens when the product cannot do what the customer needs. A solutions engineer files a feature request. A forward deployed engineer writes the code. This is a closer comparison than sales engineering, and the two titles are used interchangeably by companies who mean different things.

Forward deployed engineer vs consultant

A consultant delivers an agreed scope: the statement of work defines done, and the engagement ends when the scope is delivered. A forward deployed engineer is accountable for an outcome, so when the plan turns out to be wrong they change the plan rather than raising a change request. The test is what happens on the day somebody discovers the original approach will not work. That day arrives in most engagements, and the two models respond to it in opposite ways.

Forward deployed engineer vs systems integrator

A systems integrator connects systems that already exist, using each product as the vendor intended, and its skill is knowing how the pieces fit. A forward deployed engineer writes the part that does not exist yet. The test is whether your problem is solved by connecting things that are already built. If it is, an integrator will do it faster and cheaper. If the answer requires code nobody has written, an integrator will scope it as custom development and subcontract it, which is the moment to ask who is actually accountable.

Forward deployed engineer vs staff augmentation

Staff augmentation adds senior engineers to your team, working under your direction, on the roadmap you already own. Forward deployed engineering hands an outcome to an outside team who decide how to reach it and are accountable for it running. The test is whether you have someone senior on your side making the technical decisions. If you do, buy extra engineers. If nobody is making those decisions, buying extra engineers means paying for people who wait to be told what to do. This is the fork most buyers are actually standing at, and the two are often sold under the same words.

Building the function

How to build a forward deployed engineering team

Before hiring anyone, confirm three prerequisites: your customers are enterprises, your product is still flexible enough to change based on what you learn, and their use cases differ from each other. First Round Review names all three, and missing two means do not start. Then begin with two or three engineers on your highest-value accounts only, report the function into product or engineering rather than sales, and give somebody the job of turning work done at customer sites into product from the first month. Those last two decisions determine whether the function becomes a lasting advantage over competitors or a cost centre.

Forward deployed engineer job description

Most forward deployed engineer job descriptions fail in the same two places: they do not say which of the three jobs the role actually is, and they hide the travel. Across 1,000 postings carrying the title, 60 percent were production engineering roles, 30 percent were sales engineering with implementation duties, and 10 percent faced no external customer. 68 percent required travel, with 50 to 75 percent typical where a number was given. State both in the first hundred words and you get fewer applicants, and better ones.

How to hire a forward deployed engineer

The candidates come mostly from software engineering: across 1,000 postings, 45 percent of career paths into the role started in software engineering, 22 percent from solutions or sales engineering, 15 percent from data, 10 percent from technical consulting and 8 percent from founding or early-employee roles. First Round Review names five qualities that predict success and one surprising warning sign: ten or more years at a large tech company, because the role needs somebody who operates without the support structure of a large company. Do not lower the engineering standard to get customer skills.

How to interview a forward deployed engineer

A forward deployed engineering interview process has to test three things in roughly equal weight: engineering depth, judgment in front of a customer, and the ability to reason out loud through ambiguity. That makes it different from a standard engineering interview process, where the third is barely assessed. The main round is an ambiguous case: a vague problem from a hypothetical customer, which the candidate has to decompose into a plan. The most common reason strong engineers fail it is jumping to a solution before scoping the problem.

Where forward deployed engineering should report

Forward deployed engineering should report into product or engineering, not sales, and not a separate professional services unit. Marty Cagan's warning is direct: if embedded engineers sit in a professional services group, what they learn stops reaching the product and the company moves toward a pure services business. The hiring data suggests most of the market has already made the wrong choice, with only 45 percent of 1,000 postings sitting on a dedicated forward deployed team rather than under sales. This is a nearly free decision at the start and expensive to reverse later.

The forward deployed to product engineer ratio

There is no credible published benchmark for the ratio of forward deployed engineers to product engineers, and we are not going to invent one. What exists is a calculation you can do with your own numbers, and one documented minimum: First Round Review reports Looker validating $25,000 or more in annual contract value before committing to the model. Size the function from account count, deployment length and the contract value that has to pay for it, then check the result against whether your revenue per embedded engineer is rising.

The productization loop

The productization loop is the mechanism that turns one customer's custom work into a capability every customer gets. It needs three things: a fixed schedule, a named owner, and a stop rule. First Round Review's version of the stop rule is the useful one: expand scope when the work creates repeatable software value, and halt when the iteration only serves a single customer. Without this loop, embedded engineering produces what a16z describes as bespoke deployments impossible to maintain or upgrade, where revenue grows but no reusable work builds up.

Commercials

How to price forward deployed engineering

There are four ways to price embedded engineering: time and materials, fixed scope, outcome, and bundled into a licence. Each produces different behaviour, and the behaviour matters more than the rate. Billable hours pay the vendor to be slow and to keep the engagement going. Fixed scope pays them to argue about scope. Outcome pricing aligns both sides and is hard to write. When AWS announced its own forward deployed engineering organization it said the work would be structured around shared goals and business results rather than billable hours, which is a standard to ask of every vendor.

Outcome-based pricing for embedded engineering

An outcome you cannot measure on the day of signature is a hope with a payment schedule attached. A workable outcome passes three tests: it is observable rather than inferred, somebody named takes the measurement, and neither party can change the definition of success alone. The most reliable outcome for an embedded engagement is the least exciting one, which is a defined system running in production for real users by a named date. Business-metric outcomes sound better and fail more often, because neither side fully controls them.

What forward deployed engineering costs

Two compensation figures for this role are traceable to a source. Levels.fyi reports Palantir forward deployed engineer total compensation in the United States with a median of $278,000 and a range from $185,000 to $631,000, read on 8 September 2026. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816. Everything else published is unsourced. Add benefits, travel and unbilled time to one of those two to get your input cost, then compare it against the cost of the deployment not happening.

Measuring forward deployed engineering

Measure four things: time from contract signature to production, the share of engagements that reach production, revenue per embedded engineer over time, and what came back into the product. Do not measure utilisation. Utilisation rewards keeping engineers on accounts, which is exactly the endless engagement, the main way this model fails. The metric that matters most to a customer is time to production, and the metric that tells you whether you have a business is revenue per engineer rising rather than staying flat.

Revenue per forward deployed engineer

Revenue per embedded engineer, tracked over time, is the single number that tells you which business you are in. It has to rise. When the platform takes in what engineers learned at customer sites, each engineer handles more accounts and the number rises. If it stays flat while custom work accumulates, you are running a services business that has not admitted it yet. The benchmark for what a rising curve looks like is the previous generation: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, reaching 79 and 75 percent by 2024.

The contract for an embedded engagement

Before an outside engineer touches your repository, six things belong in writing: IP assignment on creation, scoped repository access rather than organization-wide, production access as a named exception with an audit trail, a production date, a handover date with a defined artefact, and subcontractor binding. The one people get wrong most often is the first: an NDA covers secrecy and does not assign ownership of what the vendor creates. Those are two separate clauses and you need both.

Buying the capability

Forward deployed engineering as a service

There are three ways to get this capability: build the function in-house, staff individual engineers through a partner, or engage a firm that takes the outcome. Building gives you the most control and takes a hiring cycle plus two or three engagements of learning. Staffing is the fastest way to get a person working and leaves the delivery risk with you. Engaging a firm moves the delivery risk to the firm, which only helps if the contract names the production outcome rather than an hour count. Most companies should build eventually and cannot start there.

How to choose a forward deployed engineering partner

Judge a forward deployed engineering partner on five things, in this order: which of the three jobs their engineers actually do, whether they will put a production date and a handover date in writing, what proves the code correct, how they decline work that only serves one customer, and who is accountable by name. A vendor who will not name a handover date is selling a dependency. A vendor with no answer on declining customisation will say yes to everything, and everything they say yes to becomes something you maintain.

Questions to ask a forward deployed engineering vendor

Twelve questions, each with the answer you want and the answer that should worry you. Five of them come from a16z partner Marc Andrusko, who wrote them as tests for investors evaluating companies using this model; they work at least as well from the buyer's side. The most revealing question on the list is how the vendor systematically declines customisation requests, because a vendor with no answer will say yes to everything and you will maintain all of it.

How to prepare your team for an embedded engineer

Three things have to exist before an embedded engineer starts, and all three are yours to provide: access set up and tested, one named person who can remove obstacles, and one person with the authority to decline scope. The third is the one everybody forgets, and its absence is why engagements grow without control. Beyond that, the difference between a fast engagement and a slow one is mostly about how much context you share and how completely you include the person. Nobody writes this page, and it decides more outcomes than the vendor's methodology does.

Security and access for embedded engineers

Letting an outside engineer into your systems is a real risk and it is manageable with four rules: least privilege by default, repository access scoped to the repositories the work touches, production access as a named exception with an audit trail and an end date, and revocation on the handover date rather than whenever somebody remembers. What changes when a model writes the code is that the review step before production matters more, not less, because generated code is not secure by default.

When forward deployed engineering is the wrong answer

Forward deployed engineering is expensive and it is often the wrong choice. It does not fit when your contract values cannot pay for an engineer's time, when every customer wants the same thing, when you hold a fixed product opinion you will not change, or when the scope is something you can already write down. Each of those has a cheaper alternative that works better. There is also one failure mode that disqualifies the model after you have already started: the engagement with no end date, which has stopped being a deployment and become a dependency.

Where the model is used

Forward deployed engineering for enterprise AI

Enterprise AI pilots fail for three reasons: data nobody audited, a success metric nobody defined before the work started, and users who were handed a workflow they had no part in designing. None of those three can be fixed from outside the building, which is the entire argument for embedded engineering in this context. MIT NANDA reported in July 2025 that 95 percent of generative AI pilots produced no measurable profit-and-loss impact, from a sample of 52 executive interviews, 153 leader surveys and 300 public deployments. The failures it describes are organisational rather than technical.

Forward deployed engineering for AI agents

AI agents appear in 35 percent of forward deployed engineer job postings, ahead of general LLM experience at 31 percent and retrieval at 12 percent. The reason agents need this role rather than a normal integration is that an agent needs permissions, tool access and an escalation path, and all three are properties of the customer's organization rather than of your product. AWS named its own methodology Agentic Process Transformation, directing customers to start with a business process, redesign it for AI agents, deploy to production, and demonstrate measurable results.

Forward deployed engineering in financial services

Financial services is the largest customer segment for this role: 24 percent of the job postings that named a target industry. The constraint that decides how every engagement runs is the audit trail. In most software an audit log is a feature you can add later; here it is a property the system has to have from the first data model decision, because the question a regulator asks is not whether the answer was right but whether you can show how it was reached. That requirement changes what an embedded engineer builds in week one.

Forward deployed engineering in government and defense

Government and defense is where the model was invented and it remains 18 percent of the job postings that name a target industry. Three constraints decide how every engagement runs and none of them are technical: personnel clearance, which decides who can even take part; environments that are disconnected from the internet, which removes the tooling most teams assume; and procurement cycles long enough that the technology changes before the contract concludes. The engineering response to all three is the same, which is to design for the constraint rather than around it.

Forward deployed engineering in healthcare

Healthcare accounts for 17 percent of the forward deployed engineer postings that named a target industry. Two constraints decide every engagement. The data usually cannot leave the organization, which means the work happens inside their infrastructure on their terms. And the clinical workflow cannot stop, which means every deployment is a change to a process that is running continuously with real consequences. Together those rule out the two things software teams normally rely on: taking the data home, and a maintenance window.

Common questions

What is a forward deployed engineer?

A forward deployed engineer is a software engineer who is embedded inside a customer's organization to build and release production software there, working against that customer's real data and systems, and who stays accountable for the deployment until it is running. The role was popularised by Palantir and is now used by AWS, OpenAI, Anthropic and a large number of AI companies.

What does FDE stand for?

FDE stands for forward deployed engineer. The variant FDSE stands for forward deployed software engineer, which is the title Palantir and OpenAI use for the same kind of role. The name is borrowed from the military, where a forward deployed unit is stationed in the field rather than at home base.

What is the difference between a forward deployed engineer and a solutions architect?

A solutions architect designs the implementation and produces architecture artifacts, and another team builds it. A forward deployed engineer writes and releases the production code themselves and owns the deployment until it runs. The clearest test is whether the person merges code into a repository that goes to production. If not, the role is architecture, not forward deployed engineering.

Why is the forward deployed engineer role suddenly popular?

Enterprise AI has an integration problem. MIT NANDA's July 2025 study reported that 95 percent of generative AI pilots produced no measurable profit-and-loss impact, and the gap sits between a working model and a working workflow. In June 2025 a16z argued publicly that AI companies should build teams focused on implementation, and in June 2026 AWS put $1 billion into a forward deployed engineering organization, which moved the model from a Palantir practice to an industry standard.

Do you need a forward deployed engineer, or a consultant?

Choose a consultant when the scope is known, can be written down, and does not need to change. Choose forward deployed engineering when nobody can specify the answer in advance, when the work has to run against your real systems to be judged at all, and when you want the same people who designed it to be responsible for it running.

How much does a forward deployed engineer earn?

Two figures are checkable. Levels.fyi, read on 8 September 2026, reports self-declared Palantir forward deployed engineer compensation in the United States with a median total package of $278,000 and a range from $185,000 to $631,000. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816. Public data for the leading AI labs is limited: Levels.fyi does not yet have enough submissions to show a level breakdown for OpenAI's forward deployed engineer title, so treat the specific ranges for leading AI labs shared in blog posts as unsourced.

Is forward deployed engineering just consulting with a new name?

No. A consulting engagement is defined by a statement of work and finishes when the agreed scope is delivered. A forward deployed engagement is defined by an outcome and finishes when the system runs in the customer's production environment. The difference shows up when the plan turns out to be wrong: a consultant raises a change request, and a forward deployed engineer changes the plan and stays responsible for the result.

How long does a forward deployed engagement last?

It varies with the scope and the environment, and the honest answer is that it should have a fixed end from the start. Set the production date, the definition of running, and the handover date in the contract. An engagement with no end date has become a dependency, which is the main failure mode of the model. AWS states self-sufficiency at the end of the engagement as an explicit design goal of its own forward deployed engineering organization.

Can a company hire forward deployed engineering as a service?

Yes. There are three routes: build the function in-house, staff individual engineers through a partner, or engage a firm that works this way and takes the outcome. Building is slowest and gives you the most control. Engaging a firm is fastest and moves the delivery risk to the firm, which only helps if the contract names the production outcome rather than an hour count.

What skills does a forward deployed engineer need?

Real engineering ability comes first: an FDE has to pass an ordinary software engineering standard, because the job is writing production code. On top of that, the role needs the ability to work without a specification, to scope a vague problem out loud in front of a customer, to operate in systems nobody documented, and to say no to work that only ever serves one account. First Round Review's guidance adds grit and business curiosity to the list.