Forward Deployed Engineers and the Last Handoff

In August 2026 I sat in a sparring call with a product manager. We were working through his solution and development process when he stopped and asked whether I knew the term Forward Deployed Engineer. He called it the new hot thing, the way everyone wants to work right now. Palantir has a base product, he explained, and sends its own engineers into the customer to adapt it there. One person carries the product decisions and writes the code. Anthropic has started doing the same.

My answer: That is how developers should always have worked.

He agreed immediately, and then told me something better. His own company’s main product was born exactly that way. Years ago a customer told the founder he could program it better himself. The founder said: then do it. He went to the customer, sat in the steel plant, and improved the software there, release after release. That is why the product still fits steel customers so precisely today.

Two minutes of conversation, and the whole argument was already on the table. A pattern presented as brand new. Recognized instantly by someone who had lived it. And a company whose best product exists because somebody once refused to work through a proxy.

The term deserves to be taken seriously. It also deserves to be taken apart, because the way the industry tells the story hides the part that actually works.

Is It New?

Palantir created the role and calls it Delta internally, a leftover from the days when each team in Business Development was named after a letter of the NATO alphabet. The company’s own description of the split is the sentence that carries the entire idea:

“You can think of a Dev’s focus as ‘one capability, many customers,’ while a Delta’s focus is ‘one customer, many capabilities.’”

That is not a job description. It is a slicing decision, and we will come back to it.

By the time Palantir went public, the role had become part of the investment case. The S-1 filing tells shareholders that “our forward deployed engineers (‘FDEs’) have travelled to bases in Afghanistan and factories in the industrial Midwest to deploy our platforms,” and adds the mechanism that matters: “Time in the field adds to the continuous improvement of our platforms.”

Ted Mabrey, who runs the commercial business at Palantir, traces the inspiration to something entirely outside software. Alex Karp observed how excellent French restaurants work. The waitstaff is part of the kitchen. If you order the wrong wine with the fish, they tell you no, because the point is that you get the best meal, not the meal you knew how to ask for.

So is it new? The practice is not. Engineers have been sitting at customer sites since software was sold at all, and every consultancy that ever seconded a developer knows the shape. My own answer in that call was the honest one.

What is new is three things. The role got a name, and a named role can be hired for, ranked, and celebrated: the venture capital firm a16z called it the hottest job in tech. A vendor then made it the primary way it goes to market rather than a support function bolted onto a sales motion, and until around 2016 Palantir employed more FDEs than ordinary software engineers. And the pattern has now jumped to the companies building the models.

Anthropic’s job advertisement for a Forward Deployed Engineer in Munich, posted the day before that call, asks one person to build production applications inside customer systems, deliver technical artifacts that run in production workflows, codify repeatable deployment patterns back into Product and Engineering, travel 25 to 50 percent of the time, and carry the customer relationship across the whole engagement. Palantir’s own advertisement puts it more bluntly: the responsibilities look similar to those of a startup CTO.

What is new is not the practice. It is that a software vendor made it the main way it goes to market.

XP Already Solved This, in the Other Direction

Twenty-five years ago the same problem had a different answer. Extreme Programming identified the distance between the person who knows the problem and the person who builds the solution as the thing to eliminate, and it eliminated the distance by moving the customer. Ron Jeffries describes the practice as it still stands:

“The team forms around a business representative called ’the Customer’, who sits with the team and works with them daily.”

In the second edition of Extreme Programming Explained, Kent Beck lists Whole Team among the primary practices and Real Customer Involvement among the corollary ones. The direction of travel is unmistakable. Bring the customer into the team room.

The Forward Deployed Engineer runs the same argument backwards. Send the team into the customer.

Same problem, opposite vector. The interesting question is why the vector flipped, and the answer is not fashion. It is a change in what can be moved.

In 1999 the immobile thing was the development environment. The build machine, the test suite, the pair stations, the wall of story cards: all of it lived in one room, and the cheapest thing to relocate was the one person who could speak for the business. Today the immobile thing is the customer’s context. The data cannot leave the building for legal reasons. The schemas are undocumented. The process knowledge is tacit and lives in the heads of people on a factory floor. Sometimes the network is air-gapped and nothing leaves at all. Meanwhile the engineer has become portable, because the platform beneath them, and now the model beneath that, travels with them.

At this point Scrum usually gets blamed, and the blame is misplaced. It is worth being precise, because the misreading is the actual subject of this section.

The Scrum Guide never says the Product Owner stands between the customer and the Team, and the word proxy does not appear in it. It assigns accountability, then rules out the broker reading in plain words: the Product Owner “may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.” The whole Scrum Team is “responsible for all product-related activities from stakeholder collaboration” onward, and the Scrum Master is asked to serve by “removing barriers between stakeholders and Scrum Teams.”

The name says it too. Owner, not Manager. The accountability is for deciding, not for gathering requirements on everyone else’s behalf.

The proxy was a field pattern, not a rule. Organizations wanted a single throat to clear and a familiar-looking job to promote people into, and a large secondary literature was happy to sell the requirements-broker version of the Product Owner back to them. That is the version most enterprises actually run.

LeSS wrote the correction down explicitly. Its principles state that the Product Owner “is a connector of customers/users and teams, rather than an intermediary,” and that “teams do the detailed refinement/analysis with customers/users (rather than the Product Owner).” That is the field pattern being unwound from the clarification path, in a scaling framework, years before anyone in software said forward deployment out loud.

So the wall the Forward Deployed Engineer knocks down was never in the rules. It was built on site, and it is now being removed from the other side and sold as an innovation.

There is a genuine difference, though, and it is worth naming precisely. XP and LeSS moved people around inside one organization, usually the customer’s own. The FDE crosses the company boundary, and the vendor pays for it.

Closing the distance to the customer is not the new part. Making the vendor carry the cost of closing it is.

Same problem, opposite vector: XP moves the customer in, the FDE moves the team out and feeds back what it learns

Why a Role and Not a Team?

Here is what bothers me about the way the pattern is being sold. Everything written about the FDE is written about a person. The most valuable credential in tech. The engineer who is product manager, developer and salesperson in one. Mabrey writes about the crucible that turns FDEs into hulks. The literature is a hero story, and hero stories are the most reliable way to copy the wrong thing.

There are three honest reasons the industry framed it that way.

A title is a recruiting instrument. You cannot advertise a feedback loop on a job board. You can advertise a role, rank it, and pay for it, and that is what a company scaling a go-to-market motion needs.

The customer boundary is person-shaped. Trust, status, and political navigation happen between individuals. Nabeel Qureshi, who spent nearly eight years as an FDE at Palantir, is unusually direct about this: succeeding at a customer required an unusual sensitivity to social context, and the vocabulary of the company was full of terms borrowed from improvisational theatre. A Team cannot sit in a stakeholder’s office. One person can.

The economics want a name. A vendor that internalizes systems integration cost wants that cost attributable per account.

All three are real. None of them makes the individual the unit that produces the result, and Palantir’s own material says so. The Delta is described as “part of a team that directly supports one customer.” Qureshi describes the mechanism that made the model pay: FDEs build fast and dirty at the customer, and the Product Development engineers then productize what the FDEs built. Foundry did not arrive as a product and get deployed. Its tools each began as manual drudgery that an FDE had to do by hand at a customer site until somebody automated it.

So the working system is not a person. It is a Team with a second Team behind it and a loop running between them. Calling it a role hides the loop, which is precisely why Mabrey watches the imitators fail:

“They are replicating the form but not the function of the FDE.”

One irony belongs in this section, because it is the same mistake running one level up. Palantir deliberately gave nearly everyone the same title, on the theory that titles become objects of desire and desire becomes internal politics. The market has now taken that anti-title and turned it into the status ladder it was designed to prevent.

A Team is accountable for the outcome its work produces. A title is not.

The Same Root Cause

Crediting an individual for a systemic outcome is a comfortable mistake, and it is not specific to Palantir. It happens whenever a structural shift shows up first in the shape of somebody’s job. None of this is a coincidence of the AI moment either. Andy and I traced the same force in The AI-Enhanced Team of the Future, and it produces both phenomena.

The force is this: the span of the value chain that a single social unit can hold has widened, because the layers beneath it matured. That is Evolution Focus observed rather than prescribed, the doctrine that where something sits on the path from genesis to commodity decides how you organize around it. When computing, deployment, and now generation move toward commodity, the unit standing on top of them can reach further with the same number of people.

Read the four eras of team evolution again with the handoff in mind. Component teams handed work to integrators. Full-stack teams absorbed that handoff. DevOps teams absorbed the handoff to operations. AI-Enhanced teams absorb generation and integration into the Team itself. Every era removed a handoff inside the company, and by Era IV there is essentially one left: the handoff at the company’s edge, where the vendor stops and the customer begins.

That is the handoff the Forward Deployed Engineer removes. It is the same movement, one boundary further out.

The difference between Palantir and the AI vendors is only where the platform came from. Palantir spent two decades building its own lower layer, FDE engagement by FDE engagement, until Foundry existed. The AI vendors were handed a lower layer by the model and can attempt the same reach in a single hiring round. Same climatic pattern, different substrate, and the second group has not yet proved it can do the hard half.

The Dev and Delta split also stops looking like an org chart once you read it as a slicing question. Slicing the Product distinguishes a vertical cut, which takes one customer’s value end to end, from a horizontal cut, which takes one capability across many customers. “One customer, many capabilities” is the vertical cut. “One capability, many customers” is the horizontal one. Palantir runs both simultaneously and does not pretend the tension away. Mabrey describes the relationship between FDEs and core product teams as conflict-riddled and defined by constant contradictions: FDEs are encouraged to build custom software, Devs are encouraged to abandon their roadmaps for high-value opportunities, and Devs are also encouraged to ignore FDEs.

Every era of team evolution removed a handoff inside the company. The Forward Deployed Engineer removes the one at its edge.

What Is Common, What Is Different

Forward Deployed EngineerAI-Enhanced Team
ScopeEnd to end, discovery through productionEnd to end, demand through market growth
ProxyRemoved, the engineer speaks with the customerRemoved, the Team defines intent and acceptance
MethodBuild, observe at the customer, correctAnticipate, Advance, Assess
Scarce assetDomain knowledge of one customerDomain knowledge and judgment
Unit of accountabilityThe individual, by how it is soldThe Team
What defines itPlacement inside another companyScope and tooling, location agnostic
Whose ambitionTwo, held in tensionOne Ambition, one Arena Product
Where the loop livesCompany-specific, dependent on key peopleIn the rules, Match and Tournament

The top half of that table is agreement, and it is substantial. Both patterns bet that end-to-end scope beats specialization, that a broker in the middle costs more than it saves, and that domain knowledge becomes more valuable as execution gets cheaper. The Jevons Paradox applies to both: lower the cost of building, and the scope grows rather than the headcount shrinking.

The bottom half is where we part company, and the last row is the one that matters most. Palantir’s loop works, and Mabrey names roughly eight people without whom he thinks it would not have. A loop that depends on who is in the building is not an operating model. It is a lucky configuration, and the tribute bands are the evidence.

So Is an AI-Enhanced Team Member a Forward Deployed Engineer?

Partly, and the part that differs is the interesting one.

Yes in scope and posture. An Era IV Team member owns a business outcome rather than a component, works empirically at the point where value is judged, and does not wait for a proxy to translate the customer for them. Change nothing about that person except the room they sit in, and the job advertisement would read the same.

No in the unit of accountability and in whose product gets built. An FDE serves two ambitions at once, the customer’s outcome and the vendor’s platform, and holds the tension personally. A Team in an Arena serves one Ambition and one Arena Product, and the tension is carried by the structure rather than by a person’s stamina.

Which gives the cleaner formulation. The Forward Deployed Engineer is what an AI-Enhanced Team looks like when the Ambition requires the Team to be present in the customer’s system, rather than the customer present in the Team’s. It is a deployment pattern, not a separate species of engineer.

That reading also tells you what to do with it, and what not to. Copy the title without the Team behind it and without the loop back into the product, and you have bought the most expensive thing in the model and none of the leverage. You have internalized systems integration cost and hired for it. This is the failure mode of AI Will Not Fix Your Bureaucracy wearing a new job title: a change that looks like progress because it is visible on an org chart, while the structure that produced the problem stays exactly as it was. Mabrey’s own conclusion is the same, from inside:

“The primary lesson to learn is to not copy the FDE but to provoke you to ask what assumptions are you making about the fabric of your company, and if you should be copying anything at all.”

The Forward Deployed Engineer is not a species of engineer. It is a Team standing in a different room.

What This Means for You

Three questions, and they are worth answering in order.

Which of your handoffs is the last one? Map the path from a customer’s problem to a working result and find the boundary that still requires translation. In most enterprises it is not the vendor boundary at all. It is the one between the people who talk to customers and the people who build, and it usually has a department name on it.

Who is accountable for the outcome, the person or the Team? If the answer is a named individual, you have a hero model, and it will work exactly as long as that person stays. If the answer is a Team, you have something that survives a resignation.

Where does what you learn at the customer re-enter your product? This is the question that separates the model from the tribute band. If the insight from an engagement lands in a slide deck, a lessons-learned document, or nowhere, you have paid for proximity and thrown away the return. Palantir turned that return into Foundry. In AME3 the same return has a defined path: it enters the Arena Backlog as an Improvement, and the Match forces someone to look at it.

The pattern is real, and the enthusiasm around it is earned. Just do not mistake the person standing at the customer for the thing that makes it work.

References