Verdict: You only need a forward deployed engineering (FDE) function if two conditions are both true: you sell a technically complex product to a non-technical buyer, and you have a reusable platform with shared primitives — not a pile of bespoke one-offs. If either condition is missing, you are better served by a developer relations team (for technical buyers) or a traditional sales-led motion (for non-technical products). The FDE model is not a hiring trend; it is a structural response to a specific market gap, and getting it wrong is expensive.
Last verified: 2026-07-31 · TL;DR: FDE = scaled design partnership on a platform. Palantir's $4M ACV (7x the industry median) proves it works. But without a platform, an FDE team is just a dev shop with worse margins. AI is pulling this model mainstream because agentic platforms are inherently customizable — and customers cannot implement them alone.
What Is Forward Deployed Engineering?
A forward deployed engineer (FDE) is a customer-facing software engineer who embeds directly with a client to deploy, customize, and ship production software inside that client's own environment. The role was pioneered by Palantir in the early 2010s — engineers physically deployed to air-gapped government and defense sites to make complex data platforms actually work for specific customers.
The key distinction: an FDE does not build your core product. They take your platform into a customer's real environment, understand the customer's business problem, and assemble a solution on top of your platform's primitives. They own the outcome — not the demo. Kevin Bai, who built the FDE function at Rippling as its first hire and previously led FDE engagements at Palantir before joining Anthropic's Applied AI team, puts it simply: an FDE is "nothing more than a customer-facing software engineer." [Source: Kevin Bai, "Forward Deployed Engineering 101," AI Engineer, July 2026]
The 2x2 Matrix: When FDE Makes Sense
Bai's framework is a 2x2 grid built on two axes: how technical your product is, and how technical your buyer is.
| Technical buyer (CTO, engineers) | Non-technical buyer (fortune 500 leaders) | |
|---|---|---|
| Technical product (GitHub, Datadog, Palantir Foundry) | Self-serve or dev-led. Customer absorbs the complexity. (GitHub, Datadog) | FDE territory. You must send engineers to make it work. (Palantir) |
| Non-technical product (Slack, Jira, Rippling) | Rare mismatch. | Traditional sales-led SaaS motion. Product is configurable, not built-upon. |
"You only need FDE if you are in this weird unique situation of Palantir where you are having to sell something very technical to a non-technical buyer," Bai says. If your buyer is a CTO who can absorb platform complexity, a developer relations or self-serve motion works. If your product is configurable rather than buildable (like Slack or Jira), a traditional sales-led motion is fine. FDE only enters the picture when technical complexity meets non-technical buyers.
Why Palantir's Model Works: The Numbers
Palantir's average contract value (ACV) — the amount a single customer spends per year — is the highest in public SaaS. Bai cited these figures during his talk:
| Company | Average Contract Value |
|---|---|
| Palantir | $4.0 million |
| ServiceNow | $1.2 million |
| Workday | $600,000 |
| All other public SaaS (Fortune 500) | Below $500,000 |
Palantir achieves this with only a few thousand employees. The model works because customers are not buying a product or a service — they are buying an outcome. Palantir sends trained engineers who understand the customer's business, build a solution on top of the Foundry platform, and deliver a working result. The customer never has to hire, recruit, manage, or retain those engineers themselves. [Source: Kevin Bai, AI Engineer talk; confirmed by public Palantir filings and industry analysis]
FDE vs. a Dev Shop: The Platform Is the Difference
The most common mistake companies make when adopting FDE is treating it as a hiring problem — bringing on "hybrid" engineers who build custom solutions from scratch for each customer. If each FDE builds from scratch, you do not have an FDE function. You have a dev shop.
The difference is structural:
| Dev shop | FDE program |
|---|---|
| Builds custom software from scratch per customer | Assembles solutions on top of a shared platform with reusable primitives |
| Each customer = a new codebase to maintain | Each customer = a new configuration of existing primitives |
| Maintenance costs scale linearly with customers | Maintenance costs stay bounded by the platform's surface area |
| Engineers refuse to work there (55 repos, no leverage) | Engineers see leverage: one platform, many deployments |
| P&L eats you alive from maintenance overhead | Revenue concentration offsets engineering cost |
The platform requirement is non-negotiable. FDEs must never write software from scratch. There must already be a set of shared primitives — data models, APIs, authentication flows, tooling — that they assemble into a solution. Without it, you reinvent the wheel for every customer and your engineers quit before the maintenance bills arrive. [Source: Kevin Bai, AI Engineer talk, July 2026]
How granular should the primitives be?
Bai's answer: it depends on your customer base. If you serve a broad swath of customers (like AWS, where DynamoDB removes the need to invent a database), you want robust, reusable primitives where the app is ~60% pre-built and FDEs customize the remaining 40%. If you serve niche use cases requiring extremely granular configuration, your primitives need to be finer-grained. The right level is the one where FDEs are assembling, not inventing.
FDE vs. Other Roles: What It Is Not
FDEs get conflated with several adjacent roles. Here is the actual distinction:
| Role | Owns Production Code? | Customer-Facing? | Pre-Sale or Post-Sale? | What They Deliver |
|---|---|---|---|---|
| Software Engineer | Yes | Rarely | N/A | Core product features |
| Solutions/Pre-sales Engineer | Sometimes (PoCs) | Yes | Pre-sale | Demo environments, evaluation reports |
| Customer Success Engineer | Rarely | Yes | Post-sale | Support tickets, enablement sessions |
| Forward Deployed Engineer | Yes — in production | Yes, directly | Post-contract | Running production system + product feedback to the roadmap |
An FDE who does not feed field intelligence back into the product team is a solutions architect with a different title. The product feedback loop — what the FDE learns from one customer that should become a platform primitive for all customers — is what converts an FDE program from cost center to product leverage.
The 2-Question Test: Should You Build an FDE Function?
Before adopting forward deployed engineering, Kevin Bai says you must honestly answer two questions:
Question 1: Do I need to sell something complicated to a non-technical buyer?
If your ideal customer profile (ICP) is a CTO or engineering team, and they can absorb your product's complexity themselves, you do not need FDE. A developer relations team, a great documentation site, or a self-serve PLG motion will work. GitHub and Datadog sell incredibly complex software to technical buyers who implement it themselves — no FDEs needed.
If your buyer is a Fortune 500 executive in oil and gas, CPG, healthcare, or manufacturing — someone who cares about business outcomes (shelf placement, throughput, supply chain resilience) and not data architecture — and your product requires engineering work to implement, you are in FDE territory.
Question 2: Do I have a platform, or am I willing to invest in building one?
If the answer is no, stop. FDEs without a platform is a dev shop. The maintenance burden alone will consume your P&L. Even with a robust platform, the maintenance cost is significant — without one, it is unmanageable.
If the answer to both questions is yes, you have the structural conditions for an FDE program. The next step is finding the right people.
What Makes a Good FDE? The Ideal Profile
Bai's tagline: an FDE is "nothing more than a customer-facing software engineer." The ideal profile is a person you would hire as a software engineer on your team — someone who can read a stack trace, write production code, and debug a deployment — whom you would also trust in front of a customer.
The skill set is unusually broad:
- Production engineering — FDEs ship real code into customer environments, often under tight deadlines.
- Systems integration — legacy APIs, data pipelines, auth flows (SSO, SAML, OAuth) rarely match the documentation.
- Customer communication — explaining technical tradeoffs to non-technical stakeholders under pressure.
- Product judgment — deciding what to customize for one customer vs. what belongs in the core product.
- Comfort with ambiguity — requirements shift constantly once real usage begins. Rigid processes fail here.
The non-technical skills are what eliminate most candidates. A strong engineer who cannot communicate with stakeholders will fail as an FDE. A strong communicator who cannot ship production code will fail as an FDE. You need both, in one person. [Sources: Kevin Bai AI Engineer talk; FDE Academy compensation and skills data; open job listings from OpenAI, Anthropic, and Palantir]
What Goes on the Platform vs. Forward Deployed?
This is one of the most common operational questions. Bai's rule:
- Bespoke and unique to one customer → forward deployed. It should only exist for that one customer on that customer's environment.
- Generalizable across multiple customers → platform. It should eventually be promoted into the shared primitives.
When you start an FDE program, you will not have many primitives — and that is fine. FDE is also a scouting function. As FDEs solve problems for one customer, they discover patterns that should become platform capabilities for all customers. The feedback loop from FDE → product team → platform is what compounds the model's value over time.
Why AI Is Pulling FDE From Niche to Mainstream
The landscape has changed since Palantir pioneered FDE in the early 2010s. Bai's hypothesis is not that the industry suddenly discovered Palantir's model was clever. The deeper change is structural: nearly every platform is now agentic, and agentic platforms are inherently customizable.
When every platform can be configured, extended, and customized with AI agents, every customer needs help making it work in their specific environment. The non-technical buyer cannot implement an agentic workflow on their own. The gap between what an AI platform can do in a demo and what it delivers in production — respecting RBAC, integrating with legacy systems, not hallucinating in regulated workflows — is where FDEs live.
The market data supports this:
- FDE job postings grew 800%+ year-over-year between January and September 2025, with total postings up over 5,000% since January 2025 (from ~643 to 5,330+ postings). [Source: Live Data Technologies via Paraform; Indeed data via BigGo Finance; Fast Company]
- OpenAI launched "The Deployment Company" in May 2026 — a separately incorporated FDE business unit with over $4 billion in committed enterprise capital, seeded by acquiring applied-AI consultancy Tomoro and its ~150 forward deployed engineers. [Source: FDE Directory; OpenAI official careers page]
- Anthropic formed a $1.5 billion joint venture with Blackstone, Hellman & Friedman, and Goldman Sachs in May 2026 to embed AI engineers inside financial services clients. Anthropic calls its FDEs "Applied AI Engineers" — same role, different title. [Source: Reuters; WSJ; Goldman Sachs Asset Management official press release, May 2026]
- Google announced hundreds of new forward deployed engineer hires across its Cloud division in 2026. [Source: Futurense analysis of Google Cloud hiring data]
- Compensation reflects the scarcity: OpenAI FDEs earn $350K–$550K total comp at mid-to-senior levels; Palantir FDSEs median $215K (range $171K–$415K); Anthropic's Applied AI Engineers $300K–$550K+. [Source: Levels.fyi, May 2026; GetPerspective 2026 compensation report; Paraform industry data]
a16z called FDE "the hottest job" in tech in 2026. The demand is structural — not cyclical.
What This Means for You
If you are a founder or product leader evaluating whether to build an FDE function:
- Run the 2-question test honestly. FDE is not a trend to chase — it is a structural response to a specific market gap. If you do not sell a technical product to a non-technical buyer, or if you do not have a platform with shared primitives, choose a different go-to-market motion.
- Invest in the platform before the FDEs. The platform — reusable data models, APIs, auth tooling, integration frameworks — is the moat. FDEs without a platform are a dev shop with worse unit economics.
- Hire for the hybrid profile. Look for engineers you would trust in front of a customer. The communication and product-judgment skills are what eliminate most candidates, not the coding ability.
- Build the feedback loop. The FDE → product team → platform cycle is what turns FDE from a cost center into product leverage. Without it, you are doing custom consulting under a misleading title.
If you are an engineer considering an FDE career:
The role offers high compensation ($215K–$550K+ total comp at top companies), direct ownership of customer outcomes, and a career path into senior deployment leadership or product strategy. The key skill is not AI engineering depth — it is the ability to operate across engineering, product, and customer-facing work simultaneously. Companies like OpenAI, Anthropic, Palantir, Google, Databricks, and Salesforce are all hiring aggressively.
How Does FDE Really Differ From Traditional Product Strategy?
Forward deployed engineering is not a separate product strategy — it is an extension of your product function that operates at the customer's edge. The existing Shaam Blog deep-dive on FDE as a product strategy covers the four core principles (detect the real problem, go on site, calibrate for production longevity, generalize from custom work) in depth. The short version: FDE without product strategy produces traveling consultants who never generate product leverage. FDE with product strategy turns every customer engagement into platform capability.
The decision framework in this article answers the earlier question: should you adopt FDE at all? The product strategy piece answers: once you do, how do you run it well?
FAQ
Q: What is a Forward Deployed Engineer (FDE)?
A: A customer-facing software engineer who embeds directly with a client to deploy, customize, and ship production software inside that client's environment. Unlike a solutions engineer (who does pre-sale demos) or a customer success engineer (who handles post-sale support), an FDE owns the full arc from discovery through production deployment and feeds field intelligence back to the product team.
Q: When does a company need forward deployed engineers?
A: Only when two conditions are both true: you sell a technically complex product to a non-technical buyer, and you have a reusable platform with shared primitives that FDEs build on top of. If your buyer is technical (self-serve works) or your product is configurable rather than buildable (traditional SaaS sales works), you do not need FDE.
Q: What is the difference between an FDE program and a dev shop?
A: A dev shop builds custom software from scratch for each customer, creating a new codebase to maintain per engagement. An FDE program assembles solutions on top of a shared platform with reusable primitives — never writing software from scratch. Without a platform, an FDE function devolves into a dev shop with worse margins and higher maintenance costs.
Q: How much do forward deployed engineers make?
A: Total compensation at top AI companies in 2026: OpenAI FDEs $350K–$550K (mid-to-senior); Palantir FDSEs $215K median (range $171K–$415K per Levels.fyi); Anthropic Applied AI Engineers $300K–$550K+; Databricks AI FDEs $250K–$450K. Staff-level total comp can exceed $600K, with principal levels approaching $1M including equity.
Q: Why is FDE growing so fast in 2026?
A: AI has made nearly every platform agentic and customizable. When platforms are customizable, customers cannot implement them alone — they need engineers who understand both the platform and the customer's specific environment. FDE job postings grew 800%+ year-over-year between January and September 2025, and total postings are up over 5,000% since January 2025. OpenAI, Anthropic, Google, and Salesforce have all built dedicated FDE teams in 2026.
Q: What goes on the platform vs. forward deployed?
A: Anything bespoke and unique to one customer stays forward deployed — it should only exist for that customer. Anything generalizable across multiple customers should eventually be promoted into the platform's shared primitives. FDE is also a scouting function: what an FDE builds for one customer today may become a platform capability for all customers tomorrow.
Discussion
0 comments