Inside the role Palantir made famous—and the tradeoffs most startups miss.
Pristina, Kosovo. I’ll never forget the enormous Bill Clinton portrait painted on the side of a building as my UN handler, Justin, and I rolled into town.
What was I doing in a place that was a war zone just a few years before? The UN had purchased VMware’s software back in the early aughts and wanted us on-site for a “Jumpstart” to help them get it configured. I raised my hand for the assignment. I was always up for an international deployment, especially in a place that I don’t think I would have ever picked to visit on my own. I was in and out of there in a few days after I completed my mission.
I used the words “mission” and “deployment” deliberately. You see, right around the time of my trip, a (now half-trillion dollar market cap) software company, in service of American Dynamism, had its founding moment.
That company was Palantir.
And they popularized the idea of hiring Forward Deployed Engineers (FDEs)–who literally would go into war zones if needed to implement Palantir’s software.
The idea of a tech company sending a person out to a customer site to help them deploy that company’s product wasn’t a new concept. So what was so different—if anything–about the FDE model?
Was it simply a title that sounded way cooler than “Onsite Software Engineer” or “Senior Consultant” and therefore made for a great recruiting tool?
Was it that these folks were being sent into active combat theatres instead of a client’s cubicle-covered office building?
Was it that they were committing code into their own company’s codebase on behalf of customers, instead of creating bespoke plugins for a customer that integrated into the code base?
And perhaps more importantly, when should you, as a founder or a board member, advocate for an FDE approach vs. a more traditional model of product engineering?
Before I answer those questions, let me tell you why you should care.
FDE model isn’t just a hiring decision—it’s a fundamental company strategy decision that touches everything from your burn rate to your culture to your valuation multiple. Most startups that think they have FDEs don’t actually have FDEs. Or they think they need FDEs, when it would be a terrible choice for their particular business or business model. That’s why I think it’s helpful to start by talking about what Forward Deployed Engineers are not.
FDEs Are Not Consultants
My life for my first 2 years working in VMware’s professional services (consulting) division – when it was the fastest growing software company in history – looked something like this.
- I’d get an email from our ops lead that a customer bought a consulting engagement of a specific size and shape, in <insert some city that probably wasn’t on my bucket list>.
- I’d say “OK”, tell my girlfriend-now-wife where I was going to be next week, book my travel, and get caught up from the sales rep on what kinds of challenges the customer was looking for us to solve.
- I’d do the gig, going the extra mile, doing whatever I could to make the customer happy through our existing product.
Those last 4 words are the key here. “Happy through our existing product”
As much as I wanted to go the extra mile for a customer, there were limits to what I could do as someone without access (or technical ability) to modify VMware’s core codebase. I could usually figure out how to make the product work for the customer by configuring it this way or that. But there were cases where I just couldn’t work around a bug or an issue. And so I’d need to kick back the feature request to our product managers, so they could decide whether or not to prioritize it in an upcoming release.
FDEs Are Not Constrained By Roadmaps Or Product Management
“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.”
– Ted Mabrey, Palantir
I lived this tension in a past life as a product manager at DigitalOcean. Field teams would escalate hyper-specific feature requests that solved real customer problems but were nearly impossible to generalize for the broader customer base. My answer was usually “we’ll put it on the roadmap” i.e. “not happening any time soon.” And even with agile processes, to make a hard pivot away from the core product strategy is, well, hard.
FDEs Are Not Just Integrating With Products, They’re Building Products
Here’s an example of what integrating with a product looks like vs. building the product, so that it’s easier to understand the distinction.
When I click a button or two to let ChatGPT read my Google Drive, I’m leveraging an integration to make the two products talk to each other. I didn’t have to modify ChatGPT or Google Drive code, though perhaps I had to click a couple of buttons.
Now imagine I’m an FDE at OpenAI, and my customer wants me to be able to read Google Drives 50X faster than it can today, because it would drive significant value for my customer. In that case, the FDE would have the full authority to make changes to the core ChatGPT product in order to support that specific customer need. That’s different than a consultant (like I was at VMware) who is only able to write integration code that wraps around the core software.
FDEs Are Not Cheap (Do You Like Negative Infinity Margins?)
Barry McCardel, a former Palantir FDE who now leads Hex, describes the “problem”, which relates to the lack of constraints:
“Amongst all the mystique and hagiography, it’s easy to lose sight of the tradeoffs. Truly doing “Forward Deployed Engineering” comes with exorbitant taxes that almost no one is actually willing to pay. This model requires a high hiring bar and a lavish budget…costs are compounded by the overlapping and wasted work…We burned millions of dollars on customer pilots; in many cases the margins were literally negative infinity, because we were giving projects away for free.”
Also, as Thomas Otter warned in his Substack post about FDEs: If you have a significant number of FDEs compared with product-facing engineers, you start to look like an AI consultancy, not a product company. And consultancies get valued at 2-4x revenue multiples, not the 10-20x+ multiples that software companies command.
FDEs Are Not Necessarily Mission Driven (But I Think They Need To Be)
Palantir was and is a very “us vs. them” company in that they were building for the US and its allies, so that they could be in a position to defeat the enemy. Regardless of one’s politics, I can see how an FDE – or any employee at Palantir – could get behind that mission and do some risky things that one wouldn’t usually expect of software engineer. Like flying into Afghanistan during a war…
When you’re deploying your so-called FDE to a conference room at a bank in New York City, where they can leave to grab Chipotle at lunchtime and then hit the gym at 530pm, I’m not sure you have that same compelling mission. To be clear, I love banks, conference rooms, and Chipotle. I’m just saying that without a compelling mission, you’re not going to truly have “Palantir style” FDEs that are generating results that become part of startup lore.
Are FDE’s Right For Your Startup?
As a founder or board member, here’s what you need to understand about the tradeoffs between the FDE model and more traditional enterprise software approaches with pre-sales engineers, solutions architects, product managers, engineers that generally don’t talk to customers, and professional services consultants.
- It’s a cultural decision. I think there needs to be a good amount of “weird” and hyper-intensity in your startup as well as a compelling “Why” if you’re going to go the FDE route–and actually execute on it to the desired result.
- It’s a financial decision. Burning boatloads of cash and throwing out millions of dollars of R&D that you’re not going to end up using isn’t for the faint of heart–be they founders or board members.
- It’s an ICP decision. You need to have a BIG financial prize to pursue a true FDE model. Which means you’re probably going to want to target F500 or big government agencies as customers (or both, like Palantir).
And ultimately, it’s a company strategy decision that a CEO needs to make holistically. To go back to something Ted Mabrey said in his post:
“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.”
Inspiration and Sources
These sources inspired what you’ve read, and are great further reading if you want to go down the FDE rabbit hole.
[1] Ted Mabrey, “Sorry, that isn’t an FDE,” Ted Mabrey’s Substack https://tedmabrey.substack.com/p/sorry-that-isnt-an-fde
[2] Thomas Otter, “WTF is a forward-deployed engineer?” Thomas Otter’s Substack https://thomasotter.substack.com/p/wtf-is-a-forward-deployed-engineer
[3] Palantir Technologies, “A Day in the Life of a Palantir Forward Deployed Software Engineer,” Palantir Blog https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
[4] Max Dauber, “Forward Deployed Engineer: Profession of the Future,” Max Dauber’s Substack https://maxdauber.substack.com/p/forward-deployed-engineer-profession
[5] Gergely Orosz, “What are Forward Deployed Engineers, and why are they so in demand?” The Pragmatic Engineer https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
[6] Marty Cagan, “Forward Deployed Engineers,” Silicon Valley Product Group https://www.svpg.com/forward-deployed-engineers/
[7] Nabeel Qureshi, “Reflections on Palantir” https://nabeelqu.co/reflections-on-palantir
[8] Barry McCardel, “Understanding Forward Deployed Engineering,” barry.ooo https://www.barry.ooo/posts/fde-culture
[9], Shyam Sankar, “The Primacy of Winning,” Pirate Wires https://go.piratewires.com/ti/winning-full-length
