Nabeel Qureshi on Palantir and Forward Deployed Engineering

Guest: Nabeel Qureshi — Former VP of Business Development at Palantir (8 years); previously visiting scholar at Mercatus Center (AI policy with Tyler Cowen); founding member of GoCardless; worked with NIH on large medical datasets.
Host: Lenny Rachitsky
Source: Lenny’s Podcast.

Overview

An inside account of Palantir’s operating model: how forward deployed engineers create a customer-proximity loop that produces founders at a higher rate than any other company in the world, how the services-to-platform transition happened, and what hiring and cultural practices made Palantir the world’s premier product leadership forge. Minimal AI/LLM content; primarily about product and organisational strategy.

Key ideas

Forward deployed engineers. Engineers who work at the customer site 4 days a week, literally getting a desk, building solutions to the customer’s actual problem, not a pre-conceived product vision. The fast feedback loop (5 iteration cycles per week) is the core training mechanism for founders.
Services to platform. The transition from bespoke customer solutions to a generalised platform (Foundry) happened by first being their own first customer — building internal tools for FDEs, then mandating customers use them. Three to four years of pain produced a genuinely differentiated product.
Ontology. The key product insight from the Airbus engagement: map alien database tables to human-legible concepts (part, work order, aircraft). This “ontology” layer became Palantir’s biggest Foundry differentiator.
No titles. Everyone is “forward deployed engineer.” The rationale: titles become a metric people game (Goodhart’s Law). Without explicit titles, contribution must be demonstrated continuously.
Murder boards. Standard practice for new projects: write a two-page plan, invite three to four people who know nothing about it, and let them tear it apart. Principles in the plan must be genuinely contestable — if nobody can disagree with a principle, it is not a real principle.
Distinctive bad signal. Palantir’s culture (defence/intelligence focus, “Save the Shire” slogan) intentionally filtered out people who wanted a social-media-style mission. This attracted people who wanted to work on “hardest, messiest problems in the world” — a filtering mechanism as important as the positive signals.

Forward deployed engineering

The FDE weekly cadence at an engagement:

Monday: arrive at client site; run meetings.
Monday night: build something based on what was learnt.
Tuesday: show it to someone; get feedback.
Tuesday night: iterate.
Wednesday: show again; iterate.
Thursday: fly home.

Result: 4–5 iteration cycles per week, against real users with real problems and real stakes. Nabeel describes this as why so many founders emerge from Palantir — five FDE engagements across disparate contexts is equivalent to five mini-startup cycles.

Cost structure. FDEs are only economical at large deal sizes (many millions per contract). The model does not scale to small tickets. For smaller deals: one FDE covering five customer accounts (less deep, same principle). The key question is whether the engineering investment can be justified by the deal size and learnings.

When to do it. If your customer engagement produces learnings that are generalisable across a market, the FDE model pays for itself twice: it closes the deal and funds the next product. If you are doing one-off bespoke consulting with nothing generalisable, you are just a services business.

The Airbus case study

Problem: ramp A350 production 4× in one year. Root cause: factory workflow data was trapped in SAP with unintelligible table names (e.g. S3_F1_Z). Workers could not see what work had been done at the previous station, what parts were needed, or what work orders were outstanding.

Solution: pull SAP tables, join them, and map them to human concepts — aircraft, station, work order, part. Build a unified view of the factory state. Effectively: Asana for a plane factory.

Product generalisation: the concept of an “ontology” (a set of human-legible concepts that map to raw data) became one of Foundry’s biggest differentiators. It was discovered not by product theorising but by living the problem for months.

Palantir culture and hiring

Three hiring criteria: independent-mindedness (push back, question the frame), broad intellectual interests (Habermas in a CEO memo is unremarkable), intense competitiveness (win at all costs).

Undervalued talent pools. Palantir systematically recruited people who were technical but outside the Silicon Valley ecosystem: ex-military, intelligence community, people doing MBAs to transition out of government service. These people had accomplished “very difficult goals in very hostile environments” — exactly the Palantir FDE context.

The founder interview. For a long time, every hire required a founder interview. With Stephen Cohen: unstructured philosophy discussion for 90 minutes. Could not prepare. Vibe check. This was not inefficiency — it was the final filter.

Titles. No titles except CEO and six directors. Rationale: titles become Goodhart’s Law traps. Without them, people cannot game a promotion system; they must earn their position continuously. Downside: informal hierarchy based on proximity to key executives fills the gap.

Murder boards

For every new project: write a two-page plan (vision, goals, three-month tactics, guiding principles). Invite three to four people who know nothing about the project to attack it.

Key insight about principles: a good principle must be genuinely contestable. “Move fast” is not a useful principle — nobody can reasonably disagree. A useful principle is one that many people would argue against, because it makes a real trade-off explicit.