What I learned at Palantir — Hire spiky pioneers
At Helsing, a significant portion of my mental real estate is occupied with recruiting. In this post, I’d like to share a few ideas on talent selection. While the content was originally meant for my Helsing colleagues who recruit and interview candidates, I thought it might be interesting for people outside the company, too.
Spikes
If you wanted to recruit for a triathlon team relay, would you rather compile a team of very good generalists or a team with a hydrophobic world-class runner, a mermaid, and Tadej Pogačar? Of course, you’d pick the team with “spiky” individuals, each excellent in their own discipline, but maybe not so compelling in others.
Palantir taught me to appreciate the same philosophy for Engineering talent: rather than search for generalists across many disciplines (eg, frontend and backend coding, technical writing and communication, motivation, team skills, product vision), hire engineers that are truly outstanding in a subset of relevant skills.
Like all analogies, the triathlon/engineering analogy is imperfect: except for the short handover phase between swimming/biking/running, there is no collaboration (or “interface”) between the three athletes. In contrast, a software engineering team comprising a database expert, a UI guru, and a product visionary will only create a meaningful software product if they can communicate and collaborate. Imagine the counterfactual in which there is absolutely no shared vocabulary between the three: they would have a compelling product vision, a performant database, and a beautiful UI, but the UI doesn’t do what the users need and it doesn’t integrate with the database. Not so useful.
This is the compromise I landed on: look for people with outstanding, spiky talent and then filter for humility; people who understand they are very good at some of the relevant skills, but humble enough to appreciate and defer to their colleagues’ excellence in other topics.
Pioneers
It’s startup folklore (eg, see Ben Horowitz’s The Hard Thing About Hard Things) that successful startups need to build a product that is at least 10x better than any alternative. A critical ingredient to this journey are the people you recruit; they don’t just need to be excellent, they need to be excellent innovators.
Innovators create technology rather than use technology. This is the difference between a person driving their electric car to the supermarket to buy an apple versus being the utter genius who realised some 10,000 years ago that she could grow thousands of apples by planting one in front of her house. It is the difference between someone complaining about CI style checks getting in their way and someone writing to toolchain to automate away the code style concern. It is the difference between using React to build websites and inventing React or Typescript to revolutionise the engineering practices of millions of developers.
How do you spot excellent innovators? It’s not easy, but here are some character traits that I look for.
First, they are curious; they want to grasp “was die Welt Im Innersten zusammenhält” (just like Goethe’s Faust), they dig into architecture documents and code bases until it finally clicks and they understand how it works. In discussions or interviews, they tend to ask questions rather than stipulating answers. (That’s why the awkward, long silence after an interviewer’s eventual pivot, “So, I’m sure you must have a lot of questions for me?”, can be a really bad sign if you’re looking for innovators.)
Next, they are never complacent. When they spot a structural inefficiency in their organisation or a code base, they would rather ditch other priorities or work late into the night than endure the inefficiency any longer. Note that while this character trait is an important enabler for innovation, it can also be disruptive for established teams, products, or organisations as a whole. This is precisely why Geoffrey A. Moore classic, Crossing the Chasm, advocates for eventually phasing out pioneers (i.e., innovators) in favour of settlers (i.e., maintainers).
Third, they love building tools. Of course, they master the use of existing tools, but they go way beyond that. When a task seems tedious, monotonous, or laborious, they don’t scale the process linearly by hiring or staffing more people, they invent and build tools that automate the process. In contrast to manual labour, tools compound over time and often make the difference between an organisation/application/business that scales linearly, and one that is 10x or 100x better, faster, or cheaper than the competition.
It’s worth noting that building tools is not easy and it’s not for everyone. Not only do you need the experience to spot structural inefficiencies and areas for non-linear improvement, but you also need the creativity to devise a solution, along with the clout and skills to execute your plan.
Finally, innovators have a tendency to reimagine problems or their constraints. One of my mentors at Palantir, Mark Elliot, called this re-imagination of constraints “cheating”; Kenneth Cukier et al. call it reframing. In interviews, these people will try to fully understand a problem and its constraints before suggesting a solution; in particular, they will want to distinguish between hard and soft constraints and then propose to (temporarily) ignore or bend the soft ones in order to simplify the problem.
For example, if you’re building a Web application that will hopefully someday serve millions of people, it’s likely still a good idea to start with a simple backend and an out-of-the-box commodity database, rather than trying to nail the scalable architecture on day one. Excellent engineers “cheat” by picking simple components in such a way that (a) they get off the ground quickly, and (b) they have a believable, smooth migration path later. Look for people who know how to square the supposed contradiction between being pragmatic short-term and implementing “the right” solution long-term.
Helsing
If any of this resonates with you, the good news is that I am looking for exactly those people I described in this article: pioneers and innovators with spikes in disciplines such as databases, geographic information systems, networking, UX, cloud data systems, embedded device engineering, and more. Helsing is also hiring interns (preferably final year students in computer science, software engineering, mathematics, physics, or adjacent areas) as well as computer science prodigies. I look forward to working with you!