This is one reason why former FDEs tend to be great founders. (There are usually more ex-Palantir founders than there are ex-Googlers in each YC batch, despite there being ~50x more Google employees.) Good founders have an instinct for reading rooms, group dynamics, and power. This isn’t usually talked about, but it’s critical: founding a... See more

Being a successful FDE required an unusual sensitivity to social context – what you really had to do was partner with your corporate (or government) counterparts at the highest level and gain their trust, which often required playing political games. Impro is popular with nerds partly because it breaks down social behavior mechanistically. The... See more

I’m not sure if they still do this, but at the time when you joined they sent you a copy of

Impro

,

The Looming Tower

(9/11 book),

Interviewing Users

, and

Getting Things Done

. I also got an early PDF version of what became Ray Dalio’s

Principles

. This set the tone. The Looming Tower was obvious enough – the company was founded partly as a response to... See more

The overall ‘vibe’ of the company was more of a messianic cult than a normal software company. But importantly, it seemed that criticism was highly tolerated and welcomed – one person showed me an email chain where an entry-level software engineer was having an open, contentious argument with a Director of the company with the entire company... See more

Another key thing FDEs did was data integration, a term that puts most people to sleep. This was (and still is) the core of what the company does, and its importance was underrated by most observers for years. In fact, it’s only now with the advent of AI that people are starting to realize the importance of having clean, curated, easy-to-access... See more

FDEs tend to write code that gets the job done fast, which usually means – politely – technical debt and hacky workarounds. PD engineers write software that scales cleanly, works for multiple use cases, and doesn’t break. One of the key ‘secrets’ of the company is that generating deep, sustaining enterprise value requires both. BD engineers tend to... See more

The CEO told us his biggest problem was scaling up A350 manufacturing. So we ended up building software to

directly tackle that problem

. I sometimes describe it as “Asana, but for building planes”. You took disparate sources of data — work orders, missing parts, quality issues (“non-conformities”) — and put them in a nice interface, with the... See more

This made the software hard to describe concisely - it wasn’t just a database or a spreadsheet, it was an end-to-end solution to

that specific

problem, and to hell with generalizability. Your job was to solve the problem, and not worry about overfitting; PD’s job was to take whatever you’d built and generalize it, with the goal of selling it... See more

Palantir was an unusually weird place, too. I remember my first time I talked to

Stephen Cohen

he had the A/C in his office set at 60, several weird-looking devices for minimizing CO2 content in the room, and had a giant pile of ice in a cup. Throughout the conversation, he kept chewing pieces of ice. (Apparently there are cognitive benefits to... See more