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.
A model with precedent: vendor + consulting partnerships
The above isn’t novel behavior, even though the narrative is. What FDEs are doing now was more conventionally decoupled and symbiotic between startups and consulting firms. It’s typically called “partnerships”.
I’ll anchor to my time selling developer tools at dbt Labs. There was a congruent narrative where my team coupled with a consulting partner of choice confidently said to enterprise buyers, “We are your trusted advisor.” It’s because organizations of this size are accustomed to this model with the mix of incentives and components they bring to the buying experience.
Startup Incentives and Components
Partner Incentives and Components
Static tool/platform with predictable evolution
Repeatable work to slot in consultants easily. Light customization of the tool, most customization in business logic.
Snowflake, databricks, dbt, looker, fivetran, sqlmesh
Battle-tested integrations with adjacent tech
Land and expand usage
Land and expand billable hours
Every system and incentive from a startup used to map cleanly to consulting firms. However, as we examined earlier, there is no best practice in the constant vortex of change in AI tooling. The fog of war is too thick, and buyers are more discerning with their budgets as a result. It’s breaking the social contracts startups and consulting firms are accustomed to.
The old vendor + consulting model is breaking
For enterprise buyers, build vs. buy math is wonky when it comes to AI tools. As said earlier, when does it make sense to retrofit vs. replace? As a plain example, when does it make sense to build automation tools for a call center vs. replace it outright with what an FDE can build? You’ll notice the incentives, components, and narrative don’t map cleanly between startups and consulting firms anymore.
Startup Incentives and Components
Partner Incentives and Components
Living tool/platform with exponential evolution but still cohesive
Hyper custom software
Higher standard for UI/UX
Battle-tested integrations are less common, need to build their own
"Do more with a platform that evolves with you”
"Do more with a team with real life experience”
With heightened discernment and skepticism from enterprise buyers coupled with the diverging incentives, startups and consultants no longer have a clean story to pitch. Every fight for a budget is territorial now.
A complicated incentive structure
Churn on software, consulting, and mass layoffs are unfortunately normal in corporate culture. Startups and consulting firms aren’t the only ones furiously thinking about long term viability, individual employees are now too. For individuals not overwhelmed with anxiety at all this uncertainty and pessimism, some are seizing this moment of FDE status arbitrage.
So what’s a way for good engineers to build a public brand without having to be a social media influencer? Being a known, likable person. They’re already known for being highly technical, the missing piece from their brands is having high EQ. What role is generally accepted as exhibiting both? That’s right, the FDE is a safe, recognizable brand vehicle for software engineers looking to grow in their careers.
Relationships are a competitive advantage
There’s a core story woven throughout every piece of what you read above. When the world as we know it changes all around us, we reach for people we trust. Having the best tech, the best story, the best narrative, the best funding, feel hollow against the torrent of change. What feels lasting is deeply human.
I’ll illustrate with a simple story. Let’s say I’m an enterprise buyer who went on a shopping spree to buy 10 startup AI tools. I’m suddenly tasked with churning all contracts except 1 because the AI bubble burst. How am I going to make that decision? I may make a pros/cons list and go through the theater of asking feedback from stakeholders, but that doesn’t capture the essence of these decisions. I’m thinking, “Who can I afford to lose a relationship with? Who helped me do things outside the convention of what the software did? Who is acting as my trusted advisor vs. only pinging me 1 month before contract renewal? Who do I like? Who do I want to keep having a relationship with?” So the question for startups is:
“What relationships are you building?”
