DEV Community

Michael Tuszynski
Michael Tuszynski

Posted on Originally published at mpt.solutions

Forward Deployed Engineer Names Four Different Things. One of Them Is a Software Product.

Forward Deployed Engineer Names Four Different Things. One of Them Is a Software Product.

The same three words now label a job at one frontier lab, a different job at the same lab, a billion-dollar organization at AWS, and a piece of software you can turn on inside Palantir Foundry.

That last one deserves a second read. Palantir invented the role, and Palantir now ships AI FDE, which the docs introduce as "the AI-powered forward deployed engineer," an "interactive agent that operates Foundry for you through conversational commands."

So when two people say "we need an FDE on this," there is no longer any guarantee they are discussing the same category of thing, let alone the same scope of work. That's a scoping problem, and scoping problems are expensive for whoever is holding the statement of work when they surface.

Eight years in presales left me with one reflex above all others: get the boundary of the work written down before anybody starts building. This title needs that treatment.

The role began as an answer to an information problem

Palantir popularized the term and had it in use for staff by 2009. The phrasing is borrowed from the military's forward-basing language. What it solved was a problem about information rather than cost.

You cannot write a specification for software that has to run in an environment you have never seen. Undocumented schemas. Compliance rules nobody wrote down. A workflow that lives in the heads of six people in one building. An architect who visits, produces a design, and flies home hasn't transferred knowledge — they've transferred a guess, and the guess fails in integration.

The fix was to stop splitting the person who learns the environment from the person who writes the code. Same engineer, both jobs, on site, accountable through production.

That original definition has four parts worth separating, because they behave very differently under automation:

  1. Learn an environment that isn't documented.
  2. Decide what to build in it.
  3. Build it against the real data.
  4. Own it in production, or hand it over with the knowledge attached.

What the software version actually does is step three

Read Palantir's capability list rather than the product name. AI FDE handles data integration and pipeline modification, data connection management, ontology editing, function writing and testing, read-only exploration, governance and access auditing, and React application development.

Every item on that list is platform operation. Each one presupposes two things: that somebody has already decided what should be built, and that the target is Foundry. On day one of a real deployment, neither is true.

To Palantir's credit, the documentation claims nothing more than that. There is no line on that page about replacing human FDEs — the product is scoped as a way to operate the platform faster, which is exactly what it appears to be. The overreach isn't in the docs. It's in reading the product name as a description of the role.

Which makes step three the honest answer to "what can AI do here." Building against real data is getting dramatically faster. Steps one, two and four are close to untouched, because none of them are typing problems. Nobody has automated walking into a business you don't understand and working out which of the things people are complaining about is the one worth building.

Two job titles at one company already disagree

Inside OpenAI the split between step three and the rest is visible in the org chart.

The Forward Deployed Software Engineer posting wants 7+ years of full-stack work and describes coding "side-by-side" with customer teams "on their infrastructure," designing abstractions that later engagements reuse. That's steps three and four, with the original accountability intact.

The Forward Deployed Engineer posting owns "discovery, technical scoping, system design, build, and production rollout," plus sequencing, tradeoffs between scope and speed, playbook authoring, and field feedback that "changes product and model roadmaps." It contributes code "when progress or clarity depends on it." Conditional, by design.

Both are reasonable jobs. They are not the same job, and the difference is which of the four steps the person is accountable for. A team that hires the second expecting the first will be surprised, and so will the customer.

The category got funded faster than it got defined

Anthropic and OpenAI stood up forward-deployed groups in May. On June 30, AWS committed $1 billion to a Forward Deployed Engineering organization it describes as "agentic-first," compressing "timelines from months to days," and designed so "customers are self-sufficient when a deployment ends." Two days later Microsoft announced Frontier Co. with $2.5 billion and 6,000 embedded engineers.

Treat the months-to-days figure as a vendor ceiling rather than a planning number; no independent measurement of it exists yet. But the pattern is clear enough without it: billions of dollars of organizational design arrived in about eight weeks, and shared vocabulary takes longer than that.

The market's own uncertainty shows up in what it pays. Two frontier labs are hiring for this title in the same city right now, and their posted base ranges start $95K apart — $185K at one, $280K at the other. That's not an argument about whether the role is valued. It's a straightforward signal that the scope behind the words hasn't converged.

The strongest objection is that this is genuinely new work

a16z's Tom Hollands argued in January that forward-deployed titles describe work that would have been unrecognizable five years ago, and he's right about the mechanism. An AI system's capabilities only resolve once you build against the customer's real data, which breaks the design-it-then-hand-it-off sequence and collapses steps two and three into one person. His test for whether a new title is doing real work: does it describe something that didn't exist before?

Apply that test to the mechanism and it passes. Apply it to the vocabulary and the picture changes, because the same three words now cover step three alone, all four steps, an organizational strategy, and a Foundry feature. New work deserves a new name. It also deserves a definition, and the second part hasn't happened. Worth noting that a16z funds many of the companies staffing these teams.

The scope belongs in writing before the kickoff

Not a candidate checklist — a scoping checklist, equally useful from either side of the table:

  • The artifact. What gets shipped, named outright: an MCP server, a data pipeline, an application running in the customer's stack. "Scopes of work and project plans" is a real deliverable too, but it's a different one.
  • The requirement owner. Who decides what gets built. If that's the customer, this is step three and can move fast. If it's the deployed engineer, steps one and two are in scope and the timeline is a different shape entirely.
  • The production owner at exit. The original role's defining trait was that whoever mapped the problem answers the page six months later. "Self-sufficient when the deployment ends" is a legitimate model, and a different commitment. Both are fine. Assuming one and getting the other is not.
  • The platform boundary. Whose stack, with what access, and which parts an agent can operate directly. This is where the software version of the title is genuinely useful, and where its limits are hard edges rather than preferences.

Where this argument runs out: a two-year-old title is supposed to be unsettled, and dispersion this early proves nothing about anyone's intentions. Posted ranges are base only, and equity is undisclosed, so the $95K figure describes disclosure practice as much as scope. And a single vocabulary may never arrive — "DevOps" never fully converged either, and teams still shipped, because the good ones wrote down what they meant locally.

That last part is the actual ask. Not an industry standard. Just a shared sentence, written before the kickoff, naming which of the four steps the forward deployed engineer owns. The role was invented because a handoff document couldn't carry the knowledge. It would be a strange outcome if the title itself became the thing nobody could hand off.

Top comments (0)