What Is a Forward Deployed Engineer? The AI industry's most-hyped new title

A forward deployed engineer is a software engineer who works inside the customer's problem instead of at a safe distance from it. Same fundamentals as any other engineer — they write and ship code — but the codebase they touch, the meetings they sit in, and the definition of "done" all belong to somebody else's company.

The title has gone from niche to inescapable in about two years. It shows up on careers pages at frontier AI labs, agent startups, and infrastructure companies that had never used it before. Some of those postings describe a genuinely distinct job. Some are a support role with a raise and better branding. Learning to tell the difference is worth real money — and this is one of several titles worth decoding, which we map in the field guide to new AI job titles.

Where the role came from

Palantir popularized the term. Their model was unusual for a software company: rather than shipping a product and letting customers figure out the rest, they sent engineers to the customer — government agencies, banks, hospital systems — to sit inside the operation, learn the domain, and build directly on top of the core platform until something worked in production.

That structure existed because Palantir's product was a platform, not an answer. The platform was general; every deployment was specific. Somebody had to close that distance, and the company decided it should be engineers with real authority rather than consultants writing recommendations.

For a long time this was an outlier model that most of the industry regarded as expensive and unscalable. Then a technology arrived with exactly the same shape.

Why AI companies revived it

Foundation models are the most general-purpose products ever sold, and generality is precisely the problem. A model that can do almost anything does not, out of the box, do your thing — not against your data, your compliance constraints, your legacy systems, or your users' actual workflow.

"The demo works in twenty minutes. The deployment takes four months. Forward deployed engineers exist because someone has to own the difference."

That gap between an impressive demo and a system a company will actually run is the last mile, and it turns out to be long. It is full of data that is messier than anyone admitted, evaluation criteria nobody wrote down, integrations with software from 2009, and a domain expert who knows why the obvious approach fails but has never been asked.

None of that can be solved from headquarters by reading a support ticket. So AI companies rebuilt the Palantir model: put engineers on-site, give them the ability to change both the customer's integration and the product itself, and let what they learn flow back into the roadmap.

What the job is actually adjacent to

The confusion around FDE roles is mostly a confusion with four neighbors. They overlap, but they optimize for different things:

Role	Optimizes for	Where the week goes
Forward deployed engineer	Working in production	Split between the customer's system and your own product code
Solutions architect	The design that fits	Scoping calls, reference architectures, diagrams
Sales engineer	The deal closing	Demos, proofs of concept, security questionnaires
Product engineer	The core product	Your own codebase and roadmap
Consultant	The engagement delivering	Client site, defined deliverables, handoff

The distinguishing feature is commit access in two directions. A sales engineer builds a proof of concept that gets thrown away. A consultant delivers and leaves. An FDE ships something the customer depends on Monday morning — and then changes the underlying product so the next customer needs less hand-holding.

If a posting does not give you that second half, it is a customer-facing engineering role, which is a fine job, but it is not the thing people mean when they say the title is valuable.

What the week actually looks like

Expect an uncomfortable mix. A typical stretch involves reading a customer's undocumented schema, writing genuinely throwaway scripts to find out whether an idea is viable, sitting with the person who does the job you are automating, arguing internally that a rough edge you hit is a product bug rather than a customer quirk, and then writing production code under someone else's review process.

Travel varies enormously — some roles are heavily on-site, others are "forward deployed" over video and a shared Slack channel. That single variable changes the job more than any technical detail, and it is the first thing to pin down in a screen.

The intellectual pattern is the part people either love or hate: you are rarely working on a well-specified problem. Ambiguity is not an obstacle in this job, it is the material.

Who thrives, and who quietly hates it

Worth being blunt, because the title's shine hides a real cost.

It suits you if you get energy from talking to the person with the problem, you would rather ship something imperfect that gets used than something elegant that waits, you tolerate context-switching, and you like being the person who knows why the customer actually churned.

It will grind you down if you want deep, uninterrupted work on hard technical systems; you measure a good week in code quality rather than customer outcomes; or you find it draining to be the human face of a product's rough edges. FDEs absorb customer frustration directly, which is a real and underdiscussed part of the compensation.

There is also a career-path question worth asking out loud in interviews: where do FDEs at this company go next? Strong programs promote them into product, into engineering leadership, or into founding roles — they have unusually good judgment about what customers pay for. Weaker programs quietly turn into a permanent services arm. The company will tell you which one it is if you ask for specific examples of people who moved on.

What it pays

Compensation for these roles is genuinely wide, and anyone quoting you a single number is guessing. The structure is more informative than the figure: FDE roles tend to be levelled against software engineering bands rather than support ones, they skew senior because the job demands autonomy, and at some companies they carry a variable component tied to customer outcomes — which is unusual for an engineering role and worth understanding before you sign.

The practical move is to read posted ranges directly rather than trusting aggregate averages, since pay transparency rules mean many of these listings state their band. Our salary calculator is a reasonable starting point for the surrounding market, but the posting itself is the better source.

How to actually get one

The good news for candidates: this role rewards a background that traditional engineering interviews tend to undervalue.

1. Lead with deployment stories, not architecture stories

The thing being screened for is whether you can get something working in an environment you do not control. A story about migrating a customer off a legacy integration, or salvaging a project after the requirements turned out to be wrong, is worth more here than a systems design showpiece.

2. Make the customer contact explicit

If you have ever run an implementation, handled an escalation, or shipped something after sitting with the end user, that belongs high on the résumé — not buried under "other responsibilities." Most engineers underweight this experience because it does not look like engineering. For this role, it is the engineering.

3. Show that you close loops back into the product

Any example where a customer problem you encountered turned into a permanent product change is close to a perfect answer for this job. It demonstrates the exact two-directional instinct the role is built around.

4. Apply early — these roles fill in a hurry

FDE openings are usually tied to a specific customer commitment, which means there is a deal-shaped deadline behind them. They tend to move faster than an equivalent product engineering req and close before slower applicants have finished tailoring. If you want the mechanics of that, we wrote about the timing effect here.

If you're ready to start, browse open forward deployed engineer roles — and read a few postings side by side before you apply to any of them. The variation between companies is the whole lesson of this article.

---

The title will keep drifting — it already means somewhat different things at a frontier lab, a Series B agent startup, and an enterprise infrastructure vendor. What stays constant is the underlying bet: that the distance between a capable model and a working system is large enough to need engineers standing inside it. As long as that distance exists, so will the job, whatever it ends up being called.