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

Palantir is en vogue right now, and with it, cargo-culting externally-legible elements of its culture, especially “Forward Deployed Engineering”. Lots of companies are trying to imitate this, and I've had founders reach out for advice on whether they should do this model for their startup.

The answer for most people is "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 “Embedded Analyst” or “Deployment Strategist” externally, and “Echo” internally). I worked side-by-side with some wildly talented Forward Deployed Engineers, and got to see this model at its best, and worst.

Now, running a software business of my own (that’s explicitly not doing “FDE”) I 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 the 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 for companies to succesfully adopt.

The birth of Foundry

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.

I got to witness this with the emergence 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 things, and hoping enough would emerge from it that we could cobble together a reasonable business. In the moment, it felt 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 mindset

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 an excruciatingly 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. We weren’t just looking for technical skill, either – forward-deployed folks also needed creativity, judgement, and customer-facing charisma. This was far more expensive and challenging to hire for than a traditional “Field Engineering” team.

Compounding this cost is the overlapping and wasted work. It was common to have several teams working on similar problems. We 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’d don’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, not harvest short-term margins. ² This is a very particular way to look at capital allocation and 99% of founders and investors can’t stomach it.

Darwinistic development

Beyond the financial cost, most teams are unwilling to fully subordinate their roadmap to the needs of the field.

The "FDE" model relies on the philosophy 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 teams off-roading is treated as heresy.

This bottoms-up evolutionary approach begot an incredible, inimitable pace of innovation. By letting many flowers bloom, we wound up with a brilliant bouquet that couldn’t have been centrally conceived or executed on.

Alas, this also 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 was 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 truly reap the benefits of Forward Deployed Engineering, you have to be willing 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 this has in common with the venture capital model; 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 wound up generating 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 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

Leaving Palantir, I had it drilled in my head that Forward Deployed was the One True Way to develop software. But the reality is that it isn't right for every company – not even for most companies run by Palantir alums. ⁵

For example, we don't have FDEs at Hex, a company whose founders and core Eng team have a lot of ex-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.