Maybe It Shouldn’t be an FDE

Everyone wants to copy the Palantir playbook, but maybe not everyone should.

The Forward Deployed Engineer (FDE) has become one of tech’s most copied – and according to Ted Mabrey, most poorly understood – roles. Startups see it as a shortcut to deeper customer intimacy and faster product iteration. But most of these interpretations miss the point.

The original purpose of an FDE was to serve as a bridge: someone who lived inside the customer’s world, wrote code alongside them, and brought those lessons back to shape the product. Though not necessarily the most efficient from a cost perspective, the model worked because it created a continuous feedback loop between product and customer reality.

These continuous feedback loops are foundational for AI startups, especially those building within verticals. The original FDE model offers a blueprint for that kind of learning loop: embed deeply, capture signal continuously, and translate it back into product improvement. However, as more startups adopt the FDE model, they’re discovering the limits of human-intensive deployment. What makes sense in a company with >$50M-per-account contracts is unsustainable at <$500K ACVs. Thus, the next evolution needs to be about scaling that intimacy and turning what was once a people-driven loop into a software-driven system.

The Core Misunderstanding

Many companies adopting the FDE model are designing it like sales engineering. Some even attach quotas to these roles, blending compensation with revenue targets. The intent is understandable as FDEs work directly with customers, but this structure can create misaligned incentives.

In its original form, the FDE role was flatly compensated with no variable pay. That’s because the goal wasn’t to close deals, but rather to close the gap between the product and the customer. The job was to sit inside a customer’s environment, figure out what was broken or missing, and sometimes even write the code to fix it.

FDEs are evaluated on the success of their deployments, not the size of their contracts. The best ones move fluidly between implementation, project management, relationship-building, and direct product contribution.

A Relationship More Like Open Source

That last part – direct product contribution – is what makes the FDE role particularly unique. One Palantir FDE I spoke with described their relationship with the core product team as similar to the relationship between open source contributors and maintainers. The product team builds for the entire customer base whereas FDEs build for just one customer. They understand where the product breaks for that customer, and can scope code changes to improve outcomes specific to that customer.

In this sense, the FDE is like a deeply invested contributor, providing high-quality, real-world signal about where the product should evolve – but not actually owning the roadmap. That signal, which is the translation of field pain points into product priorities, is the most valuable currency the role creates.

The Operating Model

Translating that signal into action, though, requires structure. The way FDEs are deployed and managed matters just as much as what they do day-to-day.

FDEs at Palantir are typically embedded within account-based teams under a broader business development organization. Their projects might last anywhere from a few months (in early pilots) to several years (in long-term big accounts). Assignments depend on three factors: what they’re good at, what they want to do, and what the business needs.

Crucially, the decision to stay or roll off an account isn’t purely based on maturity or deal size. As one FDE put it to me, “the vibes matter.”

This alignment-driven model explains why so many Palantir alumni go on to become founders. The role forces you to touch architecture, data modeling, relationship management, and strategy – the same cross-functional problem-solving skills required to build a company.

But what worked so well inside Palantir doesn’t necessarily translate to other companies. As the FDE model spreads, its cost structure will soon collide with basic unit economics.

The Next Phase of the Model

Most companies won’t be able to deploy FDEs in the same way that Palantir has done so. This is in part because few companies can achieve the same ACVs as Palantir, which generates ~$1.5 billion in annual revenue from their top 20 clients.

Therefore, as more companies hire FDEs, there’s an emerging challenge: efficiency. Embedding engineers with every major account is expensive. Over the next one to two years, as budgets tighten, CFOs and CTOs will look for ways to claw back the margin FDE-heavy models consume.

That’s likely to spur a new generation of software designed for deployed engineering organizations, tools that capture product signal, automate customer feedback loops, and make the FDE model more scalable.

These tools will effectively become an operational layer for human-in-the-loop deployments. This could mean that an FDE is now able to oversee ten or twenty or more accounts instead of one or two.

Palantir proved that the FDE model can create unmatched alignment between product and user need. But this model is also expensive and won’t work for most companies. Thus the next evolution will be about codifying that alignment to turn insights from the field into scalable systems.