Forward deployed engineering is a bet on the adoption gap

Everyone is suddenly talking about the forward deployed engineer. There are over a hundred YC startups hiring for the title, up from roughly zero three years ago, and the takes have arrived to match: definitional talks, skeptical debunks, explainer videos, breathless threads. It is the classic shape of a hype cycle, and the classic mistake is to read all the takes as equal. They are not. So I did the unglamorous thing and went through them, the operators who invented the motion, the skeptics who deflate it, and the explainers who repackage it, and weighted each by the only thing that matters here: whether the person has actually run the job. This is that weighted read.

The frame I trust comes from a profit-pool argument I have made before: when a capability commoditizes, the margin does not vanish, it slides to the adjacent layer that stays scarce. Every company can now rent the same frontier model, so intelligence is no longer the edge. The scarce layer is adoption, which is exactly why deployment is the moat: the forward deployed engineer is the human who works there. Hold that, and most of the noise sorts itself out.

The bet: the bottleneck is adoption, not intelligence

Start with why the role exists at all, because every credible source lands in the same place from a different direction. Bob McGrew, who ran product and engineering at Palantir while the model was invented and later led research at OpenAI, frames it as a market condition: AI agents have no incumbent product to copy, so no one yet knows what to build, and the only place to find out is inside the enterprise. Colin Jarvis, who runs the function at OpenAI, frames it as a trust problem: on the Morgan Stanley deployment the technical build took six to eight weeks and earning enough trust to change how advisors worked took another four months. Kevin Bai, who invented FDE functions at Palantir and Rippling, frames it as a fit problem: you only need it when the product is too technical for the buyer to operate. Three operators, three angles, one underlying fact. The models can already do far more than any enterprise has actually put to work, and that gap, not raw capability, is the binding constraint of this cycle.

Put simply: the reason this role appeared now is that AI capability sprinted ahead of adoption. Renting a frontier model is easy and universal; turning it into a working system inside a messy enterprise is neither, and that gap is where the money and the work are. Everything else is a detail of who does that and what we call them.

Weight the operators over the explainers

Here is the part most coverage skips: the sources are not equal, and reading them as if they were is how you end up confused. Sort them on two axes. One is authority, from explainer, someone narrating the role from outside, to operator, someone who has actually built and run it. The other is stance, from skeptic to believer. Plot the voices and a clear hierarchy appears. McGrew, Bai, and Jarvis sit in the operator-believer corner, and they are the ones to weight most, because they are describing mechanics they have lived. Natalie Meurer of Sierra, a Palantir forward deployed engineer from the origin years, sits as an operator-skeptic, which makes her the most valuable dissent, informed rather than reflexive. Jean Lee, a commentator, sits as an explainer-skeptic: her critique is sharp but it is analysis, not practice. The explainer videos sit near the middle, useful as onboarding, weak as evidence. When two of these disagree, the tie does not go to the loudest or the most viral. It goes to the one who has run the motion.

Put simply: do not average the takes, rank them. The operators who built the function outweigh the commentators explaining it, and among the skeptics the one who has actually done the job outweighs the one theorizing about it. Read the discourse with that weighting and the contradictions resolve.

The signal: what the operators actually agree on

Weighted that way, a surprisingly consistent playbook emerges, and it is the part worth keeping. You are not selling software, you are selling an outcome, the fact that a problem got solved, which everyone from Bai to Jarvis to McGrew states almost identically. You go deep on one customer and carry back a reusable primitive rather than a bespoke build, which is how, in Jarvis's account, a Klarna engagement became Swarm became the Agents SDK became AgentKit. You must build on a platform, not from scratch, or, as McGrew puts it, you have a dev shop whose maintenance bill compounds until it kills you. And the honest financial tell that you are running a software business and not a consultancy is the margin curve on a single customer: it starts negative, because you need a large team on site, and crosses into positive as the product absorbs what you learned and you earn harder problems. Consulting never makes that crossing. That is the signal, and it is remarkably stable across four independent operators.

Put simply: the operators, who have every reason to disagree, converge on a small, concrete playbook: sell outcomes, generalize into a platform, and watch the single-customer margin climb from red to black. That convergence is the real content. If a take is not about those mechanics, it is probably noise.

The noise, and the one true thing buried in it

The skeptics are right about the title, and it is worth saying plainly. Meurer's dirty secret is that forward deployed engineer has been stretched to describe so many jobs that it means almost nothing: combine the job postings and you get an impossible composite person who does not exist. Jean Lee's charge is that it is largely a rebrand of the decades-old sales engineer and solutions architect, with the word engineer chosen to recruit builders who would never take a sales title, which even Jarvis half-confirms when he admits one flagship engagement was a solution-architect job done in an FDE style. The helicopter mythology, the parachuting hero fixing a system mid-air, is marketing over a role that, in Meurer's telling, began as two a.m. DevOps babysitting. All of that is noise, and you should discount it. But Meurer, the informed skeptic, does not stop at demolition. She isolates the one thing every version of the role has always shared, across DevOps and integration and enablement and agents: accountability to the customer's outcome. Strip the title and that invariant is what is left, and it is the same thing the believers are selling under a different word.

Put simply: the skeptics win the argument about the word and lose the argument about the work. Yes, the title is overloaded and part rebrand and will be renamed again. But underneath every version sits one durable thing, ownership of a customer's outcome, and that is precisely what the operators are describing. The noise and the signal point at the same core.

What to actually do about it

So here is the synthesis, and it is almost boring in how much everyone secretly agrees once you weight them. The title is noise. It is overloaded, it is partly a recruiting device, and in three to five years it will be called AI architect or solutions engineer or something not yet coined. Do not chase it. The function is signal, and it is durable: close the gap between what AI can do and what a specific business has actually adopted, by owning the outcome end to end. That is a bet that adoption, not intelligence, is the scarce thing, and it is the same bet whether you call the person a forward deployed engineer, a consultant who can build, or nothing at all. Build the capability, understand a real business problem, turn it into a system, deploy it into the mess, secure it, and codify what you learned, and you are valuable in this cycle regardless of what the job board calls it next quarter. The role is a bet on the adoption gap. The gap is real, it is wide, and it is not closing on its own.

Put simply: stop arguing about the title and make the bet the title is pointing at. Adoption is the bottleneck, closing it is the job, owning the outcome is the invariant, and the capability to do that outlives every rename. Everything else in the forward deployed conversation is commentary.

The show notes behind this

This is a weighted read of seven source writeups. If you want the raw material, here it is, roughly in the order I leaned on it:

• Bob McGrew on the forward deployed playbook
• Kevin Bai, Forward Deployed Engineering 101
• Natalie Meurer on the dirty secret of the role
• Colin Jarvis on running the function at OpenAI
• The SPC panel on where the role goes next
• Jean Lee on the hype
• Soleyman, the consultant who builds