What's a Forward Deployed Engineer?

And why is every startup around following the Palantir model?

Before we dive in, two housekeeping notes:

1. The annual Technically reader survey is open until the end of the week.

2. Last week’s post (on vibe coding + the maker movement) from Sachin made the front page of Hacker News and roused quite a convo. To continue that convo, tomorrow Sachin + friends will host a Substack live session at 3:30pm ET to discuss whether we’re making anything of value when we vibe code, among other topics.

Now on to Palantir + the Forward Deployed Engineer role. Let’s give a warm welcome to Sung, who’s done technical sales at multiple software companies (most notably dbt Labs), on his first Technically post.

---

The TL;DR

The startup ecosystem is seeing an explosion of companies coining themselves as, “We’re basically Palantir, but for X.” Underlying that idea is the Forward Deployed Engineer, or FDE – think of them like a customer-facing engineer working directly with prospects and customers. The FDE seems to be all the rage right now…but is it actually a good idea for startups to have them?

This post will run through everything you need to know about FDEs, what they do, secular trends that are causing so many companies to want to hire them, and whether they actually make sense for most businesses.

If you prefer this post in video form, check it out on Technically’s burgeoning YouTube channel:

What is a Forward Deployed Engineer (FDE)?

A Forward Deployed Engineer (FDE) is a highly technical, customer-facing role where software engineers are embedded directly within customers to solve real-world problems. Originally pioneered by companies like Palantir, the role has become essential for AI, enterprise SaaS, and data infrastructure firms where products are too complex to be “plug-and-play.” Instead, someone from the vendor has got to get in there and make sure it actually works.

How is this different then a conventional technical consultant?

Technical consultants – think Accenture and the like – have been around for decades. Isn’t an FDE the same thing?

A lot of people had that same question when Palantir coined the role and it can be summed up simply. FDEs do highly custom work – like a technical consultant – but then take it a step further by generalizing the implementation and lessons learned into a core product. In Palantir’s case, an example is *Foundry, “*the foundational data operations platform, which provides the core capabilities for data management, logic authoring, Ontology development, analytics, and workflow development.” In a startup’s case, you’ll notice they use terms like “platform” which is analogous to providing the lego blocks to build use-case specific software vs. building from scratch every time.

How is this role different from a software engineer (SWE)?

SWEs are primarily internal and have minimal interactions with customers. The FDE, on the other hand, takes on the mantle of owning direct customer relationships. There’s usually a distinction, sometimes as subtext, that FDEs need high technical ability and emotional intelligence (EQ) to be effective in the role. If you’ve been in the workforce for years, you’ll recognize this combination is rarer than people think (or like to admit).

Why is this Palantirization narrative so popular now?

We don’t know what we don’t know

Deploying AI in production is hard, brittle, and constantly evolves. There is literally no such thing as best practice right now. For example, people were raving about vector databases to reduce bloat for LLM models retrieving context to perform tasks. But now, mainstream LLM models don’t need that infrastructure overhead because they handle 1 million tokens in their context windows; vector databases aren’t so hot anymore. Similarly, testing AI applications is an emerging art called “evals” that is in very early stages to even have convention. This builds a lot of anxious hesitation for anyone, even those on the cutting edge. You can imagine this feeling is more pronounced in large enterprises.

Only a real person can clear the fog of war

This then motivates the question of what’s worth retrofitting (think: slapping AI chat bubbles in your app) vs. replacing entire people, processes, and existing subscriptions. There aren’t enough role models in the industry yet, so companies need a real human with deeply lived experience to make sense of the constant change. To make this emotionally grounded, it’s like what a lot of people do when researching health problems with AI. It may give convincing general guidance, but you’ll want a real, human doctor to make big decisions and catch things you didn’t think to ask the AI.

Why can’t you be like Cursor?

The above couples tightly with the fact that expectations for being a “successful startup” have increased exponentially. Being a unicorn ($1 billion valuation) startup gave you pedestal prestige. But now, it feels like you have to be a decacorn ($10 billion valuation) startup to attain that same cachet. To reach that decacorn requires fast revenue growth, and the easiest way to get there is to win bigger sales deals that are six-figures on average vs. the 4-5 figures a lot of startups even 2 years ago saw as convention. This biases them towards going all-in on large enterprises.

But first, explaining enterprise sales

To understand the role of the FDE we must first take a detour to talk about old school enterprise sales.

In short, it’s a highly custom sales motion requiring many months, persuading and aligning multiple stakeholders and departments at a company, custom contracting, and “white-glove” onboarding. Some examples include buying a fleet of airplanes by a major airline. The airline likely won’t feel comfortable with standard pricing and contract terms with the swipe of a monthly credit card subscription. For software, the enterprise sales motion above was likely expressed in how your company bought slack or Microsoft teams, buying hundreds or thousands of seats in a single contract.

Working with enterprises is very very difficult

Let’s get a bit more meticulous with how selling to large enterprises looks and feels. The above affectionately termed “the decagon of despair” illustrates why enterprises are slow to buy new software, even if they really want it. I’ll belabor the point with questions that a potential customer thinks through when they see a demo or thinking seriously about buying.

• Institutional Inertia: Why is this worth doing extra work on top of my busy job?

• Charging Models: Do we get economies of scale as we expand usage of the product?

• Audit: What internal governing body/accounting firm will yell at me if we get this wrong?

• Capability: Does it solve the problem with a reasonable level of effort?

• Security: Does this touch the public internet? You got RBAC and SSO? SOC 2 Type 2?

• Outdated Paradigms: This mental model is the only one this org runs on (think: on-prem only)

• Regulation: What external governing body will yell at us if we get this wrong?

• Procurement: What’s a reasonable price to value?

• Legacy: Retrofit vs. replace?

• Change Control: Who is the project manager that keeps progress daily and maps names to scope?

These questions swim through an enterprise buyer’s head no matter how good a startup’s product is. It can be summed in an adage we’re all familiar with: “Change is hard.” Most enterprises aren’t willing to change with fancy slides, a demo, and even an undeniably great product. Enterprise buyers commit to a complicated, immersive relationship, and you need a face like an FDE to instill trust that it’s worth it.