Deltas, Devs, and the Gravel Road: The Palantir Vocabulary Behind the FDE Role

Every discipline worth joining has an inherited vocabulary, and forward deployed engineering inherited most of its own from one company. If you are preparing for an FDE role in 2026, at an AI lab, a data platform, or a startup that did not exist three years ago, the words you will hear in interviews and all-hands trace back to Palantir: Deltas and Devs, the ontology, the gravel road. Knowing what they mean is partly interview preparation and partly cultural literacy, because the companies hiring today are running recognisable adaptations of the same playbook.

The short version: Palantir split engineering into customer-embedded engineers and platform engineers, invented working vocabulary for how the two feed each other, and proved the loop could compound into a product company rather than a consultancy. The AI era then rediscovered the same problem, the last mile between a capable model and a workflow somebody actually uses, and reached for the same design. The what is an FDE guide covers the role itself; this post is about the words.

Deltas and Devs: the two-track design

Palantir's engineering organisation has two tracks with internal names that stuck. Devs build the platforms, Gotham and Foundry, and rarely visit customers. Deltas, the forward deployed software engineers, deploy those platforms into customer environments and live with the consequences. The name is not a metaphor: it is a holdover from the company's early days, when business development teams were named after letters of the NATO alphabet. The lore is documented in Palantir's own engineering blog and in Nabeel Qureshi's Reflections on Palantir, the single most read first-person account of the role, which describes Deltas as typically onsite at the customer three to four days a week.

The design insight is not the split itself, which every enterprise vendor has in some form. It is the return path. Deltas do not just deploy; they surface what the platform is missing, and Devs treat recurring field patterns as the roadmap. Qureshi's essay describes exactly how Foundry took shape this way: FDEs did cruft work manually at customer sites, and product engineers built the tools that automated it, until the accumulated toolset became the platform that now drives the majority of Palantir's revenue. The pivot shows up in the numbers he cites: software gross margins of around 80%, against roughly 32% at a consultancy like Accenture. That is what the return path is worth. One direction ships value to a customer; the other is what makes the next customer cheaper, and it is the difference between a software company and a body shop. Our engagement loop lesson teaches this as the stage teams skip, because it is the only stage with no customer asking for it.

The cultural bias behind it all was proximity. Qureshi describes the company's operating instinct as "get on a plane first, ask questions later", to a degree that produced out-of-control travel budgets and a decade of compounding customer knowledge that nobody else had. His own first engagement is the cleanest illustration: he moved to Toulouse for a year and worked inside Airbus's A350 factory four days a week, building what he summarises as Asana, but for building planes, software credited with helping quadruple the pace of A350 manufacturing. Not a demo. A year, in the factory, four days a week.

The gravel road and the paved superhighway

The most useful single image in the FDE canon is attributed to Bob McGrew, an early Palantir executive, and popularised more recently by PostHog's much-shared explainer on the role. When an FDE enters a messy customer environment, they build a gravel road: a bespoke integration, a scrappy pipeline, a targeted workflow that gets this one customer from A to B fast. It is not elegant and it is not meant to be. Then, once the road is carrying real traffic, the core team looks at which gravel roads keep being built across customers and paves the recurring ones into a superhighway: a hardened, generalised feature the next hundred customers get out of the box.

Two things make the image precise rather than merely pretty. The gravel road is supposed to be rough; polishing it before the route is proven wastes exactly the time an FDE exists to save. And not every gravel road gets paved; most turn out to be one customer's private shortcut, which is why the judgment about which patterns generalise is a real skill rather than an automatic step. The rule of thumb we teach in the courses: the third time you build something that resembles the last two, stop and generalise it. Not the first, not the fifth.

The ontology: model their world first

The third inherited word is ontology: a semantic model of the customer's operational world, their entities, properties and relationships, built before any analytics or AI are layered on top. At Palantir this is a literal product concept in Foundry. As inherited culture, it encodes a habit that outlives any product: model the domain in the customer's own language before you compute anything.

That habit translates directly into the AI era, which is why the word keeps resurfacing. A retrieval system over enterprise documents, an agent acting on a logistics workflow, a text-to-SQL layer over a warehouse: each one works precisely to the degree that somebody first mapped what a shipment, an exception or an account actually is in this company's world, including the five systems that disagree about it. Candidates who reach for chunking strategies before asking what the entities are tend to lose the design round; the ones who do discovery first are doing ontology work whether they use the word or not.

Ontology was only one entry in a much larger private vocabulary. Qureshi lists others: "impl", "compounding", "metabolizing pain", "the 36 chambers", "gamma radiation", each compressing a set of insights the company had earned the hard way. His career advice from the observation is worth passing on: when evaluating a company to join, look for a rich internal language, because it is evidence that the people there have been thinking hard enough, for long enough, to need new words.

Why the vocabulary spread

When foundation models commoditised raw capability, the differentiator moved to the deployment layer, and the industry reached for the one proven playbook. OpenAI, Anthropic and Databricks all run customer-embedded engineering functions descended from the Palantir design, under titles ranging from forward deployed engineer to applied AI engineer. Startups publish their own adaptations: Ramp's builders blog describes an FDE team whose mantra is "always be scoping", a deliberate riff on sales' oldest slogan, and whose hiring filter favours people with teaching experience. PostHog runs the role fully remote and asynchronous, which would have been heresy in the badge-and-travel original.

The adaptations differ; the skeleton does not. Two tracks, a deliberate feedback loop from field to platform, and engineers who own outcomes rather than tickets. If you are interviewing for any of these companies, including Palantir itself, the vocabulary in this post is load-bearing: it is how your interviewers were taught to think about their own jobs, and a candidate who understands why the gravel road is supposed to be gravel has understood the role better than most of the people applying for it.

The place this vocabulary is put to work on FDEInterviews.com is the courses: the engagement loop, the productisation stage and the discovery-first habit each get a full lesson, with the opening modules free to read and the complete arc, capstones included, behind a single subscription that also unlocks the question bank.