Forward Deployed Engineers

A forward deployed engineer (FDE) is a technical builder who works at the customer’s site rather than in the product company’s offices — occupying a physical desk, attending internal meetings, building alongside the customer’s employees, and iterating daily against the customer’s live problems.

The practice originated at Palantir (where the role gave the function its name), and has since been adopted in various forms by enterprise software companies. Nabeel Qureshi on Palantir and Forward Deployed Engineering provides the most detailed public account of how the model works in practice.

How it works

The classic Palantir FDE model:

Monday–Thursday on-site. The engineer works at the customer’s building, not from a Palantir office.
Monday–Tuesday–Wednesday iteration cycle. Monday in meetings; Monday night build; Tuesday show it; Tuesday night iterate; Wednesday show it again. Four to five fast loops per week.
Empowered to build new product. Unlike a solutions architect or consultant, the FDE can create net-new software, not just configure the existing platform. That empowerment is what made the role generative.
Build close personal bonds. FDEs become friends with customer stakeholders, go to dinner, understand the organisation socially. Trust is the precondition for getting access to the real problem.
Deep business-domain fluency. To solve the Airbus production problem, Nabeel’s team had to understand how aircraft move between factory stations, how SAP stores work-order data, and what the factory floor’s actual workflow looked like. The “domain secrets” discovered in this process seeded Palantir Foundry’s Ontology layer.

Why it produces founders

Nabeel’s thesis: each FDE engagement is a compressed startup cycle. Go into the building; gain trust; discover the real problem; build something that solves it; get tight feedback; ship. After five such cycles in five different contexts, a person has acquired the founder skillset — not through selection alone, but through deliberate repetition.

30% of PMs who leave Palantir start companies (Lenny’s data). The FDE model is a leading explanation.

The economics

The model requires a large ticket size to pencil out. Palantir charged customers based on outcome value (solving a $100M Airbus production problem → price anchors to outcome), not infrastructure cost. That justifies placing five to ten engineers at a single customer for months or years.

Below that ticket size (roughly $5M+), a modified version works: one FDE managing five customer accounts, spending less deep time at each, with a more defined offering. Many Palantir alumni founded companies targeting the customers Palantir found too small, using this lighter model.

What makes the model work (Nabeel’s criteria)

Real engineers who can build. Not solutions architects who configure. FDEs must be empowered to ship new software.
In-person presence. Zoom cannot replicate the trust-building that happens in a factory or hospital. Physical presence is not an efficiency constraint — it is the mechanism of discovery.
Deep business-domain understanding. Think of the customer’s organisation the way its COO does. A hospital wants to turn over beds; a factory wants planes moving between stations; understanding that framing is what makes the software prescription legible.
AI is changing the economics. Coding agents lower the cost of FDE-style work: one person can now do what previously required three, at lower ticket sizes, with faster iteration cycles.

Where mainstream views differ

The orthodox enterprise sales motion sends account executives and solutions engineers who demonstrate and configure existing software. FDE inverts this: the engineer is the primary relationship owner, and building new product for the customer is an explicit part of the engagement.

Critics argue: