Understanding 'Forward Deployed Engineering' and Why Your Company Probably Shouldn't Do It

Palantir is en vogue right now. So of course, folks are cargo-culting elements of its culture, especially “Forward Deployed Engineering”. Lots of companies are trying to imitate this, and some other founders have even reached out to me for advice on whether they, too, should do this model for their startup.

For most people, the answer is simple: "absolutely f%#&ing not!".

Slapping a title on your field team because it sounds cool is one thing – building a truly “Forward Deployed” culture is another. It doesn’t work without complete commitment to the benefits and costs, and unless you’re willing to accept all of them, you're engaging in thin imitation – just sparkling Sales Engineering – and shouldn’t expect to achieve the same results.

I spent almost 5 years in a “Forward Deployed” role (called “Deployment Strategist” externally, and “Echo” internally). I worked side-by-side with some wildly talented engineers, and got to see this model at its best – and worst. Now I'm running a software business of my own (that’s explicitly not doing “FDE”), and have a deeper appreciation of what made this so unique.

There have recently been a couple of great posts explaining a bit about how Palantir works, including this masterful piece by Nabeel and this FDE-specific piece from Ted. But I want to go a bit further, and talk specifically about why this model is so hard, and such a bad idea for most folks.

Born in the field

The core of “Forward Deployed” culture is a radical deference to teams in the field. They are empowered to do whatever they need to solve a problem, even if it bears only a thin – even begrudging – relationship to the base platform. This isn’t limited to just configuring or customizing; it’s inventing entirely new products and technologies, if that’s what it takes to win.

This is the story of Foundry, the primary platform Palantir sells today. The core elements were first developed in places as far-flung as Zurich and Houston, São Paulo and Toulouse, Westport and Baku. They were born of necessity, because small teams wanted to fix a problem, with cost, compatibility, or cohesion as only secondary concerns. ¹

Customer deployments were proving grounds for new technologies – and those that worked were migrated toward the core and taken over by Dev teams, while FDEs fanned out in search of the next frontier problems. This development cycle happened incredibly quickly: when I was recruited in 2013, no part of Foundry existed, and by the time I left in 2018, it was a complete platform powering the company toward an IPO.

And this happened entirely bottoms-up. In 2014, at our annual “Hobbitcon” conference, our stated product strategy was literally “strong opinions, weakly held” – basically throwing things at a wall and seeing what stuck. We were just… building stuff, and hoping we could cobble together a reasonable business. In the moment, it was incredibly chaotic and nerve-wracking. Those of us with equity strike prices above $4 wondered how deep we were underwater.

But eventually things started sticking, and today Foundry is generating billions in revenue and relied on to power decisions at many of the world’s most important institutions (and the stock price is trading over $50 as I write this!)

This may sound like a success story to replicate – but this approach is not for the faint of heart, nor right for most startups.

R&D vs. COGS

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. At Palantir, we hired top-tier software engineers – the kind that could work at Google or Facebook or wherever – as FDEs, because they were there to build systems, not just tweak them. And we needed more than technical skill – forward-deployed folks also needed creativity, judgement, and customer-facing charisma. This was far more expensive and challenging to hire for than a traditional "Sales Engineering” team.

The costs are compounded by the overlapping and wasted work. We'd often have several teams working on similar problems, and wound up with multiple products for analysis, transformation, visualization, orchestration, and so on, all built by FDEs for whom the existing tooling wasn’t sufficient. And there were many failures – spectacular pyres of time and treasure and travel expenses that amounted to nothing. 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.

This all looks extremely inefficient if you look at it through a traditional SaaS finance lens: you’re spending on top-1% engineers traveling the world and building custom software, with no ex-ante monetization strategy and a high failure rate.

But in a true “FDE” culture, you wouldn't focus on the hours spent on specific customers — that’d be missing the point. Individual deployments can have terrible margins, because it’s really R&D, not COGS. The customer implementation is primarily an opportunity to build and learn,rather than harvest short-term cash. ² This is a very particular way to look at capital allocation and 99% of founders and investors can’t stomach it.

FDE, take the wheel

Beyond the financial cost, few companies are willing to fully subordinate their roadmap to field teams.

The "FDE" model relies on the doctrine of "Auftragstaktik" ³ where senior leaders set only the high-level objectives, and leave it to the Forward Deployed teams to make all other decisions. This is an anathema to most cultures, where leadership creates top-down roadmaps and plans, and off-roading is treated as heresy.

This bottoms-up, evolutionary approach begot an incredible pace of innovation. We let many flowers bloom, and made a brilliant bouquet that couldn’t have been centrally conceived or executed on.

This often took on a Darwinistic bent, with competing FDE-built solutions vying to see which could get adoption across the rest of the deployment fleet. It felt like development via jungle combat: the code was written quick-and-dirty to solve a problem at a specific customer, and generalizing it took longer than building the v0. It was messy.

Of course the natural tendency in most organizations is to fight this kind of variation, by hiring layers of PMs who implement process to control and corral it and make sure everything reflects the Gantt chart on slide 42 of the roadmap deck.

But to reap the benefits of Forward Deployed Engineering, you have to not only accept the chaos, but embrace it. You have to look at overlapping efforts, and failed projects (and burnt-out husks of FDEs) with gratitude for the lessons learned. This is the core of the “forward deployed” model, and unless you’re willing to commit, you’re not really doing it.

Something I didn’t appreciate at the time is how much Palantir BD has in common with the venture funding model for startups; it’s ok for most bets to miss, as long as the ones that hit pay back big. Our customer pilots were like little seed startups, given a few FDEs and a tight timeline, and told to go run through walls and make it work. Most didn’t make it – but the ones that did generated incredible value. ⁴

When does full-on "Forward Deployed Engineering" actually make sense?

I think you need a few things:

• A market that can command extremely high prices; you basically need to be targeting F500-size companies or big government agencies if you want to make this your long-term model.
• A mindset that you don't actually know the thing to build, and you're going to discover it bottoms-up with users. This is uncommon amongst startup founders, who usually have (or convince themselves they have) a strong vision of what they want to build.
• A platform designed for extensibility, and discipline about what is developed on the edge vs. migrating to the core.

These things are just exceptionally rare and very hard to pull off. ⁵

What we do at Hex

We don't have FDEs at Hex, a company whose founders and core Eng team have a lot of ex-Palantirians (better known as "Hobbits"). We have Software Engineers and Product Managers on our development teams, and we have Solution Engineers and Product Experts on our customer teams. We are a SaaS business and sell one product – there’s no custom development work in the field.

But the way we develop that one product builds on a lot of the lessons from our time at Palantir. We partner closely with customers and users on new features – getting into Commitment Engineering loops that allow us to quickly discover and build the right things. This avoids “ivory tower” development, which is unfortunately very real, and the reason most software sucks.

I’d encourage anyone building something new to adopt this model! Go sit with customers. Feel their pain. Build with them. Let your users guide you, and embrace your team making creative decisions on the fly.

Just don't equate that to needing "Forward Deployed Engineering", or pretending you're something you're not.