Lessons from Palantir Alums About Building a Tech Company

Forward deployed, chaotic, and irreverent in achieving customer value.

Nov 13, 2024

When I joined Palantir in 2015, I didn’t think the company was that weird. It was my first real job, so I assumed Palantir was probably similar to other tech companies. It was only after I left that I realized how wrong I was. Palantir was fundamentally different from almost any tech company out there. That difference may be why it succeeded.

Recently, I attended a session where four Palantir alumni (plus one current Palantirian) discussed lessons learned from their time at Palantir. I had the privilege of working with all of them at one point or another [1].

The shared learnings from their time at Palantir were fascinating and reminded me of other observations I had while there and afterward. And while some specifics have changed, the overall paradigm there is much the same as it always has been.

I’ve done my best to synthesize everything below, focusing on how Palantir was different.

How Palantir worked with customers

Deals started at the top

Palantir had a very unique approach to sales. Commercial deals, in particular, came in one way – through an introduction from Karp or Karp’s team. Arda described this in more detail:

“If you’re trying to replicate Palantir, unless you’re at Bilderberg or at Davos in the early days, you literally won’t have the high-level executive connections you need to bring it off.”

This is pretty much the opposite of most enterprise deals in SaaS that I’ve seen. At Palantir, there was no serious outbound function. There were no AEs. The top-of-funnel sales motion was most similar to the techniques seen in high-level strategy consulting. (Note that much of this approach has changed since Palantir IPO’d - Palantir now has sales team members).

Once deals were “started” at the executive level, Palantir usually offered a “free pilot.” The free pilot would be a project politically sponsored by the customer's executive.

The pilot would start by flying to the customer's office with a small team of deltas and echos (Palantir internal terms for “forward deployed engineers” and “deployment strategists,” respectively) and working on 1) getting access to data, 2) integrating data together, and 3) visualizing the integrated data in a useful way for the organization.

Navigating customer bureaucracy

So, our intro was at the top of the org chart. Access to data usually required going to the middle of the org chart, where IT and other admins sit. Making something valuable to the customer usually meant going to the bottom of the org chart, where the individual contributors were “getting work done.”

Thus, Palantir was the perfect place to learn about navigating bureaucracy and internal politics in big companies. In one colorful example, Cobi talks about using deployment team members as “sacrificial lambs”:

“We decided to deploy a new product and email the entire agency that this product existed. And we tried to hide it from all of the leadership of that agency…And so we had to have a sacrificial lamb. It was all planned out. We had to have one person have their badge taken away, like “fake fired”. And sometimes real fired, but usually fake fired from an account, but that is the type of line we were willing to cross to accomplish the mission regardless of the product development or the end resources or types of engineering we were trying to do. It's just like, get the fucking mission done.”

Another common technique was colloquially called the sandwich, in which we would push from the top (via an executive) and up from the bottom (via the users) to get access to data and to unblock random processes/hoops that middle managers put in the way.

Navigating the internal hierarchy was as critical to success as building a great product because how the deployment ended in the final room often depended on the relationships built, an internal champion, and showing the best world view compared to the alternative.

Closing the pilot was critical and frantic.

From a product perspective, there was some infrastructure-level product support in the early days, but the FDE and analyst team would build anything that would solve the problem and help the end user. Everyone would be coding frantically and desperately to get something ready for a critical meeting towards the end of the pilot phase.

I remember many sleepless nights and often making changes to a critical dashboard minutes before the meeting started. The dashboard was usually the epitome of technical debt—with random Javascript and CSS holding it together or the demo flow only working for a certain type of question asked (but not for others). There was no such thing as having a polished product finished even days before the big presentation.

If the presentation at the meeting went well, the customer would “convert.” The presentation often demonstrated a concrete positive outcome.

The customer would pay some huge price (usually in the seven figures) to productionize what was built in the pilot and often added on other “use cases.” These different use cases would frequently be new pilots, and the cycle would repeat.

How Palantir worked internally

Chaotic, in a good way

Internally, I would describe Palantir as “chaotic”. There was never one correct way to do things. Interestingly, every single panelist tried to explain this as part of their two-word description of what made Palantir different: “irreverent,” “rogue,” “tell the boss to fuck off,” etc.

Palantir was explicitly structured to enable teams to solve customer problems while ignoring internal hierarchies or reporting structures. One-third of the company was in the “business development” part of the org, deploying with customers and building exactly what the end users needed. One-third of the company was in the “product development” part of the org, building core product capabilities that could be used across deployments. And the last third was in “internal development,” which housed the other parts of the company (HR, Legal, etc.).

While the “product development” org was structured as you’d expect, with PMs, software engineers, and scrum practices, interestingly, a large portion of its work was retrofitting/rewriting/cleaning up code that the BD org had built for one deployment or another.

As Akshay described it:

“The origins of the Gaia application were like this. It could not be cleanly extended from the existing geospatial capabilities in the platform, and there were so many reasons why it should not have been built. But people who were forward deployed at the edge saw users who needed this new type of software with a fundamentally different architecture and ended up building it.
And there was this pain point and religious struggle internally of, why is this separate? Why is it not on top of the existing code base? Why did it have to fork?…
But it was the right thing to do to take the ground with Gaia initially, and there are lots of examples of that, where there is some BD forward force that's pushing the product in some direction that some person back in Palo Alto or New York doesn't like.
The culture valorizes going rogue where you need to say, fuck you, and go build the thing that has to work to accomplish the goal.”

Gaia was eventually merged back in with the other defense offerings. Any team, or any team member, could decide to do something. And the question was never whether you had permission to do it. The question was if what you did had an impact on a user. If it did, you were celebrated. If it didn’t, you’d get shunted onto another project to try again.

Being forward deployed was like joining a SEAL team for software.

On the BD side, Palantir emulated a platoon-like structure. Each team had between 3 and 10 deltas and echos, and one person was designated as the “Commanding Officer" (CO). The commanding officer was ultimately responsible for the deployment's success, and success was the only goal.

The most memorable thing at Palantir was how hard people worked to achieve success. We would do anything to win. It’s one of the cultural practices I think is ultimately very difficult to replicate at other organizations. As Barry mentioned:

“I think that it's important to reflect back to the company's origin, and, like the fires it was forged in…We had to sue the Army to get the Army to buy the software [2]. And so there was this sort of insurgency that I think was often formed, which is like, we want to go, actually solve the freaking problem and the powers that be are often in the way.”

Joining the cult of Shyam

It’s hard to describe what it was like at Palantir in the 2010s. But one truly unique person there was Shyam Sankar, now CTO. I continue to think of Shyam as one of the greatest orators I’ve ever seen, on par with Barack Obama or MLK Jr. He could inspire at a high level and dig into low-level details about a project in a way few leaders could. He also had a degree of brutality when giving feedback, which made working with him exhilarating.

While I was there, outside of Palantir, no one really knew about Shyam. Now he’s somewhat famous. He recently spoke on Capitol Hill, and it’s worth watching to see how he abstracts out of problems and digs into the specific implications. You can tell that even the veteran politicians are impressed.

At least for me, Shyam was inspirational, not just in the specific case of pursuing Palantir’s mission but also in the sense that I continue to emulate his oratorical style and his way of approaching problems.

Transparency to a ridiculous degree

Palantir had a pretty sophisticated system for keeping track of everything that was going on, one that I haven’t seen replicated anywhere else. All email communication with the outside world had to BCC a mailing list with everyone on the team. All significant meetings with the customer were memorialized in a “meeting report” and also sent to a mailing list that had a very wide distribution - often the entire company on it.

While I won’t talk specifics, with this system, you faced two options: 1) drown in your email or 2) get good at setting up email filters and clearing your inbox. Getting Things Done became a commonly recommended book and eventually became part of the mandated reading for new hires.

The best part about this is that you could keep a running pulse of everything that happens at the company in real-time just by watching folders in your inbox. You can see the entire history of a pilot starting, a deployment progressing, how the final meeting went, how it converted, and who the key stakeholders internally were.

While other companies I’ve seen have attempted to replicate a similar system using Slack notifications, I have seen no place with the degree of internal visibility and, generally speaking, awareness of what was happening in every part of the company. It was stunning to see. It also meant that you could make your career just by doing a lot of work and sending meeting reports with your progress on customer engagements. Your work was being read by everyone.

Internal credibility was based on what you crushed on the edge

Unlike most companies, internal credibility was based on what you had accomplished/hacked together for a customer in a field-driven way. If you were on a pilot that converted, you usually returned to the mothership and explained all the broken stuff, and people took it seriously. As Akshay put it:

“I think this is actually quite different than a lot of cultures in B2B SaaS. If you are in the field, you have a title like sales engineer #1, or solution engineer #3, and you are clearly on a different rung of the ladder than the high priests who live in California or New York.
But at a place like Palantir, the question is: have you ever been in the field and seen what's fucked up, and what's wrong about the current thing? If you haven’t, you have no legitimacy. Everybody who has any title or authority, or fake whatever at Palantir came from the field and is coming back and saying, this is what I learned.”

This was a great gift for folks like me. I could “eat what I killed” - spend a few months working with an insurance customer, build a bunch of stuff, unlock value for them, then go to an oil and gas customer, build a bunch of things, unlock value for them, then go to a pharma customer, repeat ad nauseum.

My internal credibility was fairly high because the number of “notches in my belt” exceeded most. To be frank, that’s because I was single, did not mind traveling 100% of the time, could write code like a “delta,” could work with customers and write meeting reports like an “echo,” and could solve problems in a hacky way. Palantir specialized in supporting people like me.

Chaotic, in a bad way

On the other hand, it also meant that the internal organization was in constant flux. There was no such thing as a “leader of X” (despite us describing people that way to customers). Instead, the de facto “leader of X” was whoever owned the internal narrative after just coming back from the field and trying to build X for the customer. Palantir was not a place with a formal “progression” you were on. In fact, the executives at Palantir were against such things, as Arda described:

“A very negative word at Palantir that came from Peter and others is tracked. Tracked stands for people who are so used to someone laying out the next step for them. This is the next best thing that you can do in life, and you don’t have to think for yourself.
And maybe that's what is a good preparation for starting a company after Palantir, because there are no set rules. There is no known cycle to fit into and just execute.”

However, the absence of structure and track also meant that people got tired, at least after a few years. Certainly, I got tired after four years or so. I loved my time there, but I also didn’t date much, didn’t have any hobbies, and didn’t stay in the same country long enough to make very many friends.

It was hard to know exactly where you were going because every deployment was another months-long slog of trying to stitch together something in preparation for a critical meeting. Moreover, there was very little learning from deployment to deployment - it often felt like the company was unwilling to build structure and strategy holistically. Shreya describes this weakness:

“There's also the reason why some of us left, which is…you're kind of trying to attach yourself to some of these ideas. On the commercial side, we had no idea what we were doing. And the actual model while I was there was just like, try a bunch of shit, and just keep throwing shit at the wall.
And that is very fun when you're 22 or 23 years old, but at least I got to a point where I aged out of it, where I want some through line or something that I'm building towards, that is stacking on top of itself for at least a few years. I think that the organization kind of rejected any attempt to put that level of structure around it.”

Officially, Palantir was a “flat organization.” But realistically, it was constantly changing and remolding itself. There was certainly a hierarchy; it’s just that the hierarchy today was different from the one last week.

Palantir was flat in that a top leader would parachute in to make big changes if things were going very well or badly. If things were going well, we would increase the number of people on the project, bring in a good negotiator to double the size of the deal, etc. If things weren’t going well, we would change structure faster than almost any company I’ve ever seen. No middle management protected you, nor was there a process to slow things down or retain prior knowledge. There was no such thing as a “safe job.”

This chaos also applied to teams in PD. Sometimes two teams would build products that solved the same problem differently. At a key moment, we would decide which product should live and which should die, and the contributors on the other team would be refolded into other groups.

In some sense, a similar process happens at mature software companies during quarterly or yearly planning. But at Palantir, it could happen any day of the year. And in whatever new structure that came to be, a random engineer could go off and build something independently. A new team would be created to support them if it was good. So every team was constantly forming, reforming, changing, and shifting.

It was a world of constant, sometimes nauseating, flux. More than one “experienced engineering manager” failed after joining Palantir, as Akshay said:

“It's like some people come in and want a structure that we don't provide, and want a level of hierarchy that Palantir is not going to make legible to them all the time, because it values this fluidity. It values this kind of field-facing presence, and I think there are lots of talented people, especially in Silicon Valley or at large, that just work better in different constructs. And I think that's what stands out to me, there's some people who just want a lot more explicit structure.”

Lessons after leaving Palantir

First principles vs state of the art

While I was at Palantir, one remarkable thing was that pretty much everything was invented from scratch or taken directly from customers (who weren’t in the tech sector at all). Our deployments and codenames were all inspired by our first military clients, for example. The vast majority of roles internally were filled with people whose first job out of college or grad school was Palantir. Every role was uniquely created the “Palantir way.” It was a recipe for genuine innovation or flailing around in the dark. As Cobi put it:

“At Palantir. We tried to 1st principle everything, but to an absurd degree, including sales for a very long time. So there was always this sort of dogmatic view of ‘we don't have a sales team because sales teams don't work, and you can do it’. There was always this really really strong push against having a true sales team.
At Chapter we went through a bunch of journeys of what that means, and we're not a SaaS company, so it's a little different. But there are people who are really good at selling stuff, and that's a very valuable skill. And at Palantir it was viewed as a negative.”

Similarly, Shreya described joining a company as a product manager after Palantir and discovering that the role was really quite different:

“In BD, we didn't really have product managers, meaning you didn't have the practice of product management. You just had engineers building shit. And then you had people like me who were running around trying to get access to data or users. And I guess in some ways you could call that the equivalent of product management. But it didn't feel like that, because engineers were actually making a ton of the decisions about what to be built.
And then I left, and I got a job at a normal company and I was on the product team. And they told me to write a PRD and write user stories. And I was like, ‘I have no fucking idea what this is’.
At least the part of the org that I was in at Palantir carried a lot of disdain for product managers. They thought that it was disempowering for engineers to be told what to build versus seeing the raw data firsthand of what the user is doing, and then using that to draw their own conclusions about what to build.”

I had a similar experience when moving from Palantir to Benchling. What’s interesting to me is that, in some ways, the “standard” way of building products in tech is deeply inefficient—it was not uncommon for an entire Palantir deployment to start, land onsite, get data, and build an end-to-end software tool in days.

From how Palantir describes its boot camp structure (after my time), it sounds like they’ve cut the time down to hours.

Meanwhile, at most software companies, you’d be lucky to have a description of the problem in a document shared with the design team in the same time span. Finalizing a PRD at Benchling often took months. And building the product, at least at Benchling in recent times, never took less than a quarter.

And yet, Palantir didn’t figure out how to take that rapid, consulting-style development motion and turn it into a SaaS for over a decade. There are plenty of sales (and PM) people at Palantir now. When should you innovate on an approach vs not innovate? The Palantir case is both evidence you should innovate and evidence that perhaps you shouldn’t. Barry put this another way:

“You're already trying to perform one miracle, which is, you're trying to build a new product that will have PMF. Hundreds or thousands of other companies who are trying to do effectively the same thing, haven't.

And so you just have to be careful of where you're going to try to reinvent the wheel. And so, we have salespeople and they're great. We've got sales engineers. They're great. We pay them. They do deals. We build 0 custom shit. We have no forward deployed engineering. We just sell SaaS, like, here's a license. Do you want to buy it? Great!
It's a nice business model. And it's equally valid to the Palantir forward deployed engineering model. It just depends on what kind of adventure you want to have.”

On hiring

Palantir had an amazing ability to hire really, really smart people and pay them very little. When I was an undergrad at Stanford, Palantir was famous for rejecting the best computer science grads (including those like me who taught computer science to other undergrads). Palantir had the hardest technical problems in the interview—harder than Google or Facebook. Undergrads wanted to go to Palantir because it was this shadowy, secretive company that was really, really hard to get into.

Palantir also leveraged its ability to hire the unfashionable—the pro-defense people, the smart grad students who dropped out of their PhD, and the Air Force officers who gave up on rising through the ranks.

But most of all, Palantir placed a huge premium on people referring their smartest friends. Palantir’s referral bonus was absurdly high for a couple of years (much more than even today’s referral fees at most companies). Akshay describes the tactic in more detail:

“I think the reason why this Stanford and MIT thing became more of a meme with the 0.1% was because it was the firsthand network effects of people that just knew each other. So it's like, Hey, Bobby knows Rob. He knows Liz, and they all came over because they vouch for each other, and they kind of understand the weird culture that this person would be coming into. So it became this very like point to point way of doing recruiting, that actually looked a lot more mechanistic from the outside than it felt on the inside.”

Palantir’s hiring bar was so high that, in some ways, it’s the foundation of the company I’m running now. Many other companies are trying (so far unsuccessfully) to mimic the recruiting advantages that Palantir once had.

On when you should start a company

Palantir alums have gone on to start a ton of companies. The most remarkable thing to me is that each company seems mission-driven, as much of a Frodo-like journey, as we perceived our deployments internally at Palantir. Cobi described his thought process:

“My personal view is you should not start a company for the sake of starting a company.
Different people disagree with me on that. But I started Chapter after seeing my parents struggle with the Medicare process. They got screwed by working with a local Medicare broker who didn't have good data or good tools. And there's a lot of incentive misalignment issues. And I just think our elders broadly deserve much better. And we, as a society, don't build really any good product for our seniors.”

Similarly, Barry talked about founders “playing house,” who start companies because they’ve romanticized the idea of being a founder instead of building something that resonates with them personally:

“I know so many whiteboard founders who are like, ‘I wrote 10 ideas on the board, and we circled this one’. And I think people try to talk themselves into having passion about something, and I know 2 founders in particular who did this, and then they were fucking trapped because it was going well enough that they couldn't walk away. But it wasn't going well enough that they wanted to stay. If you're smart, it's reasonably easy to find yourself in that kind of bad local maximum.
So you have to really care about what you're doing. I didn’t want to be a founder. I actually started this as a buyer, not a builder. I was an employee, and I was like, certainly someone's built this, and they hadn't, and it took a while for my co-founders and I to be like, maybe we should be the ones to do it.”

Shreya echoed the same sentiment and talked about the value of having a community of people to build you up and a separate community who will keep you down-to-earth and let you approach ideas that are outside the current zeitgeist:

“If you're in SPC, or you're thinking about joining SPC: the great thing about it is, you have access to a community of people where there are going to be a lot of builders. And you do need that community to give enough life to crazy ideas and tell you, and where you can say something that sounds ridiculous and have people around you not laugh at that.

But you also need people around you who will laugh at that…The second one will give you access to ideas and concepts and ways of thinking that are outside of whatever the flavor of the week is in Silicon Valley, and that's probably where some of the most interesting ideas are going to come from.”

The ex-Palantir community

This event was hosted at the South Park Commons office in NYC, and the remarkable thing was how many other Palantir alums were in the room. The ex-Palantir community Slack continues to have daily posts, and the community is very close. There is a long list of favors traded, investing in new companies from alumni, and shared knowledge and expertise.

In many ways, the most enduring aspect of the Palantir experience is the community that lingers long after you’ve left. Arda captures this well when he reflects on the unique culture of the company during its formative years:

“I feel like there are also companies, and maybe eras of companies and styles of companies that are good to be an employee of. And then there are companies that are good to be a stockholder of. I feel like companies evolve through this life cycle.
I worked at larger companies that I really looked up to before Palantir. I thought they'd be the pinnacle of everything being great for the employee. It wasn’t. When the company has figured out everything, you might be doing things, but they're not your ideas anymore.
Early on, Palantir was the opposite. You would not have wanted to be a stockholder of it, but it was the best training for a lot of things. It was all the right kinds of pain to get you used to real life pain [3].”

This tension between early struggle and eventual success is common to many companies that begin with a bold vision and face significant uncertainty. The journey of ex-Palantirians mirrors that of their predecessors, the “PayPal Mafia,”…a group of people who, having weathered difficult challenges, go on to build new ventures and tackle fresh problems, carrying with them invaluable lessons learned from their past.

Watching Palantir’s evolution, there’s a quiet pride in seeing how the company has transformed. Success isn’t just about stock prices—it’s about the bonds forged during times of uncertainty and the knowledge that the hard work and the pain were worth it.

Ultimately, the most lasting impact of the Palantir experience may not be what happens to the company but what happens to the people who were part of it. The journey, not the destination, is what shapes us.

Thanks to Shreya Murthy, Cobi Blumenfeld-Gantz, Akshay Krishnaswamy, Barry McCardel, Arda Kara, Aditya Agarwal, and Sasha Spivak for the splendid session, lessons learned, and for suggesting changes to this post. Thanks to Nabeel Qureshi, Apoorv Agarwal, Cobi Blumenfeld-Gantz, and Barry McCardel, who wrote similar posts recently that inspired this one [4].

[1] Shreya was my “enterprise lead” when I was a “commanding officer” (I reported to her). Barry was my “people lead” (I reported to him too). Cobi and I collaborated on healthcare work, especially workflows moving from government to commercial and vice versa. Akshay and Arda were both technical experts that I would regularly consult. I’m glad to call all of them friends today.

[2] Barry refers to a case in 2016 when Palantir sued the US Army so that its software could be considered for a large military contract. Palantir won the lawsuit and won at least a portion of the contract a few years later.

[3] If you want to hire people who’ve had this sort of training and can endure the pain of building 0 → 1, I’m building a product to help you find, engage, and hire them part-time. You can read more about that here.

[4] Nabeel’s post here: