Inside Palantir's Founder Factory: Forward-Deployed Engineers, Ontologies and Deliberately Off-Putting Hiring

Host Lenny Rachitsky opens with data from his research on product managers: about 30% of PMs who leave Palantir start a company, the highest rate of any company he looked at, with Intercom second at 18%. Qureshi, who left the company in 2023 after almost eight years, answers the question every employee gets by saying Palantir achieves outcomes for very large customers through a data platform. Gotham is the version built for intelligence and defense, and Foundry is aimed at commercial use.

On the early culture, Qureshi says the company screened hard for three traits. The first was independent-minded people who questioned the frame of everything and were not afraid to push back. The second was broad intellectual interests, and the third was an intense, win-at-all-costs competitiveness. A founder had to interview every candidate, and Stephen Cohen's interviews could be an hour and a half of philosophy on a topic he picked out of thin air.

Qureshi connects this to Peter Thiel's idea that the best recruiters send out a distinctive bad signal that turns some people off. He compares it to how OpenAI and Anthropic attract people who are almost messianic about superintelligence. Palantir's version was a focus on defense, intelligence and preserving the West, with a "Save the Shire" slogan, at a time when the hot companies were social and mobile apps. Rachitsky adds that defining who a company is not for is a lesson he took from writing Airbnb's core values.

Palantir also tapped a talent pool that was undervalued at the time. Qureshi says people leaving the military or intelligence agencies, who might otherwise have joined a Fortune 500 firm, were used to hard goals in hostile environments, which suits a chaotic young company. He says that, besides selecting for leaders, the company also trained them.

Palantir avoided traditional titles, and Qureshi cites Thiel's reasoning in Zero to One: titles give people something to compete for, which produces unproductive conflict and Goodhart's-law behavior. He points to ex-Google employees who complain that promotion rewards launching a new product rather than improving an existing one. At Palantir nearly everyone had the same slightly meaningless title, forward-deployed engineer, and only the CEO and six directors had real ones.

The approach has costs. Alumni sometimes update their LinkedIn with inflated titles, which Qureshi says is understandable, because leaving a company means making your experience legible to the next employer. Competition also moves from titles to proximity, as people try to win favor with a particular leader and join an inner circle.

Qureshi is still a fan of the philosophy. With no "GM of this project" title, anyone leading an important effort holds the role because they are good at it, and can be replaced if they stop performing. In his words, you always had to earn the right to work on what you were working on.

Qureshi describes two kinds of Palantir engineer. Product-development engineers work on the core platform, while business-development engineers spend roughly Monday to Thursday at the customer's site, with a desk, a computer and a login. There are two flavors of forward-deployed engineer: the classic software engineer, and a more technically adjacent person hired for reasoning about data and for navigating the social dynamics of an executive room.

Rachitsky points out that this is customer contact "on steroids" compared with the occasional interview or Zoom. Qureshi worked this way at an Airbus factory and later at the NIH, where he held a badge and worked beside civil servants and clinicians. Deals were large, often many millions of dollars, and were priced on the value of the outcome rather than as data infrastructure, so the engineer's job was to solve the problem, not just deploy software.

That work can create new product. Qureshi's example is a colleague working with an energy company who learned how oil wells work and found that streaming data was valuable, which became a part of the core platform. He describes the weekly cadence as building something on Monday night, showing it on Tuesday, iterating that night, and repeating, for four or five loops a week. Do that in five different contexts and, he says, you become very good at the cycle founders need.

Early on, Qureshi says, people dismissed Palantir as a "sparkling Accenture", a consulting business pretending to be a product company. He points to the 80%-plus margins as evidence otherwise, since a consultancy would be closer to 20 or 30%, and notes that anyone can now sign up with a credit card for the current product, AIP.

The platform came out of the tools forward-deployed engineers built for themselves. Shyam Sankar mandated that every customer deployment have a customer using those tools within three months. The tools crashed and were built for "nerdy Silicon Valley engineers", but the pressure forced rigor on performance, reliability and usability over about three or four years, and Foundry emerged. Qureshi credits top-tier talent in product development and a hard-won understanding of how data really works in large organizations.

He describes the shared structure of Gotham and Foundry as a pyramid: data ingestion at the bottom, data mapping in the middle and user-facing applications on top. Gotham leans toward maps and graph analysis, such as tracing networks of people or detecting fraud. Foundry looks more like classic SQL queries and tables, which suits most B2B companies.

Airbus asked Palantir to help ramp up production of the A350 far faster than it ever had, with the mandate framed as an outcome rather than a software purchase. The plane moves through stations, and each station needs to know what work was done, what remains and which parts are needed. Much of this had depended on people talking to each other on the factory floor.

The data lived in SAP tables with names Qureshi compares to an alien language. The team pulled those tables in, joined them and mapped them to human concepts such as parts, work orders and aircraft, so a user could ask where Aircraft 79 is and what work is outstanding. He jokingly describes the result as something like Asana for a plane factory.

The application itself did not go into Foundry, but the idea of mapping raw tables onto human-legible concepts became the ontology, which Qureshi says is still a major differentiator. He recalls production rising at least fourfold in a year, and says Airbus's CEO credited Palantir with a critical part. He lived in France for about a year and a half and flew around Europe to track where components were. The company expected engineers to be ready to board a plane that night, and he says being in person builds trust that Zoom cannot.

Asked how far a startup should go with a forward-deployed model, Qureshi cites Hex CEO Barry McCardel's view that most companies probably do not need it. The model requires being willing to be wasteful and needs very large ticket sizes. One thesis alumni left with was serving customers too small for Palantir, charging perhaps 250K instead of 5 million, with one engineer covering about five accounts.

On whether to build for one customer, he says the more common mistake is being too anchored to your own product vision. If an enterprise customer cares less about your analytics software than about another large problem, it can be right to pivot toward that problem. He recalls Retool's David Hsu changing a subject line to "build internal tools easily" and suddenly getting replies from CTOs. He adds that strong founders treat a new opportunity as a blank slate.

Many companies now use the forward-deployed label, Qureshi says, but it means different things. Palantir's version had real engineers empowered to build entirely new product, not solutions architects deploying an existing one. The other ingredients were being in person, forming personal bonds and understanding the customer's business, such as seeing a hospital as a business that wants to turn over beds. With AI coding tools, he thinks the model gets cheaper and more viable.

Qureshi says Palantir tracked revenue per engineer as a measure of product leverage. If you need many engineers for every new problem, you are effectively a consultancy. Over time, the number of engineers per customer should fall from perhaps five to ten toward one person covering several customers. He says the job has shifted that way and that the bull case for the company is two decades of data foundations that now let it help customers deploy AI on proprietary data.

On why data was such a secret of success, he describes the typical corporate experience: you need sales data, discover you cannot access the database, file a ticket and wait six to eight weeks. When access arrives the data is hard to query correctly. Analysis, he says, is the tip of an iceberg, with the remaining 95% being getting access, cleaning, joining and normalizing.

Productizing each step created room for real product innovation: a universal data adapter that can read sources such as JDBC and S3 and preview rows, schedules that replace hand-managed cron jobs, and tools that let non-technical users join tables. Qureshi argues Palantir is an underrated source of product and UX ideas, though most never reached the public. He calls Foundry the best data platform in the world.

Qureshi says the data gatekeepers are not malicious. InfoSec teams reasonably want to prevent breaches, and locking data down is the easiest way. But he describes people whose job security depends on being the only person who can write the sales-calculation SQL, and who resist making that data point-and-click. For that reason he considers Palantir's biggest competitor to be a company building its own data infrastructure on top of a hyperscaler.

Qureshi's current company has six people, and he says hiring advice that sounds obvious becomes real once you live it. The hardest thing to find is someone who will go the extra 20% and pursue the real outcome rather than checking boxes. That matters enormously for the first 20 people, and he says there is no formula for finding them.

His method is to look for mission fit and a private reason to care. Palantir hired many veterans and patriotic people, and in his health-focused company he looks for people touched by illness such as cancer. He asks what the hardest thing they have worked on was and why. He also describes lateral signals such as former athletes in sales, and notes with some humor Max Levchin's story of PayPal rejecting a candidate who liked shooting hoops.

Qureshi says Palantir was anti-PM for a long time and only needed them when it got more serious about product testing. The company was extremely careful to make PMs only of people who had proven themselves as forward-deployed engineers. The woman who managed the Airbus factory deployment later became the PM for the ontology.

The reasoning is that such a person understands customers, has customer empathy and has the drive that business development selects for. The company wanted to avoid what Qureshi calls Google Docs syndrome, where a PM writes requirement documents and manages in a very rational manner. He knows of no case where a PM hired from a place like Google succeeded at Palantir. PMs also had to win the trust of their engineers quickly, or they did not last.

On the founder rate, Qureshi says that in a team of 20 to 25 people when he joined, at least six are now unicorn or near-unicorn founders. He also says retention was high, so those who left usually did so for something specific, such as founding a company, rather than to join a traditional tech firm. Rachitsky adds that there are more YC founders from Palantir than from Google, despite Google being a vastly larger company.

Rachitsky raises the objection that Palantir builds products that can contribute to killing people and works with governments some people dislike. Qureshi says there was a great deal of upside, including the US COVID response, Operation Warp Speed work he knew of, and his own cancer-research work at the NIH, none of which he thought could be done elsewhere. He was clear that he did not work on the defense side himself.

His broader point is that disengagement is rarely correct. He sees Google's withdrawal from a Pentagon AI project as going further left than the median American would, who he says would accept defense work within reason. He argues that being in the room can make processes more targeted and accurate than a decade earlier, and that engineers need to think actively about grey areas, while acknowledging the answer could change if the country became the bad guys.

Qureshi also criticizes tech's long refusal to view its work through a political lens, pointing to engineers optimizing short-form video engagement without considering effects on children. He says events like the war in Ukraine made the need for companies such as Anduril and SpaceX clear, and argues that deterrence against, for example, a Chinese invasion of Taiwan needs to be strong. He adds that this is not for everyone, and that turning some people off is part of how such companies attract talent.

The first habit is fast iteration: success rises with the number of bets, so test early and cycle quickly. He recommends taking something to a customer and asking for a lot of money straight away, instead of waiting three weeks as many founding teams do. If it does not work, find a new problem.

The second is a tight, distinctive team culture. At Palantir there was a feeling that if you worked there, you must be good, and Qureshi says working at such a place gives you internal benchmarks for what great looks like, so you know when something is off. Rachitsky reads this as advice to work at an amazing company first and build a network of such people.

The third is working on a messy part of the real world. Qureshi joked that he wanted to build pure software, but his advantage lies in his experience with messy sectors such as healthcare, and he worries those areas may still be broken even if AGI arrives. He believes large organizations are now more open to small startups than before the ChatGPT moment, and that the cost of forward-deployed work has fallen perhaps five to ten times.

In the AI Corner segment, Qureshi names Wispr Flow for speaking long prompts, Claude Code as a preview of AI agents operating directly on the file system, and Gemini 2.5 Pro, which he had been testing that week. He also used an LLM-written script to classify transactions for his taxes. Rachitsky notes how much Qureshi's enthusiasm contrasts with people who feel overwhelmed.

His contrarian view is that going to college is great and that dropping out suits only a small share of people. College is one of the few times to form deep friendships and think without paying rent. To stay current on AI he recommends X lists and technical newsletters like Latent Space, and points to chess, where top players who embraced neural-network engines early did best. He urges becoming a kind of cyborg while also touching grass.

In the lightning round he recommends Keith Johnstone's Impro, Shakespeare's Henriad and Andy Grove's High Output Management. His life motto comes from the architect Christopher Alexander, who told students to aim to make something better than the Gothic cathedral at Chartres. He also praises Anna Karenina for Tolstoy's ability to enter anyone's head, a skill he says product builders need.