Forward deployed engineering explained for executives

This page is for whoever signs off the spend. It assumes you do not need the history of the role and do want to know what you are buying, what it costs, and what to hold the vendor to.

What you are buying

Engineers who work inside an environment rather than beside it. They use the real data, the real authentication, the real approval process, and they are accountable for the system running in production rather than for a document describing how it should.

The alternative models are cheaper. A consultant will deliver a scope. An integrator will connect products that exist. Staff augmentation will add hands to a plan you own. Each is the right purchase under conditions that are easy to state, and when forward deployed engineering is the wrong answer states them.

Why the model exists at all

Because AI systems cannot be specified in advance the way earlier software could.

With a conventional integration, you could write down what the system should do, price it, and hold a vendor to it. With an AI system, nobody knows the acceptable error rate, the edge cases, or the escalation path until it runs on real data with real users. The specification is something the work produces.

That is the mechanism behind the number everyone quotes. MIT's Project NANDA reported in July 2025 that 95 percent of generative AI pilots delivered no measurable profit-and-loss impact. Worth knowing the sample before you repeat it in a board meeting: 52 executive interviews, 153 leader surveys, and analysis of 300 public deployments. It is a strong signal rather than a census.

The failures it describes are not model failures. They are 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 can be fixed from outside the building.

The three questions that decide it

Does the contract value carry an engineer? Work out what one engineer costs you loaded for a quarter, then compare it against what the deployment is worth. First Round Review reports that Looker validated $25,000 or more in annual contract value before committing to the model. Do not adopt that number, do the same arithmetic, and write the floor down before the first engagement.

Do the environments differ from each other? Look at your last five implementations and count what was genuinely different in each. If the answer is a connection string and a logo, you have a documentation problem and an embedded engineer is an expensive way to solve it.

Will anybody act on what the engineers find? This is the one executives underweight. The value of putting an engineer inside an environment is what they learn there, and that learning only pays if it can change what gets built. First Round Review is blunt: if you hold strong opinions about product direction and do not want them moved, embedded engineers are a bad fit. You will have paid for discovery you intend to ignore.

Two noes and the answer is no.

What it costs

Two figures are checkable, and almost everything else circulating is not.

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.

Load either for benefits, travel and the time an engineer is not on another account, and you have the input. What forward deployed engineering costs works it through, and names what is not knowable.

The other cost is margin. An engineer assigned to one customer is an engineer not building the product, and it shows up on gross margin where every investor sees it. a16z's argument for accepting that is Trading Margin for Moat: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, both later climbing to 79 and 75 percent by 2024. The services-heavy start was the on-ramp.

The two dates to insist on

This is the shortest useful thing on the page.

A production date. Not a design delivery date, not a pilot date. The date the system is running for real users.

A handover date. The date the vendor leaves and your people run it, plus what the handover artefact actually is.

When AWS announced its own forward deployed engineering organization in June 2026, it named customer self-sufficiency at the end of the engagement as a design goal, and said the work would be priced on business results rather than billable hours. Hold every vendor to both, including us.

An engagement without those two dates is not a deployment. It is a recurring cost with an optimistic name.

What to ask in the vendor meeting

Four questions, and the answers are more informative than the deck.

What share of the week will these engineers spend writing code in our repository? Who is accountable by name if this does not reach production? Are they compensated on our system going live or on this contract being signed? And what is the handover date?

A vendor selling genuine forward deployed engineering answers all four without reframing any of them. Questions to ask a vendor has the longer list, and the three jobs hiding behind the title explains why the first question matters: across 1,000 postings, 30 percent using this title were presales roles.

The decision in one paragraph

If the work can be written down, buy delivery. If it cannot, and the outcome is worth an engineer's full attention, and somebody on your side will act on what the engineers learn, buy forward deployed engineering with two dates in the contract. If you are unsure, the cheapest next step is not a pilot engagement. It is counting what was actually different about your last five implementations.

Then: three routes to the capability.