Scaling FDE Teams Guide for Enterprise AI Leaders

A forward deployed engineer (FDE) is an engineer who works inside a customer's or business unit's operation instead of from the product organization, and who owns a business outcome end to end rather than a backlog. 

The shortlist for hiring FDEs is short. Your strongest candidates hold offers from AI labs, and the ones who sign land in an organization that was never built to support the role. For most enterprises the faster route to the same capability may be to bring in an assembled FDE pod and grow the internal muscle from there.

What Is a Forward Deployed Engineer?

A forward deployed engineer sits inside the operation the software is meant to serve, builds in that context, and is judged on whether a business outcome moved. We've already written about what the role actually involves day to day, here we’re focusing on staffing it.

Palantir originated the role and later renamed it Delta. A Delta focuses on "one customer, many capabilities," a Dev on "one capability, many customers" (The Pragmatic Engineer). 

Sounds confusing? Well, Akshay Krishnaswamy, Palantir's chief architect, described it more plainly on the a16z podcast, quoting a line he credits to the company's CTO: "an FDE's job is to basically absorb pain and then excrete product."

The model inverts the usual enterprise arrangement, where a core product team decides what gets built and field engineers implement it. Krishnaswamy calls the alternative building "through backpropagation" : start from one specific outcome, work out what has to exist to reach it, then generalize backward into something reusable.

Incentive structure is what separates an FDE from a solutions architect. Those roles, Krishnaswamy notes, are typically "metered by the hour or very much tied into contract deliverables." 

An FDE gets a declarative mission scope instead. Desmond Loh, who has run an FDE practice for three years, illustrates it with an engineer who noticed an analyst cross-checking the same three dashboards every afternoon, sat down beside her, and shipped an automation that ended the task inside a week.

Is It Hard To Hire a Forward Deployed Engineer?

The role spent a decade as an oddity in a dimly lit corner of enterprise software. "It was the ugliest duckling for so long," Krishnaswamy says. Once AI labs realized that enterprise adoption of agentic AI needs a push, the oddity moved up to the spotlight.

Anthropic's public posting for a forward deployed engineer (here’s an archived version if the posting is down) lists a base band of $280,000 to $320,000 for four-plus years of experience and around 25% travel. That is base compensation, before equity.

In July 2026 Microsoft announced Frontier Company, a $2.5 billion commitment to embed "6,000 industry and engineering experts" inside customer organizations, positioned as going "beyond what has been labeled as Forward Deployed Engineering." Microsoft also named FDE partnerships with Accenture, Capgemini, EY, KPMG, and PwC.

The Pragmatic Engineer's survey of FDE programs counted "more than 10" FDEs at OpenAI across eight cities, and around 15 at Ramp. Palantir remains the largest employer of the role by a wide margin.

So Microsoft alone is staffing 6,000 seats against a proven population measured in dozens, and everyone else is bidding into the same shortage. An enterprise that opens a requisition competes on compensation against private-lab equity and on interest against the work these engineers already want.

The Trap of The Isolated Internal FDE

Suppose you hire an FDE. Do you have the right operating model around them?

They have nothing to build into

The first question Krishnaswamy asks about any FDE program is whether "the entire organization is really built to support the forward deployed engineering modality.”

Without a product team receiving what the FDE learns, every engagement ends in a bespoke artifact and the work never compounds. Loh found FDEs in different business units solving near-identical problems without knowing about each other, "leading to duplicated efforts and missed opportunities to fix deeper, systematic issues."

The island

Three years in, Loh's verdict was that "FDEs often felt like they were on an island. Technical mentorship was inconsistent, handovers lacked clarity, and spending most of their week away from central tech made them feel unsupported."

His fix was that every FDE now sits inside a virtual, part-time pod of a manager, a tech lead, and often an engineer, which answers who owns career development and technical guidance while the FDE is in the field.

Nobody is providing top cover

An FDE working alone inside a business unit has no political protection. Krishnaswamy is direct about the consequence: "you could have the best FDEs in the world, they won't be able to actually get access to the problems or have the protection to be able to constructively break some rules to be able to get the outcomes."

That cover comes from named people, usually an executive sponsor on the business side and a product lead internally. 

Everything they ship becomes something to maintain

Loh's third finding catches programs around 18 months in. "Every full-time FDE meant a backfill gap on a product team, and every quick-win solution became an asset someone had to maintain."

One engineer producing a dozen small internal tools a year creates a support obligation nobody staffed. Loh's answer was to push FDEs toward features on existing flagship products, trading slower time-to-market for something the organization can keep.

How Does An FDE Pod Create Value?

It starts with direct context. Loh's first success factor was "direct context over relayed specs," the difference between watching someone work through a clunky interface in real time and reading a sanitized ticket three weeks later. 

Proximity produces continuous iteration against reality instead of one build against assumptions. That becomes a shipped workflow change, then a measured outcome. His practice now saves north of 10,000 hours a year, and he rates the improved trust between operations and technology as the more valuable result. 

The last link is generalization, where what worked in one business unit gets pulled back into the platform so the next engagement starts further along.

The value chain is short, and it only pays out if every link holds. The reduction of delivery timelines is a downstream effect of that chain.

Two things multiply the chain. The first is tooling. "An FDE can be only as effective and fast as the tools in their hands," Loh writes of the low-code tools, developer platform, and agent builder his team assembled. 

The second is AI-assisted execution. IBM's Debbie Vavangas argues that as AI absorbs scaffolding, test generation, and deployment orchestration, "the primary constraint is no longer development capacity. It is the ability to make sound technical and business decisions quickly." An embedded engineer with real context relieves this constraint, which is why the model is now the default shape for getting autonomous agent squads into production.

Palantir's numbers show what the loop is worth. In the Q1 2026 shareholder letter, Alex Karp reported revenue per employee of $1.5 million annualized, $1.6 million in the US, "in light of a sales headcount that is smaller now than it was even two years ago."

What Does a Working FDE Pod Contain?

Palantir pairs its embedded engineers with a second role. The Delta builds; a deployment-side counterpart, carries the domain knowledge, the stakeholder relationships, and the adoption problem. 

Adapted for a partner engagement, the working unit has four parts:

1. One or two embedded engineers with production access and a seat in the business unit's meetings.

2. A domain lead who owns stakeholder alignment, adoption, and the definition of done.

3. A back line, meaning a product team that receives generalizations and turns repeated patterns into platform.

4. Engineering supervision tethered to the technical organization rather than the business unit, which is how Loh's practice keeps field work from "quietly drifting into shadow IT."

IBM puts the effective size at two to five engineers with end-to-end responsibility, sized to "reduce the number of places where work pauses because ownership is fragmented."

Match the engagement shape to the problem. Loh runs two: a 12-to-18-month embed for ambiguous problem spaces that need real discovery, and a three-to-six-month scoped engagement where the problem is understood and the work is execution. Defaulting to the intensive option every time is how practices burn out.

One caution, because it is the honest risk of the partner route. An FDE partner that stops pushing work back into product is basically a consultancy. Ask any partner what they built last year that started as one client's problem and ended up in their platform.

Build, Partner, or Global SI?

What Do FDEs Need To Succeed?

An executive sponsor has to provide top cover in writing, with authority to override a business unit that would rather not be helped. 

Access to production data has to be settled before the engagement starts rather than negotiated during it, because an FDE without data access is an expensive observer. 

The definition of done has to be a business outcome with a number attached, not a shipped feature.

IP and model governance need resolving up front. Microsoft made this its stated non-negotiable when it launched Frontier Company: a customer's data, IP, and competitive advantage should not be "used to train models in ways that commoditize what differentiates them in their industry." Any partner should answer that without an escalation, along with whether you can run different models for different workloads.

Agree on measurement before anyone starts. Gartner research quoted by IBM proposes lead time to deploy, escaped defects, deployment frequency, delivery margin, percentage of work automated by agents, and time to first value. The same research predicts that "by 2029, 80% of enterprises will actively prioritize talent density over talent mass.”

Why Forward Deployed Engineering May Be The Future of Agentic AI Adoption

One of Krishnaswamy's key observations is that it’s “less about the forward deployed engineer, and more about the verb, forward deployed engineering." The value lives in the operating model rather than the job title, which is why you can’t just hire one person, give them the FDE title and be done with it.

So the question changes from who to hire into how to build an organization where FDEs can succeed. This means giving FDEs a product team on the receiving end, an executive willing to spend political capital, tooling that compresses a week's work into a day, and measurement agreed before the first sprint. 

Enterprises that assemble those pieces can absorb an FDE pod and grow their own capability from it. The ones that only open a requisition spend a year discovering the rest of the list.