The Forward Deployed Engineer Is Now AI's Hottest Hire — And It Makes Sense Why

If you've been anywhere near the AI hiring market lately, you've seen the term forward deployed engineer showing up on job boards at OpenAI, Anthropic, Databricks, Ramp, and now PostHog. The role clocked 800% job growth in 2025 and a16z called it the hottest job in startups. The question is: why now, and what does an FDE actually do?

The Origin: Palantir's Solution to a Deployment Problem

The Forward Deployed Engineer (FDE) is a Palantir invention. When Palantir was building intelligence software for government customers in the 2000s, they ran into an unavoidable wall: even simple demos required weeks of NDAs and security clearances. No standard sales motion worked.

Their solution was to send engineers directly into customer sites — "forward deployed," the way the military deploys assets close to where they're needed. These engineers embedded with customer teams, got the approvals required to work with actual data, and built what customers needed on-site. What they learned fed directly back to Palantir's core product teams, who generalized the solution for the next customer.

The model created a flywheel: customers got tailored solutions fast, Palantir got unfiltered product intelligence, and the core team had a tested signal on what to build next.

Why AI Companies Need This Now

The original Palantir problem has resurfaced at scale across the AI industry. As Anjor Kanekar, a seven-year Palantir FDE who's now at the center of this conversation, put it:

"AI companies have the models, but they need to figure out what exactly needs to be built using the models to make inroads into large enterprises and the public sector."

Three structural forces are driving the FDE surge:

Contract sizes are huge. Enterprise AI deals run six, seven, and eight figures. At that price point, companies can afford — and customers expect — engineers embedded on-site to make the product actually work. Consultants used to play this role; AI companies are now absorbing the cost to land better contracts and gather better product data.

Data privacy is non-negotiable. Enterprises won't hand over financial records, customer data, or proprietary systems to an AI vendor without deep access controls and established trust. FDEs get the permissions that a typical vendor relationship doesn't. They're not just selling software — they're operating inside the customer's environment.

Executives need to see it to believe it. Demos don't move enterprise procurement. Decision-makers, particularly at traditional companies, remain skeptical of AI's practical usefulness until they see results on their own data. FDEs remove that barrier by building real outcomes with real data, not a sanitized proof of concept.

When OpenAI worked on voice models, FDEs embedded with a call center automation customer, built the evals to test real-world performance, and took that data back to the core research team. The result became OpenAI's Realtime API — a product shaped by genuine deployment, not hypotheticals.

FDE vs. Software Engineer: A Real Distinction

The comparison that matters most is with product engineers. Both roles build quickly and talk to users. The difference is surface area: a product engineer is solving a problem shared by many users, working toward a generalizable solution. An FDE is solving one customer's problem, and generalizability is explicitly a secondary priority.

Bob McGrew, an early Palantir executive, described FDEs as the ones who build the gravel road — rough, fast, functional. Software engineers on the core product team then pave it into a highway that ten customers can drive on.

In numbers:

	FDE	Software Engineer
Primary focus	Customer-specific solutions	Scalable, generalizable features
Customer time	60–80% of their day	10–20% of their day
Travel	20–50% typical	Minimal to none
Build style	Rapid, scrappy prototypes	Production-ready, maintainable code
Success metric	Contract renewal, customer results	Feature adoption, system stability

Who Makes a Good FDE

The profile that keeps appearing in FDE job descriptions: 5+ years of engineering experience, customer empathy, executive presence, low ego, and a tolerance for ambiguity. Palantir CTO Shyam Sankar has described the ideal FDE as a "heretic" — someone with deep domain knowledge and the energy to apply it unconventionally.

Notably, every trait in that list overlaps heavily with what makes great product engineers and founders. Former Palantir FDEs have an outsized track record of starting their own companies, which says something about the shape of the role.

When It Makes Sense — and When It Doesn't

The FDE model is not the right answer for every company. If your standard product-market fit playbook is working, you don't need it. The FDE strategy involves years of effort against a single customer account, and the economics only make sense at high contract values.

It does make sense when:

• Your product requires deep integration with existing infrastructure and you can absorb the cost
• You're in a regulated industry (healthcare, finance, government defense) where compliance expertise is table stakes
• You're entering a new vertical where you don't know what you don't know, and customer discovery has to happen in the field

Ramp started building for small businesses and added FDEs when enterprise customers brought challenges the existing team wasn't equipped to handle from a distance. PostHog just hired its first FDE — but doing it PostHog-style: fully remote, async, and focused on automation rather than physical on-site work. The underlying goal is the same: go work with customers rather than just talk to them.

The FDE role will keep evolving as AI capabilities improve. As the gap between model capability and enterprise deployment closes, the people who can bridge that gap in real customer environments will remain valuable. That's a long-term structural role, not a trend.