When people ask me, “How do you build a high-performing engineering team?,” the answer is: I don’t. High performance engineering teams are downstream of culture, and a culture reigns supreme if it has internalized the primacy of winning. Because winning is what matters. I’m not talking about stock price or OKRs. I’m talking about fulfilling your mission, delivering outcomes, and going faster, higher, and further than anyone thinks possible.

What is a high-performing engineering team? A sufficient number of software updates per hour? Crazy impressive DORA metrics? Elegant code that puts the best Haskell poetry to shame? It’s none of these things. A high-performing engineering team wins.

JRock said it best: “Win win win win win, fuck everything else, win.” It’s obvious, but not enough people think this way. Engineers get caught up in how they want the world to work, how they’ve been taught the world should work, but they rarely understand how the world actually works. And you can’t win if you aren’t living in reality. It’s a natural human tendency to define the problem based on what you can win at, but that is the ultimate corruption. You have to take the red pill and see how far down the rabbit hole goes (18 years in, and I haven’t hit bottom yet).

Roadmaps, planning, communication, release notes, and the process du jour aren’t evil. But when process interferes with the primacy of winning, you’re doing it wrong. Besides, the number one reason people buy into process is because they want to avoid pain, and they believe things are supposed to get less painful over time. But as champion cyclist Greg LeMond said, “It doesn’t get any easier, you just go faster.” You can’t build greatness if your primary feedback loop is built around pain avoidance. In reality there is no process, and it will be painful.

Are you winning? Do more of that. Are you losing? Don’t do that. You’ll figure out the rest, but in this piece, I explain in detail some helpful things I’ve picked up during my career to figure it out faster.

Missionaries vs. Mercenaries

No one has started a great company with the principal purpose of making money. That’s not a big enough “why” to bind you through the hard times, the near-death experiences when you’re days away from running out of money, when you have to pivot hard and blow up everyone’s roadmaps, when great people leave your team. There is no recovery from the congenital defect of choosing a bad quest.

Instead, people need to wonder, “Is this a cult or a company?”

Hiring missionaries who pursue winning with a religious and existential zeal is key. These initial cohorts will create the environ. As mercenaries (inevitably) interview — and even if you should make a mistake and let one slip through — they will find your team of missionaries as acerbic as the missionaries find them. Mercenaries are optimizing on their next job. Missionaries see this one as their only calling.

Shortly after Palantir started, investors and the few folks in the valley who were into us wanted us to hire a well-known 1000x engineer. At this stage as a company, we had nothing. No product, no business, no traction. We were desperate for any validation our model would work. And the fact that this engineering god would work at Palantir was very validating. The problem was, he wanted $500k in cash (that 2004 cash salary expresses at $10 million 2024 Silicon Valley dollars) and very clearly didn’t value the equity we were offering him. Fundamentally, he was a mercenary. To him, Palantir wasn’t a calling. Not giving him the offer was so hard — our investors weren’t happy and our own sense of self wobbled — but it led us to double down on the importance of missionaries. From that point forward, all salaries were capped below market, but with generous equity. We were going to be a cult. It was going to be painful to join, so applicants needed to want to be on board badly.

Rod Rhines was a U.S. Navy SEAL and CIA officer who tragically lost his life in a car accident in 2018. Rod led a lot of our early DOD (Department of Defense) work. He often told me he did more for his nation at Palantir than as a SEAL or CIA officer. Don’t let anyone into your engineering organization that doesn’t understand the privilege, obligation, and opportunity of your mission.

The False Choice of Work-Life Balance

If you build a cult, you won’t have to field too many questions about the false choice of work-life balance (another great example of how engineers want the world to work). But inevitably you will get a few. Don’t capitulate. You should live your life however you want, but if you want to do great things, you have to choose life over balance and commit to work so meaningful that you wouldn’t want it to exist as a concept distinct from your life.

Example: one of our first opportunities to deploy overseas came suddenly and all at once. We had spent time with the 10th Special Forces Group and their commander at their home garrison at Ft. Carson, Colorado, as they were preparing to take over command of a base in Balad, Iraq. They had liked what we showed them, but didn’t have time to train up predeployment. Then suddenly, several weeks later, the call came with three days notice to drive our servers from Palo Alto to Colorado, palletize them, and grab four seats on the C-17 that would deliver them to Iraq. The crusty warrant officers didn’t understand why they had to find space and housing for a few kids at the commander’s request (Anduril cofounder and COO Matt Grimm was one of those kids). Two weeks later, after our team crushed many cans of Red Bull and made countless commits, the units wouldn’t go on missions without Palantir.

Shortly before that, we had been training with the 5th Stryker Brigade Combat Team, 2nd Infantry Division, in anticipation of their deployment to Iraq. This was during the depths of a brutal conflict between combat units and Army bureaucracy around an Army intel platform that cost billions of dollars and didn’t work. The combat units wanted Palantir. The 5th Stryker Brigade Combat Team was asking for Palantir. But the bureaucrats won — 5/2 found out while finishing training that not only were they now going to Afghanistan instead of Iraq, they were also going without Palantir. The first few months of their deployment was carnage — they lost a lot of lives. This led them to call us up to figure out how they could get our software. Unfortunately, we had deprioritized a bunch of the capabilities they needed months ago when we learned they wouldn’t be using us. It was a whole-of-company effort over the next month to catch up. We tore up our roadmaps and organized around the problem. It was quite literally lives over balance.

In 2016, we expanded our product focus from intelligence analysis to mission planning and battle management, building a new product called Gaia. There was no flow state, neat OKRs, or planning documents because we were in Iraq, with no space on base, sleeping on cold concrete floors, committing code and responding to feedback real time. Born during the Battle of Mosul, Gaia’s first job was on this rescue mission of CNN journalists. Most Palantir products have an origin story like this — a conscious rejection of work-life balance in favor of something greater.

Real Growth Will Never Not Be Painful

Sometimes you need painkillers, but don’t confuse them for medicine. Levels, ladders, and any form of ex-ante performance expectation neatly codified into a rubric or guide are lies. They’re corporate opioids that keep the masses pliant and ‘productive’ as batteries in a vast matrix. The companies that are really good at telling their employees about their career growth make them feel great but deliver no actual growth.

Real growth is scary, hard, periodic, non-linear, and responsive to the environment. It doesn't happen on schedule, and it is subject to periods of intense activity.

Bruce Banner didn’t become the Incredible Hulk by lifting a little bit more everyday. It took a near-fatal dose of gamma rays to unleash his potential. And it felt awful. If you love your employees, regularly expose them to gamma rays by throwing them off the deep end. Put them in roles that stretch and even tear them. If you aren’t constantly talent spotting and taking bets, you’re doing it wrong. If no one at your company who has been there three months is leading an effort with people who have been there three years, you’re doing it wrong.

None of our leaders followed a conventional path. Khan Tasinga joined Palantir shortly before our first DOD deployment in 2008 as part of the effort to defeat improvised explosive devices. As with any first deployment, things were rough. Most of the engineering organization wanted the field team to send the debug logs and stacktraces back to Palo Alto. They wanted to be efficient. But Khan was not most people. He recognized efficiency was an illusion, and he committed to doing the hard work, onsite, in the windowless Sensitive Compartmented Information Facility (SCIF): pounding through logs, decompiling jars, and shipping fixes and monkey patches to solve problems. Technically hired outside the core engineering team, he stepped in and stepped up, pushing himself and all of us. It was three weeks of 18-hour days — his immense dose of gamma rays. He threw himself at every hard problem, and these experiences compounded. Khan eventually went on to run all of engineering.

Mark Scianna is another great example. Mark joined Palantir as a quality engineer outside of core dev. No one at the company spent more time supporting warfighters in Denied, Disrupted, Intermittent, and Limited (DDIL) network environments, and no one had a sharper sense of what was needed and what could work in these areas. When his pleas to redesign our flagship Nexus Peering technology weren’t gaining traction with the engineering organization and its senior leaders, Mark and a few others set off during a single week to hack together the poetically named “Red-Headed Step Child” project. He was right, and the red-headed progeny of Nexus Peering still drives global operations today.

Create an Artist Colony, Not a Factory

Management’s desire to scale in repeatable ways and reduce pain leads most organizations to scale like a factory. This approach requires interchangeable parts, people, and functions. Human interfaces define how the various teams interact with finance, recruiting, and themselves. Levels provide a clean way to handle comp conversations and keep talent on a conveyor belt. Coarsely defined roles let recruiting trawl the vast ocean for Software Engineer IIs. This cog-oriented approach elevates process over content, breeds conformity, and imposes a mimetic, self-limiting conception of the role. It makes it easy to lose sight of the primacy of winning.

Instead, you want to be an artist colony. What does managing and leading 10 of the world’s greatest artists look like? It isn’t command and control. It doesn’t hew to any structure or strictures. Instead, the leader must maximize the unique strengths of each individual in the colony — with the right person in the right role in the right time — to produce a great work of art.

Also keep in mind that not every work by an artist is going to be beautiful, because artists go through periods and phases, so you have to be committed to the incredible talent of your 1000x engineers and producers through their ups and downs. Episodic hits transform your business.

Artists are attitudinally anti-authoritarian. We love and encourage that. When I interact with new hires in AMAs, I always end them by asking them to tell me to “fuck off” in unison. Mark Scianna’s Red-Headed Step Child was one such rebellion. But one rebellion started it all. Dan Cervelli, now known to be a front-end god, was a new hire in 2008 and a former volcanologist. He was arguing with Bob McGrew, now VP of Research at OpenAI, about building a new map in Gotham, our battlefield intelligence product which has since evolved. Bob, who was head of the project at the time, didn’t believe it was feasible. Dan did, and what he built during one of our hack weeks was so eye-watering that we reorganized violently around it (much to Bob’s credit). It changed the trajectory of our business, not only because his product was so good, but because it encouraged us to allow Dan to continuously throw himself off the deep end in pursuit of his convictions and intuitions.

The Necessity of Chaos

Chaos feels bad, but structure is anti-creative. So much of a conventionally defined, well-run engineering organization is built to eliminate chaos by creating legibility and clarity, and avoiding “wasted” work. Project assessments are always retrospective — upon completion, there’s a tendency to determine that the frustration and pain the team experienced to meet the objective were unnecessary, and in the future should be avoided through the imposition of more order and process. But this is almost always wrong. You want to get there quickly, not painlessly. Every lesson you can learn about going faster is likely right; every lesson aimed at reducing chaos alone is likely wrong.

At its best, the engineering organization metabolizes pain and excretes product.

Some degree of flux, confusion, and chaos is a precondition to creativity. You want to be effective before you worry about being efficient. In the zero to one stage of any project, it should be chaotic (or you’ve already lost). Five-to-N is well-suited to structured approaches that drive repeatability. Thus the R&D product transition that happens when a product goes from one-to-five is always the most painful. The humans who did the scrappy, zero-to-one work see the world in irreconcilably different ways from the humans who must now scale this work by imposing some semblance of process. Managing the colony through this chaotic, interpersonal friction is your privilege.

When Google walked away from Project Maven, the groundbreaking DOD AI warfighting initiative, Palantir stepped in. The project called for a complete reimagination and fusion of intelligence and operations. We already had powerful pieces of the puzzle, but a lot of entirely new things needed to be built, and it wasn’t at all clear what those pieces were and what they should do. Classic zero to one. The team took over my D.C. office as a colocation space. And when they weren’t in D.C., they were in Afghanistan, Iraq, Djibouti, and other places working with operators.

The traction was immediate and intense, but so was the friction when I had to pull in more teams to mainline the effort. Roadmaps were at risk. Requirements were hazy. The ambiguity made problem decomp and clarity hard. There wasn’t going to be a linear path conducive to flow to get from here to there. This is perhaps why so much of the DOD’s R&D fails to transition to production. Scaling innovative product is not reducible to Gantt charts, milestones, and excessive requirements. To the extent it’s a “process,” it’s one that requires exceptional individuals who are willing to forge a unique path each and every time.

We built so much epic shit because of the chaos during Maven. And it was epically painful, one of the most painful experiences I’ve had, because of the chaos. And I would do it all again. Just look at the outcomes.

Superpowers and Kryptonite

Exceptional people are highly uneven. Very few, if any, are well-rounded. Thus the winning team has exceptional abilities, deep flaws, and complicated personalities. These unique humans have superpowers, but they likely don’t actually know what they are. Your job is to help them discover their superpowers and manage them to peak performance.

X-ray vision, the ability to fly: these were just some of Superman’s powers. But they weren’t hard for him, they were natural and effortless. Likewise, most people don’t know what their superpowers are because they’re not difficult to exercise, and unfortunately, talented people tend to believe that what they wish they were good at are their superpowers. A simple way to sort this out is to help them look at an ability they wish they had and help them see if they are two or three standard deviations away from genpop (likely not) — and compare that to their effortless superpower, where they are probably many more deviations away.

Similarly, it isn’t Superman’s fault that kryptonite is his weakness. It just is. There’s no cure for it, and only one solution: avoid kryptonite at all costs. All exceptionally talented people have kryptonite. Your job is to help your talent discover and accept that in a world that has taught them it’s fatal to admit to any weakness you can’t improve. You need to teach them the opposite is true: weaknesses don’t hold you back unless you’re in denial about them.

I discovered my kryptonite when, after truthfully answering a seemingly innocuous question from a congressional staffer about which agency was most behind on technology adoption, our team found all our badges to that organization’s buildings deactivated the next morning. Guileless engineer meets D.C. power politics.

Winning comes from the power law returns of maximizing superpowers and minimizing kryptonite. Despite what conventional HR professionals tell you, leave the rest unmanaged.

Decoupling Position and Portfolio

In the traditional model, employees embody a defined position with a defined portfolio. The chief virtues (vices, really) of this approach are predictability and legibility. This is why conventional, status-driven organizations are so often ruthless and dysfunctional. You can only be really aggressive and formal about promoting leaders if you're equally aggressive about firing leaders. This dynamic is inherently pro-mercenary.

The alternative model is the artist colony, where position and portfolio are not only decoupled, but position itself is an arbitrary construct — there are only artists and their work. Decoupling position and portfolio enables you to manage your artists to their superpowers and apply them to the company’s most pressing challenges. This approach also allows you to manage them out of their weaknesses without humiliating or breaking them, whereas in a traditional organization, taking away a portfolio or position implies an embarrassing loss of status.

The fundamental fluidity of portfolio and position constitutes the artist colony's greatest inherent advantage (and challenge). This approach is not a panacea of any kind — it requires constant engagement and examination. But it can be an unfair advantage to winning.

The Quantum Org Structure

Is the right org structure functional, matrixed, cross-functional, something else? Yes and no. Both. It’s like asking if light is a wave or a particle.

That’s because the best org structure is quantum. It’s both flat and hierarchical, functional and horizontal. For a point in time it manifests in an observed state when you organize around the problem that needs to be solved right now. Then it reorganizes around the next problem with a different structure more appropriate to the new challenge. Your people will hate this because it seems chaotic, and the common belief is that the ‘correct’ approach is one that’s well-ordered.

But that isn’t true. To win today, solve for the right structure. To win tomorrow, solve for the right structure again.

Broken companies have to reorg at great expense because they pick a structure, optimizing for legibility and planning for a world that inevitably stops existing, purely due to the entropy of the universe over time.

Code delivery is continuous and always optimized for winning. Your flying formation should be the same.

Building the Right Things vs. Building the Right Way

Broadly speaking, there are two types of engineers: hackers and artists. To paint a caricature, hackers derive joy and satisfaction out of solving a problem in the world — building the right things — but they are likely to do it in a way that doesn’t scale. Artists derive joy and satisfaction out of building a beautiful product the right way, but whether it solves a problem is completely beside the point.

If your team is made up of only one of these types of engineers, you’ll fail. All value comes from a managed misalignment between building the right things and building things the right way. Building the right thing is really hard. It’s the first 80% of the work. Building things the right way is really hard. It’s the second 80% of the work. Each type undervalues the contributions and difficulty of the other’s work, and there will be endless, unsolvable tension here — if you are lucky (that means you’re doing it right).

In 2006, Alex Karp asked me if I knew why French restaurants were so good. I had no idea. He told me that at a French restaurant, the wait staff is actually part of the kitchen staff. They intimately understand the food, the methodology, and the technique. They are not merely carrying the food from the kitchen to the table, but are instead part of a subtle and complex system that affects kitchen operations. He wanted me to build that, but for engineering.

I did just that, and in 2007, I gave it the name “forward deployed engineering” (FDE) in homage to our customers. FDEs embed alongside our customers and work to ensure our software solves their problem and not some proxy for their problem. They’re crazy enough to get on a last-minute plane to Iraq, they’re smart enough to ship quality, same-day code, and their EQ is still high enough to talk to users (and maybe even enjoy it). Investors ridiculed us for creating a “services” role that would only serve to depress the margins of a software company. We didn’t look like the other SaaS businesses, something they eventually realized was a feature, not a bug. Just like French restaurants don’t blindly hand off food from an uninformed waiter to the diner, we didn’t believe in throwing our software over the wall in the hopes the customer would divine the correct meaning from it. This approach built an engineering organization with unmatched creativity, responsiveness, and focus on the primacy of winning.

Kill the Orcs!

In Middle Earth, the Orcs spawned in the seams of the world. In this realm, the Orcs spawn in the seams between teams, generating dysfunction in a malevolent bid to block the engineering organization from delivering valuable bits at the right time to the right user. As a leader, managing, mending, and merging those seams is a crucial responsibility. Organizing around the problem will help you win here.

We grew up as company that proudly built and shipped monoliths. Our software provided an exquisite and integrated user experience. It just worked the way you expected it to. This was wonderful for our users and incredibly painful for us. Releases were a huge pain. Upgrades sucked. Managing quality in mission-critical environments was brutal. I can remember more than one upgrade that exceeded its outage window (remember those days where when you used to have outage windows?) and missions had to be scrubbed as a result. I never want to feel that shitty again.

We built Apollo to solve this. It enabled each dev team to be operationally responsible for their products across nearly 1,000 production environments, including nearly 100 air-gapped environments. It could manage each environment, its blue/green upgrades, rollbacks, CVEs — everything that was painful for the engineering team at scale and speed.

Apollo let us ship at blinding speed. But what we soon realized was that the blinding speed came at the expense of delivering an integrated user experience. Teams could now ship independently, without coordinating, and this encouraged people to build things with blinders on as to what was happening elsewhere. Unintentionally, Apollo had expanded the seams between the teams. We had to build a series of new muscles — moving the front-end back to a monorepo, growing new product muscle, changing the surface area of product ownership and tens of other small changes to regain the advantage and be able to both deliver 90,000 upgrades a week and a winning user experience. This is a problem you manage, not solve. Kill the Orcs!

The Truth is Out There

There is only the primacy (and finality) of winning. The right answers, the big gaps, and the valuable ideas have to be mined in the field, hidden within the chaos and crisis of the outside world.

Ask yourself constantly, “Am I winning?“ If the answer is yes, nothing else matters — chaos is tolerable; pain is tolerable. The only thing that matters is to win.

—Shyam Sankar