Forward Deployed Engineer: what it means, why it's everywhere, and why it means something different at every company right now

Maybe you've noticed "Forward Deployed Engineer" popping up everywhere lately. Maybe you haven't.

When I researched talent markets for VC-Backed Founding Engineers back in January 2026 across Canada and the US, I didn't see it once (for context, we manually look through thousands of profiles). Now, in June, deep in a search with the same tech stack and an even smaller geo-pool (Toronto-Waterloo corridor), the title is reocurring. When I ran this by my team, they shared that each of their clients have FDEs on their upcoming roadmap.

So we did what we always do - we looked closer.

What's driving this?

I wanted to understand if this was just a naming trend (like my name, Ashley, was in '93). What I found is that it's a signal about how companies are rebuilding their go-to-market around the product itself. When products get complex enough - especially AI infrastructure, dev tools, or enterprise platforms - traditional handoffs between sales, solutions, and engineering break. The idea is that someone needs to live in the gap between "the product works" and "the customer is successful." That's the FDE.

At its core, an FDE is embedded directly with the customer - working "forward" at the client's site or in their environment to build, customize, and integrate the company's product into the client's systems. Part coder, part consultant, part diplomat.

In practice, three distinct flavours of this work have emerged:

1. The integration engineer: deep technical work wiring complex products into client infrastructure 
2. The embedded success engineer: ensuring customers actually use the product to its fullest 
3. The technical consultant: using the company's platform to solve bespoke client problems

All three borrow the FDE halo. None are technically "new." What's new is who's hiring them.

From Palantir to Startups: Why the Shift Is Happening Now

Palantir invented the model in 2011 for a simple reason: their contracts were massive. Government agencies, banks, Airbus - multi-million dollar deals where dedicating a senior engineer to a single account was trivial math. Their software couldn't work any other way - messy data, legacy systems, airgapped military networks. You genuinely couldn't fix that from HQ. As Jason Lemkin wrote in SaaStr, “Palantir absorbed the upfront FDE cost themselves for years through multi-month pilots. Expensive, hard to scale, but justified by contract size.”

For years, startups stayed away for one reason: the math didn't work. If your ACV is $10K-$50K, dedicating an engineer to a single account destroys your unit economics. Your engineering team is tiny. Every hour spent at a customer's site is an hour not spent building product.

I asked Zach Waterfield, CTO and ex YC-Founder, why this model is having a moment now:

"It was previously thought that deploying an engineer in this way would be too expensive and not worth the investment, especially for startups with limited resources. However, companies have proven that embedding an employee with the customer is really important. It helps ensure the customer is using the product properly, retains it, and has expansion revenue."

So what changed?

Three forces flipped the math:

1. AI products require deployment to actually work: Unlike traditional SaaS, AI agents don't just "work" out of the box. As Lemkin notes, self-serve customers hit 20% automation rates while enterprise customers with FDE support hit 60-80%. The product literally doesn't deliver value without someone configuring it against real data.
   
   
2. Churn became more expensive than the FDE itself: Startups realized retention and expansion revenue outweigh the cost. Zach's point again: embedding someone "helps ensure the customer is using the product properly, retains on it, and has expansion revenue."
   
   
3. The playbook got lighter: Palantir innovated the AIP Bootcamp model: compressing "prove value" into five days with the customer's real data, then deploying FDEs only during the expand phase. This made the model more efficient. Plus remote work means you don't need someone physically on-site at an Airbus factory anymore.
   
   

Now some startups are being selective, one AI vendor told SaaStr only 5,000+ employee customers get dedicated FDEs. But others are finding that without embedded help, their product simply doesn't land. The WSJ noted that using FDEs can lower gross margins by about 10% for startups - but that the tradeoff is increasingly worth it.

When I came across this “new to me" title, I wondered if this was title inflation, like the “Growth Hacker” or “Rockstar Developer” hype cycles that came before it. Upon my research 🤓 it isn’t. It's organizations realizing customer success and engineering can't stay in silos anymore.

For Founders

If your product is complex, technical, or requires deep integration, this hire might be your retention and expansion secret weapon. But be specific about which flavour you need. "FDE" alone won't get you the right candidates. Look for people with both engineering and client-facing DNA - consulting engineering, solutions architecture, or technical pre-sales backgrounds who can actually code.

For Talent

Vet the role carefully. Some FDE jobs are genuinely new work that didn't exist five years ago. Others are rebranded solutions engineering. The "good ones" offer high impact, direct customer exposure, and a faster path to understanding the business side of tech.

The Bottom Line

If your product is complex and requires deep customer integration, the FDE model is worth considering. If you're an engineer who likes coding but also wants direct customer impact, this path is having a real moment. Either way, know what you're signing up for - because "Forward Deployed Engineer" means something different at each company right now, and we’re excited to see how it evolves.