Sorry, that isn't an FDE

The replicants take the form but not the function, and miss the soul

One of Palantir’s secrets in the Zero to One sense of the word has been the FDE.  We were criticized for a very long time for this approach to building and delivering software.  This criticism was annoying in the moment but in a full accounting quite valuable for Palantir.  The criticism created a chilling effect and resulting conformity in how software companies were built.  The resulting dead zone gave us a two decade head start on building a software company that is aligned with its customers. 

Now, the FDE is being lionized, studied and replicated.  It is both acknowledged as the most valuable credential in tech and becoming a mainstream way for software companies to organize.  However, every replicant I’ve encountered is a half measure.  They are redrawing boundaries around roles and responsibilities, internalizing costs previously outsourced to SI’s, or capturing product feedback in a different way. 

They are not committing to aligning their interests with their customers.  As a result they are replicating the form but not the function of the FDE.  In an ironic twist, by doing so people are now reinforcing what they misunderstood about the FDE all along and creating the very thing that has been criticized.  And perhaps should have been if the criticism was true.

The FDE works for Palantir because it is intrinsically linked to the unique ambition, product strategy, and business strategy we pursue.  The tribute bands go half way.  They capitulate on needing an FDE like role, but are still stuck in the prison of low-value, low-complexity, extractive software business models.   This results in underwhelming roles for individuals and underwhelming cash flows for shareholders.

The full embodiment of the role requires a full commitment to the customer.  Below is my version of what an FDE actually is and how it integrates with the fabric of Palantir.

The Inspiration

The FDE role was famously inspired by Karp’s observation of how excellent French restaurants operate.  The waitstaff is an intrinsic part of the kitchen.  If you want to order the wrong wine with the fish, the wait staff will simply tell you no.  In order to provide the best experience the delivery mechanism has to be a part of the product, it has to be opinionated, and it has to own that in this case the customer is going to get the best meal even if they don’t know how to ask for it.  Similar to the earned hubris that comes with a Michelin star in Paris, Karp observed that institutions were not organized to ask for the right software meal and the market forces of the software industrial complex were pumping them with empty calories.  You return to the restaurant if the food was the best; you would return to Palantir if the result was the best.  Over time we endeavored to set a standard for enterprise technology that would reform the entire market.  You can go to the hyperscaler buffet or the potato chip aisle until you decide you are what you eat and commit to the best.

A Worthy Product

The role is intrinsically connected to the ambition of Palantir’s products.  A worthwhile product thesis for Palantir requires 1) identifying a problem that is impossible to solve, 2) with major societal implications, 3) where if you can make any progress you create intrinsic value for the world.  These problem sets are worthy of a deep commitment.  They are the antithesis of an analysis of a market map.

The product thesis for Gotham was to provide enhanced security and enhanced civil liberties.  Karp believed society would not work with constant terror attacks and would not work if we were forced to forfeit our privacy in exchange for stopping them; the only way to push out the efficient frontier of that tradeoff is through technology. 

The product thesis for Foundry was to enable perfect truth in individual decision making and perfect truth in organizational decision making.  Individuals on the frontlines are not equipped with everything they need to know to make every decision they make, and leadership is hampered by the obfuscation that occurs between reality and the synthesis they receive. 

These mission statements, and similar ones we have for all of our products, mean that no matter how much product you have built, you have only built a fraction of what needs to be built.  When the things you need to build are de facto infinite, the only thing that matters over any reasonable duration of time is how quickly you can extend the perimeter of the product.  This approach to product strategy requires an organizational structure that is hellbent on extending that perimeter as fast as humanly possible. 

A Business Strategy of Unabashed Alignment

The FDE role is also intertwined with an unconventional business strategy: having the right clients is a better way to build an enduring, scaleable business than trying to have all the clients.  We publicly disclose that we generate >$1.1 billion in annual revenue from our top 20 clients. We achieve these exceptional ACV’s because we are deeply committed to alignment with our customers.  In the government context this is obvious; we have chosen sides and do not work with China, Russia and the like.  The west winning is our raison d’etre and we are intrinsically aligned with our customer. 

We have the exact same philosophy in the commercial sphere: the more we are aligned with our customers, the more we will win.  Much like the sometimes abrasive French waiter cares more about you having the best meal than you do, FDE’s are trained to view themselves as owners of their customers’ businesses.  You must hold yourself accountable to the end results of the customers business and try to act as if you are the CEO, but with zero authority.  This alignment constantly demands more of our product.  We have a visceral connection to how much more a customer could win if the product could just do a little bit more for them.  Instead of a customer facing engineer whose actual job is to reduce scope to shrink the customers ambition down into what a product does today, we own that every single reason the customer might lose is a shortcoming in what our product can do for them.  Those shortcomings define our roadmap.

For the FDE’s tasked with this impossible mission a large part of their job is navigating the intricacies of how to use technology to overcome challenges that are often not technical on the surface: organizational alignment, technical aptitude, user adoption, reimagining technology enabled business processes. These are all problems technology companies externalize.  The FDE internalizes them and uses code to solve them. 

This often results in a Gita-esque experience of incrementally revealed truth, one of Karp’s favorite metaphors, on a chariot of software.  The customer ends up with more demands and more ambition the more we deliver and usually completely reframe a project charter every month.  At odds with traditional waterfall or agile software development strategies, the FDE yearns for scope creep because the customer’s mission demands it.

Embracing Complexity in Product Development

The financial success of a company pursuing the FDE model hinges on whether or not you can embrace this complexity at the edge, but actually build software leverage into the business at the same time.  This is the hurdle nobody believed we could clear for a very long time.  Given how hard it has been, perhaps the skepticism was as reasonable as it was wrong. 

For Palantir the problem statement is can you build a product that provides substantial technical leverage to solve the next problem we have never seen before.  The same software that allows a soldier to avoid IED’s has to stop blue-green attacks.  The same software that produces more oil has to enable building airplanes faster has to enable AI powered underwriting.  This is an excruciatingly difficult challenge. 

I believe Palantir is the only company of our scale to succeed at delivering generalized, high ambition, product inspired by specific implementations.  I also expect that if Stephen Cohen, Shyam Sankar, Bob Mcgrew, Brian Schimpf, and three to five other less famous folks didn’t work at Palantir none of it would have worked; there is enormous key-man risk to building a product this way.  There are no rules, there is only taste, and even the best people in the whole world have as many misses as hits.  I regularly tell Palantir people that we are the very best in the world at building product like this.  And we suck at it.  We are constantly under and over generalizing and every once in a while getting it just right.

Our approach is to discover what products are going to need to do in the future by getting very, very deep with our customer and constantly pushing on the frontier of how valuable the software can be.  By doing this we are quite literally pulling the future forward, and developing software that consistently stays 5 years ahead of what the toe-deep enterprise software market collectively believes is required. 

The FDE has a conflict-riddled relationship with core product teams defined by constant contradictions.  FDE’s are encouraged to build custom software.  Devs are encouraged to forget their roadmaps to swarm high value opportunities.  Devs are also encouraged to ignore FDE’s.  FDE’s are also forbidden from deviating from a few core product principles.  Many core products evolve from specific solutions at specific customers.  Many core products were created whole cloth by creative geniuses.  Many core products required 10-20 different custom implementations before they could be synthesized into a common load-bearing technology. 

This is a very messy way to build product.  It is also the only way we have discovered to do it.  There are no maxims that, if you backtested them, wouldn’t violate the path one of our most important products took.  We must build product that provides meaningful leverage, every time, for the next business problem our customers have never applied the software to before.  Much like our overarching product theses, doing this excellently is an impossible problem to solve, but one we have found to be immensely rewarding to grapple with not hide from.

The tribute bands

The knockoffs look at the Palantir FDE and try to reason how they can use the model to more efficiently deliver their product.  They have taken one step but they haven’t taken the meaningful step to free themselves from the prison of commodity software.  They are only willing to tackle a level of complexity where they assume they must deliver the same narrowly- defined product with zero marginal cost sales from the very start.  This short changes their customers and short changes how powerful their products can be over time.

I regularly speak with former Palantir FDE’s who have taken roles at these companies and describe it as feeling like they are in jail.  They are constrained by the business strategy and thus the perimeter of what they can sign up for.  My point of view as an outsider is these companies are literally doing what people thought we were; internalizing systems integration cost with FDE’s but gaining none of the long term leverage. 

Most importantly, they are also failing to provide the crucible that turns FDE’s into hulks.  By defining the product by its edges not its ambition, they de facto define the role narrowly. The engineer is protected from the most important lessons the FDE role in its primordial form forces them to learn about the world. 

Wrap

FDE’s were created by an insight about the world that had very little to do with the domain to which we apply it.  It works because of how aligned it is with Palantir’s whole business from soup to nuts.  I think the primary lesson to learn is to not copy the FDE but to provoke you to ask what assumptions are you making about the fabric of your company, and if you should be copying anything at all.