The Forward Deployed Engineer

The short version

Nobody agrees on what a forward deployed engineer is. That breaks two things.

It breaks pricing, which is the easy one. The comp spread on this title is unusually wide, and it is not just because the market is irrational. Three genuinely different jobs are wearing the same title and each prices differently. Sort the definition and the number mostly answers itself.

It breaks hiring, which is harder, and is why most of what follows is not about money. The thing that makes these people worth the premium does not appear neatly on a résumé and is not created by the offer. Some of it is selected for. Some of it is produced by the environment they came from. And some of it can be switched off in a quarter by the environment they arrive in.

Three jobs, one title

1. The implementation FDE. Configures and integrates the product inside a customer environment. Closest to solutions engineering. Real technical depth, but the center of gravity is getting the deployment working for that customer.
2. The product-building FDE. The Palantir lineage. Embeds deeply with a customer, writes production software against real customer problems, and creates a feedback loop between deployment and product. Palantir has framed the orientation as “one customer, many capabilities,” against the more traditional “one capability, many customers.” The distinguishing question is not simply whether they deployed the product. It is whether what they learned at the customer changed what the product could become.
3. The revenue FDE. Sits closer to sales, activates accounts, and increasingly carries some number. Common in enterprise AI, and increasingly paired with variable comp and net-new-revenue accelerators.

These are not seniority levels. They are different jobs.

A company posting for one and benchmarking against another is the single most common comp error I see in this role right now.

The title has also begun appearing on postings for roles involving neither forwardness nor deployment, which is not helping.

What the market pays

Base salary, from job postings. A June 2026 analysis by Recruiting from Scratch of 924 FDE postings put median base salary at $195,000, with the 25th percentile at $160,000 and the 75th at $215,000. San Francisco came in around $194,000 and remote around $180,000.

Other datasets produce somewhat different numbers depending on which postings they include, which is not surprising given the title problem described above. I consider observed job-posting data more useful here than self-reported compensation, but I would still not set a band without first defining which FDE you are actually hiring.

Total compensation gets considerably messier. At the high end of the market, particularly frontier AI companies and well-funded applied AI startups, equity can dwarf cash compensation. Enterprise packages tend to carry considerably less equity and more predictable cash.

The closer the role gets to product creation, scarce technical capability and revenue impact, the more expensive it gets.

And the more of the offer that comes in equity, the more important it is to remember that “total compensation” is partly a forecast.

If I were presenting this to a board, I would spend less time debating whether the median is $190,000 or $200,000 and more time asking why this role suddenly commands the premium at all.

Why the demand appeared

a16z's Joe Schmidt made the argument better than I will in Trading Margin for Moat. Enterprises buying AI, in his framing, are a little like your grandmother getting an iPhone. They want it, and they need you to set it up.

The startups winning these deployments are sometimes trading near-term gross margin for control of implementation, workflow and data, a pattern Schmidt compares to earlier enterprise software transitions.

The FDE is the person who executes that trade.

Which is why the hiring profile matters so much.

The profile increasingly sought by these companies is some combination of technical depth, curiosity, urgency and unusually high agency.

I have been making that argument about hiring for a long time. It is also one of the hardest instructions to actually follow, because pedigree is legible and agency is not.

Every sourcing tool on the market indexes the former. None of them indexes the latter particularly well.

This is usually the point where someone says they hire for slope rather than intercept, and then asks where the candidate went to school.

How to tell a real one

The screen that separates the archetypes, in order of how much signal I think it carries:

1. Tell me about something you built for one customer that changed what the product team built next.This gets at the feedback loop. A strong product-building FDE can move from a messy, specific customer problem to something generalizable.
2. Tell me about a deployment where the requirements were wrong.Real FDEs usually have a story here, and it is usually specific and slightly painful. People who have operated further from the problem are more likely to describe a process.
3. What did you say no to?The failure mode of the role is building whatever the customer asked for. I want to know whether the person can distinguish a customer request from the underlying problem.
4. Where have you worked that was not an office?Factory floors. Air-gapped environments. Hospitals. Military installations. Customer sites. The precise environment depends on the company, but discomfort is often part of the job.

None of these questions is foolproof. Together they tell me considerably more than another LeetCode screen about whether someone actually understands forward deployment.

What the Palantir pool actually has

A disclosure before the observation: I am a Palantir American Tech Fellow, which you should weigh when reading anything I say about their alumni.

What follows is what I watched about how people work there, not anything about what they work on.

Palantir selects for agency.

But it also creates an environment that compounds it.

Everyone is an owner. Nobody waits around very long for permission. You have an idea, you go do it.

“Nobody has a boss and everybody is the boss” reads as a slogan until you watch someone act on it on a Tuesday.

There is not a lot of hand-holding. You are dropped into a problem, surrounded by people who have solved a great many problems with technology, and your proximity to them is part of the onboarding.

That is the mechanism I found most interesting.

Not simply a training program. Not simply a career ladder.

Sit close to people who are very good at solving problems and be handed a problem nobody has completely scoped for you.

Over and over again.

Which explains two things at once.

It helps explain why the pool is genuinely good.

And it explains the failure mode of hiring out of it.

Bring one of these people into a company where work is assigned, spend needs three approvals, and the response to an unsanctioned idea is a meeting in two weeks, and you may have paid a premium for a capability you are in the process of switching off.

They will be polite about it for about a quarter.

Which scales badly in one direction.

One of these hires into the wrong culture is a bad hire.

A go-to-market motion built on forward deployed engineers, inside a company that does not work anything like the environment that produced them, is a strategy problem that will eventually get handed to a recruiter.

You cannot recruit your way around the conditions required for the behavior you want.

So if an army of forward deployed engineers is the plan, the first piece of work is not a search.

It is making sure the culture is one that would attract that kind of human and keep them past the second quarter.

Which means the most useful screening question I would ask is not of the candidate.

It is of the hiring company:

What happens here when someone starts something nobody asked for?

If the honest answer is that it depends who they are, you have a different problem than a sourcing one.

Where the supply is

Palantir alumni are the obvious pool and also the most picked-over, so the markup is real. You are bidding against everyone else who has read one article about Palantir.

The less obvious pools are more interesting:

• Infrastructure and platform engineers at companies that sold into complicated enterprise environments.
• Deployed engineers from industrial, aerospace and energy software.
• Technical founders whose companies did not make it.
• Solutions architects at enterprise vendors that actually required their SAs to write production code.
• Engineers who have spent substantial portions of their careers somewhere messy: factories, customer sites, field operations, classified environments, hardware programs, implementation teams.

I would search for the conditions that created the capability before searching for the title.

One constraint worth naming: anyone recruiting for a defense-facing or export-controlled deployment needs to raise ITAR, export-control and any applicable U.S.-person requirements before the search strategy is written, not after the slate is built.

It is a cheap conversation in week one and a remarkably expensive one in week nine.

The honest caveats

Compensation data for this role is still noisy.

The job-posting figures are the sturdier numbers available because they are observed rather than recalled, but even those datasets are comparing jobs that may share a title without sharing a job.

Total compensation is considerably harder. Equity valuations, company stage, geography and inconsistent definitions make cross-company comparisons particularly slippery.

I would not set a compensation band from an internet FDE table.

I would start by answering three questions:

What is this person actually going to build?

How close are they to the customer and to revenue?

Does what they learn change the product?

Then benchmark that job.

How this was made

I used AI heavily to write this.

Pulling and cleaning postings data. Structuring the archetypes. Organizing research. Laying out tables. Challenging claims. Tightening prose.

It was good at all of it.

It was considerably less useful with the part that matters: knowing which distinctions actually predict whether someone can do the job.

That came from running searches, watching these roles evolve, talking to the people doing the work, and getting things wrong a few times first.

Which is roughly the argument of the whole piece.

The legible parts are getting cheap.
The judgment is not.