Palantir's Reflection: The Journey from Controversy to Recognition

Compiled from: Reflections on Palantir (by Nabeel S. Qureshi)

Palantir recently joined the S&P 500, its stock price has soared, and its market cap is approaching $100 billion, attracting the investment interest of venture capitalists. In the past, Palantir was controversial due to its association with spy technology and NSA surveillance; the company had a poor image and was even questioned on moral grounds. The author worked at Palantir for eight years, and after leaving, decided to share his experiences and understanding of the company, because there are many misconceptions about Palantir in the outside world.

1. 加入的原因

I joined the company in the summer of 2015, initially at the newly opened London office, later moving to Silicon Valley, and finally to Washington, D.C. — as a forward deployed engineer. For context, the company had about 1,500 people at the time; it had offices in Palo Alto (headquarters), New York, London, and a few other places. (The company now has about 4,000 people, with headquarters in Denver.)

Why join?

First, I wanted to work in "hard" industries and solve genuinely meaningful problems. For personal reasons, the fields I was interested in were healthcare and biotechnology, and the company was just getting started in these areas. The company talked about working in healthcare, aerospace, manufacturing, cybersecurity, and other industries I considered very important, but at the time most people weren't working in those industries. What was hot then was social networks (Facebook, LinkedIn, Quora, etc.) and various consumer apps (Dropbox, Uber, Airbnb), but few companies were tackling the truly hard parts of the economy. If you wanted to work in these "harder" sectors of the economy while also having Silicon Valley work culture, Palantir was at one point almost your only option.

My goal was to start a company, but I wanted to (1) first work deeply in an industry for a while and truly understand it; and (2) work for an American company and obtain a green card that way. Palantir offered both. This made the choice easy.

Second, talent density. I spoke with some of the early people working in the healthcare business and was deeply impressed. Afterwards, I spoke with some of the early business operations and strategy people and was even more impressed. These people were extremely focused, fiercely competitive, hungry to win, true believers; they were quirky, fascinating, read philosophy books in their spare time, tried strange diets, and rode 100 miles for fun. It turned out this was inherited from the PayPal Mafia. Yishan Wong, an early member of PayPal, wrote about the importance of intensity:

Overall, as I began to research more startups, I found that PayPal's level of talent was not unusual among Silicon Valley startups, but the differentiating factor was probably the intensity from the top: Peter Thiel and Max Levchin were both very intense people — extremely competitive, hardworking, and unwilling to accept failure. I believe this kind of leadership was what drove a "standard" talent team to accomplish great things, and subsequently, enabled the steady stream of later achievements.

Palantir was a very peculiar place. I remember the first time I spoke with Stephen Cohen, the air conditioning in his office was set to 60 degrees, there were several oddly shaped devices to reduce the carbon dioxide content in the room, and a large cup filled with ice. Throughout the conversation, he kept chewing on ice cubes. (It's said this is good for cognition.)

I also spoke with CEO Alex Karp and talked with other members of the leadership team. I probably don't need to convince you that Karp is quirky — just watch one of his interviews. I can't say what Karp and I talked about, but an interview he gave in 2012 captures his style well:

I like to meet candidates without any data: no resume, no prior discussion or job description, just the candidate and me in a room. I'll ask a fairly random question, one that has nothing to do with anything they might do at Palantir. Then I observe how they break down the problem, whether they realize there can be many different ways of looking at the same thing. I like to keep the interview short, about 10 minutes. Otherwise, people slip into the answering patterns they've learned, and you can't really get to know who they are.

My interviews are often unrelated to the job or software — in one interview, we spent an hour discussing Wittgenstein. Note that Peter Thiel and Alex Karp are both philosophy graduates. Thiel's lecture notes (CS183: Startup - Peter Thiel Class Notes) were made public a while ago, and they discussed Shakespeare, Tolstoy, Girard (then little known, now a cliché), and more.

This intellectual grandeur combined with fierce competitiveness was a perfect fit for me. In fact, it's still hard to find today — many have imitated the "hardcore" work culture and the "this is the Marines" atmosphere, but few possess the intellectual atmosphere, that feeling of engaging with rich ideas. This is hard to imitate — your founders and early employees must be genuinely interesting intellectual thinkers. The main companies that come to mind today that do this well are OpenAI and Anthropic. It's no surprise that these companies attract enormous amounts of talent.

2. 前线部署（Forward deployed）

When I joined, Palantir was divided into two classes of engineers:

1. Engineers who worked with customers, sometimes called FDEs, i.e., forward deployed engineers.

2. Engineers who worked on the core product teams (Product Development - PD), who rarely visited customers.

FDEs were generally expected to "go on-site" to customers' offices, 3-4 days a week, which meant frequent travel. This was very unusual for a Silicon Valley company.

There is a lot worth discussing about this model, but the core idea is that you would gain a deep understanding of the business processes of challenging industries (manufacturing, healthcare, intelligence, aerospace, etc.), and then use that knowledge to design software that actually solves problems. The job of PD engineers was to turn the frontline engineers' custom solutions into standardized products, so that these products could be applied more broadly and improve the productivity of the entire company.

This is how the Foundry product originally took shape: FDEs went to customer sites and had to manually do a lot of tedious work, and PD engineers built tools to automate that tedious work. Need to import data from SAP or AWS? Here's Magritte (a data import tool). Need to visualize data? Here's Contour (a point-and-click visualization tool). Need to quickly spin up a web app? Here's Workshop (a Retool-like UI for building web apps). Eventually, around the loose theme of "integrate data and make it useful somehow," you had a truly excellent toolset.

At the time, letting customers use these tools was seen as a radical step — they weren't ready — but now this drives more than 50% of the company's revenue, and it's called Foundry. Viewed from this angle, Palantir accomplished a rare services company → product company transformation: in 2016, describing it as a Silicon Valley services company wasn't entirely absurd, but in 2024, that description is completely absurd, because the company successfully leveraged the experience of those early years to build an enterprise data platform, which shows up in gross margin — 80% gross margin in 2023. Those are software gross margins. By comparison, Accenture's gross margin is 32%.

Tyler Cowen has a brilliant line, "context is that which is scarce," and you could call this the model's fundamental insight. Going to the customer site in person—startup guru Steve Blank calls this "getting out of the building"—means you can capture the tacit knowledge of how they actually work, rather than just the "requirements checklist" model that enterprise software typically relies on. The company believed in this deeply: phone calls would come in, and we'd have to book flights for the next morning to some very random place; "get on the plane first, ask questions later" was a cultural bias. This led to uncontrollable travel expenses for a while—many of us ended up with United Airlines 1K status or the like—but it also meant an intense decade-long learning cycle that ultimately paid off.

My first real customer engagement was with the French aircraft manufacturer Airbus. I moved to Toulouse for a year and worked four days a week at the factory with the manufacturing staff, helping to build a version of our software there.

The CEO told us his biggest problem was scaling up manufacturing of the A350 aircraft. So we ended up building software to address that problem directly. I've sometimes described it as "Asana for building airplanes." You bring together different data sources—work orders, missing parts, quality issues ("non-conformances")—into one nice interface where users can check off work, see what other teams are doing, where parts are, what the schedule is, and so on. It lets them search (including fuzzy/semantic search) through previous quality issues and see how those issues were resolved. These are basic software features, but you've also seen how bad enterprise software can be—simply deploying these "best practice" UIs into the real world is extremely powerful. This ultimately helped drive the surge in A350 manufacturing, successfully increasing the manufacturing rate by 4x while maintaining Airbus's high quality standards.

This makes the software hard to describe concisely—it's not just a database or a spreadsheet; it's an end-to-end solution for that specific problem, with less concern for generality. Your job is to solve the problem, not to worry about overfitting; PD's job is to take whatever you built and generalize it, with the goal of selling it elsewhere.

FDEs tend to write code that gets the job done quickly, which often means—politely speaking—technical debt and hacky workarounds. PD engineers write software that scales cleanly, works for multiple use cases, and doesn't crash. A key "secret" of the company is that creating deep, lasting enterprise value requires both. BD (business development) engineers typically have high tolerance, and need the social and political savvy to embed deeply in an unfamiliar company and win the customer's trust, plus high efficiency—you need to quickly build something valuable so the customer realizes you're the real deal. Customers' expectations for most software contractors are extremely low; they're usually implementers of SAP or similar software working on multi-year "waterfall" timelines. So when a ragtag team of twenty-somethings shows up on-site and builds real, usable software within a week or two, people notice.

This two-pronged model forms a powerful engine. Customer teams are usually small (4-5 people) and operate quickly and autonomously; there are many of them, all learning fast, and the core product team's job is to leverage those learnings to build the main platform.

This model tends to work well when we're allowed to work within an organization. The obstacles are mostly political. Whenever you see the government giving Deloitte another $110 million contract to build a website that doesn't work, or disasters like http://healthcare.gov, or the San Francisco Unified School District spending $40 million on a payroll system that doesn't quite work, what you're seeing is politics triumphing over substance. The SpaceX-versus-NASA contrast is another example.

The world needs more companies like SpaceX and Palantir, ones that differentiate themselves through execution—delivering results—rather than playing political games or building narrow point solutions that fall short.

3. 秘密

Another key thing FDEs do is data integration, a term that puts most people to sleep. This was (and still is) the company's core business, and for years its importance was underestimated by most observers. In fact, it wasn't until the advent of AI that people began to appreciate how important it is for enterprises to have clean, curated, easily accessible data.

Simply put, "data integration" means: (a) obtaining enterprise data, which usually means negotiating with the "data owners" in the organization; (b) cleaning the data, and sometimes transforming it, to make it usable; (c) putting it somewhere everyone can access. Much of the foundational software in Palantir's main software platform (Foundry) consists simply of tools to make this task easier and faster.

Why is data integration so hard? Data often exists in formats that aren't easily analyzable by computers—PDF files, notebooks, Excel files, and so on. But often what really blocks us is organizational politics: a team or group controls a critical data source, and their reason for existing is that they hold the keys to that data source; they typically justify their existence in the company by acting as gatekeepers of that data source (and, often, by providing analysis of that data). This politics can be a difficult obstacle to overcome, and in some cases it led to laughable outcomes—you'd see a company purchase an 8–12 week pilot, and we would spend the entire 8–12 weeks just trying to get data access, scrambling to prepare the demo in the final week.

Another "secret" discovered early on at Palantir was that the fight over data access stems partly from genuine data security concerns, which can be mitigated by building security controls into the platform's data integration layer—at all levels. This means role-based access controls, row-level policies, security markings, audit trails, and many other data security features that other companies are still catching up on. Because of these features, implementing Palantir typically makes a company's data more secure, not less.

4. 关于文化的注释

The company as a whole feels more like a messianic cult than a normal software company. But importantly, criticism appeared to be highly tolerated and welcomed—someone showed me an email in which a junior software engineer engaged in a public and contentious argument with a company director, with the whole company (about a thousand people) cc'd. As a philosophy graduate with a rationalist mindset, this mattered a lot to me—I had no interest in joining an uncritical cult. But a group of skeptics who cared deeply and wanted to argue about where the world was heading and how software fit into it—in an existential sense—that was interesting to me.

I'm not sure they still do this, but when you joined, they would give you a copy of Impro, The Looming Tower, Interviewing Users, and Getting Things Done. I also received an early PDF version of what later became Ray Dalio's Principles. This set the tone. The Looming Tower is obvious—the company was founded partly as a response to 9/11 and what Peter saw as the inevitable civil liberties infringements that followed, and that context is valuable. But why Impro?

Being a successful FDE requires an unusual sensitivity to social situations—what you really need to do is collaborate at the highest level with your counterparts at the company (or government) and win their trust, which often requires playing political games. Improv is popular among nerds partly because it mechanically breaks down social behavior. The company's vocabulary is full of improv terminology—"casting" is one example. Johnstone discusses how the same actor can play a "high status" or "low status" role simply by changing part of their physical behavior—for example, keeping your head still while talking is high status, while frequently shaking your head from side to side is low status. Standing upright with hands visible is high status; slouching with hands in your pockets is low status. And so on. If you don't know all of this, your odds of succeeding in a customer environment aren't great. Which means you're unlikely to integrate the customer's data or get people to use your software. Which means failure.

This is one reason why former FDEs often make excellent founders. (Even though Google has roughly 50 times as many employees as Palantir, in every YC batch, former Palantir employees usually outnumber former Google employees.) Great founders have an intuition for reading the room, group dynamics, and power. This point often goes unmentioned, but it's crucial: building a successful company is participating in negotiation after negotiation and ultimately winning on aggregate. Recruiting, sales, and fundraising are all essentially negotiations. Without these intuitions about human behavior, it's hard to excel at negotiation. This is something Palantir taught its FDEs, and it's hard to learn anywhere else in Silicon Valley.

Another is that FDEs must be good at understanding things. Your effectiveness is directly proportional to how quickly you learn the customer's language and develop a deep understanding of how their business operates. If you're working with a hospital, you quickly learn to talk about capacity management and patient throughput, rather than just saying "helping you improve your healthcare." The same goes for drug discovery, health insurance, informatics, cancer immunotherapy, and so on; they all have specialized vocabularies, and those who do well tend to be good at learning these vocabularies quickly.

One of my favorite insights from Tyler Cowen's book *Talent* is that the most talented people tend to develop their own vocabulary and memes, which become entry points into the entire intellectual world that person has built. Tyler himself is of course a great example of this. Any MR reader can immediately name more than ten Tylerisms — "model this," "the environment is what's scarce," "solve for the equilibrium," "the Great Stagnation" are all examples. You can find others who are good at this. Thiel is one. Elon is too ("multiplanetary species," "the light of consciousness," etc. are all memes). Trump, Yudkowsky, gwern, SSC, Paul Graham — they all frequently coin memes. It turns out this is a good indicator of influence.

The same insight applies to companies, and Palantir has its own vast set of jargon, some of it so obscure that "what is Palantir actually doing?" became a meme on the internet. "Ontology" is an old term, but there's also "impl," "artist's colony," "composite," "Room 36," "points," "metabolic pain," "gamma radiation," and more. The point isn't to explain all these terms, each of which compresses a whole set of rich insights; rather, it's that when you're looking for a company to join, it's not a bad idea to look for one with a rich internal language or vocabulary that helps you think about problems in more interesting ways.

When people hear the name Palantir, most think of Peter Thiel. But many of these terms actually came from early employees, especially Shyam Sankar, the company's current president. Nevertheless, Peter's influence on the company culture remains profound, even though during my time there he wasn't involved in running the company. This document written by Joe Lonsdale (*Lessons from Peter Thiel*), originally an internal document that was made public at some point, shows the kind of cultural principles the company had.

One point I attribute to Peter is not giving people titles. When I was there, almost everyone had the title "forward deployed engineer," and beyond that there were five or six supervisors and the CEO. Occasionally someone would come up with a different title (someone I knew called himself "Head of Special Situations," which I found amusing), but these titles never really caught on. This traces easily back to Peter's Girardian beliefs: if you create titles, people start to covet them, which ultimately creates competitive politics within the company and undermines internal cohesion. It's better to give everyone the same title and let them focus on the mission.

There are many criticisms of the "flat management" stance — *The Tyranny of Structurelessness* is a good example — and it seems to have fallen out of fashion in modern startups, where you quickly see CEOs, COOs, VPs, founding engineers, and so on. But in my experience, this style of management worked well at Palantir. Some people were more influential than others, but that influence was usually based on impressive accomplishments, and above all, no one could tell anyone else what to do. So if someone had influence or thought your idea was stupid, it didn't matter — you could ignore them and do what you believed was right. Beyond that, the culture celebrated people with stories about engineers who ignored a supervisor and built something that ultimately became critical infrastructure, which was held up as a role model to emulate.

The price the company paid for this was that it often felt like there was a lack of clear strategy or direction — more like a bunch of smart people building their own little fiefdoms in a petri dish and then evolving at will. But its creativity was astonishing. People underestimate how many novel UI concepts and ideas this company produced. Only some of these now have non-Palantir equivalents — for example, Hex, Retool, and Airflow all contain parts originally developed at Palantir. Now the company is doing the same thing in AI — its tools for deploying large language models at large enterprises are very powerful.

The "no titles" approach also meant that people's popularity within the company could change quickly. Because everyone had the same title, you had to measure influence in other ways, like "who is currently close to this director" or "who is leading this seemingly important product project," rather than "this person is the VP of such-and-such division." The result was a large-scale hero-and-asshole rollercoaster — someone would be very influential for a while, then mysteriously disappear, not working on anything visible for months, and you could never quite figure out what happened.

5. 蝙蝠信号

Another idea I can trace back to Peter is the talent signal. Recruiting great talent is hard, and you need a differentiated source of talent. If you're just competing with Facebook/Google every year for the same batch of Stanford CS graduates, you will fail. This means you need (a) a pool of talent that is particularly interested in joining your company over others, and (b) a way to reach them at scale. Palantir had several differentiated recruiting sources.

First, at the time there were many people who supported defense/intelligence work, which was unpopular back then, which meant there were more than usual smart engineers from, say, the Midwest or red states, as well as many smart former military and former CIA/NSA personnel who wanted to serve their country while also seeing the appeal of working at a Silicon Valley company. On my first day at the company, I attended my team's internal onboarding, and there was another person there who looked slightly older than me. I asked him what he did before coming to Palantir. He looked at me deadpan and said: "I worked at the Agency for 15 years." Then I was introduced to my first lead, who had been a SWAT officer in Ohio (!) and a veteran.

There were many people like this, many extremely talented, and most of them hadn't joined Google. Palantir was the only real "beacon" for this type of person — a company that openly supported the military, patriotism, and so on, which was very uncool at the time. This created a highly effective, differentiated signal. (Now there's Anduril, along with a large number of defense and manufacturing startups.)

Second, you had to be a bit quirky to want to join this company, at least after the initial hype faded (especially during the Trump administration, when the company became a lightning rod). Part of this was because this kind of aggressive "mission-focused" branding wasn't common at the time, and the company was also unapologetic about the fact that employees worked long hours, were paid below market rates, and frequently had to travel. Meanwhile, we were kicked out of Silicon Valley career fairs for working with the government. All of this filtered for a particular type of person: someone who could think independently and wouldn't be overly swayed by negative press.

6. Ethics

Ethics is a fascinating topic. This company unapologetically supports the West, and even though I disagree with some of the things the military does, I have no problem supporting the company helping the military.

But doesn't the military sometimes do bad things? Of course — I opposed the Iraq War. This gets to the heart of the matter: working at the company is neither entirely morally good — because sometimes we may be helping institutions whose goals I disagree with — nor entirely bad: governments do a lot of good, and helping them do things more efficiently by providing decent software is a noble thing to do. One way to clarify this is to break down a company's work into three categories — these categories aren't perfect:

• Morally neutral. Ordinary corporate work, like FedEx, CVS, financial companies, tech companies, etc. Some people might object to this, but overall people feel good about these things.
• Clearly good. For example, working with the CDC to fight a pandemic; working with the National Center for Missing and Exploited Children to combat child pornography; and so on. Most people would agree these are worthwhile things to work on.
• Gray areas. I mean "work involving morally thorny, difficult decisions": for example, this includes health insurance, immigration enforcement, oil companies, the military, intelligence agencies, police/crime, etc.

Every engineer faces a choice: you can work on something like Google Search or the Facebook News Feed, which are all slightly better things and basically fall into the first category. Or you can go work on things in the second category, like GiveDirectly or OpenPhilanthropy.

The key accusation against Palantir seems to be "you shouldn't work on things in the third category, because sometimes it involves making morally wrong decisions." One example is immigration enforcement during 2016–2020, which many people felt uncomfortable about.

But in my view, completely ignoring the third category and disengaging from it is equally an abdication of responsibility. Institutions in the third category need to exist. America is defended by people with guns. Police must carry out the task of fighting crime, and — in my experience — even people who are morally uncomfortable with certain aspects of policing will quickly call the police if their own home is burglarized. Oil companies must provide energy. Health insurance companies must constantly make difficult decisions. Yes, all of these things have unpleasant aspects. But should we completely disengage from these institutions and leave them to figure things out on their own?

I don't think there's a clear answer to whether one should work with customers in all three categories; it needs to be evaluated case by case. Palantir's answer is "we will work with most third-category organizations, unless they are clearly bad, and steer them in a better direction over time." So:

• On the ICE issue, they decoupled from ERO (Enforcement and Removal Operations) during the Trump era, while continuing to work with HSI (Homeland Security Investigations).
• They work with most other third-category organizations, on the grounds that these organizations are mostly doing good in the world, even though it's also easy to point out the bad things they do. I can't be specific, but Palantir software has partially prevented multiple terrorist attacks. I think this fact alone is enough to justify this position.

For many people, this is an uncomfortable position, precisely because you can't guarantee that you're always doing 100% good. To some extent, you're at the mercy of history, and you're betting that (a) you'll do more good than harm, and (b) being in the room is better than not being in it.

That's good enough for me. Others would rather go elsewhere.

Of course, the danger of this position is that it becomes a fully generic argument for doing anything the power structure wants to do. You're just amplifying existing processes. That's where "case by case" comes in: there's no universal answer; you have to evaluate each specific issue on its own merits. As for me, I spent most of my time there working in healthcare and biology, and I'm satisfied with my contributions. I'd bet the people who prevented terrorist attacks are also satisfied with their contributions. Or the people who distributed medicine during the pandemic.

Even though the tide has turned and it's now fashionable to study these "thorny" areas, these questions remain relevant for technologists. AI is a great example — many people feel uneasy about some of the consequences of deploying AI. Maybe AI will be used for hacking; maybe deepfake technology will make the world worse in various ways; maybe it will cause job losses. But AI also has major benefits.

Just like Palantir, working on AI research may not be 100% morally right, nor 100% evil. Not engaging with it — or calling for a pause/stop, which is just a fantasy — is unlikely to be the optimal position. Even if you don't work at OpenAI or Anthropic, if you're someone who might work on AI-related issues, you probably want to be involved in some way. Some cases are simple: building evals, working on alignment, improving societal resilience. But my point here is that gray areas are also worth engaging with: working on government AI policy. Deploying AI into fields like healthcare. Of course, this will be difficult. Even so, press forward.

When I think about the most influential people in AI today, almost all of them are in the room — whether at AI labs, in government, or at an influential think tank. I'd rather be one of them than one of the armchair critics. Of course, this will involve difficult decisions. But even if you later have to leave and sound the alarm, it's still better to have been in the room when things happened.

7. 接下来是什么？

Am I still bullish on the company? The huge productivity gains of this AI cycle will come when AI starts providing leverage for the large companies and enterprises of this era — in manufacturing, defense, logistics, healthcare, and other industries. Palantir has spent a decade working with these companies. AI agents will eventually drive many core business workflows, and these agents will depend on read and write access to critical business data. Spending a decade integrating enterprise data is a key foundation for deploying AI into enterprises. This opportunity is enormous.

Disclaimer: This article is from Nov and is copyrighted by the author. The content of the article represents the author's independent views only and does not represent the position of SecNews. It is reproduced for the purpose of conveying more information. For infringement issues, please contact anquanneican@163.com.