The Forward Deployed Engineer: Why Everyone Is Hiring One, When You Actually Need One, and How to Spot a Fake

The first time someone introduced me as a “forward deployed engineer,” I had been doing the job for years without the title. I was the person who sat with the client’s team, figured out what they actually needed, built it inside their stack, and stayed until it ran on a Monday morning without me. In 2026 that job description became the hottest title in tech. That is good for people who do the work — and a problem for everyone trying to hire them.

My argument is this: the forward deployed engineer is a structural response to AI products that only create value once they are wired into a customer’s systems — and most companies now hiring one actually need a solutions engineer, an integration engineer or a better product instead. The role is not a fad. But it is expensive, scarce and easy to fake, and hiring one to paper over the wrong problem is one of the most costly mistakes an AI company can make this year.

This article works through the case in order. It starts with the market — why postings exploded and where the money is going. It then looks at the origin and economics of the role, from Palantir’s “Deltas” to the margin-for-moat argument, and at what the supply data really says. It sets out a model of what the job actually consists of, then goes deep on four practical questions: when to hire one, how to spot a fake, how to interview and score candidates, and how to structure an FDE team so it does not quietly turn into an unprofitable consultancy. After a handful of public cases, it takes on the three strongest objections, spells out the implications for founders, hiring managers and engineers, and closes with a 90-day action plan and an honest list of what the evidence cannot tell us.

Context: why this matters now

The numbers are startling even by AI-boom standards. Lightcast data reported by Fortune shows forward-deployed engineer postings up more than 1,000% in January–August 2026 versus the same period a year earlier — and more than 4,600% versus 2023 — while the overall tech job market grew 13%. Microsoft, Meta, Google, OpenAI and Anthropic were all hiring, and Palantir alone had around four dozen open FDE roles.

Exhibit 1

Forward deployed engineer>1,000%

All tech job postings13%

FDE figure reported as 'more than 1,000%'; shown at 1,000% as a floor. Growth is from a small base.

Source: Lightcast data via Fortune, 3 Sep 2026

View data table

Segment	Posting growth, Jan–Aug 2026 YoY
Forward deployed engineer	>1,000%
All tech postings	13%

The money followed. The median advertised FDE salary in the same data is over $188,000, against about $145,000 for traditional software engineers, with some frontier-lab roles reaching $400,000. Anthropic’s London FDE posting advertises £225,000–255,000. And supply has not caught up: a Gartner analyst estimates only around 2,000 engineers today genuinely fit the role — and that the industry could absorb four times that.

Exhibit 2

$188Kmedian advertised FDE salaryLIGHTCAST · DICE · 2026

$145Kmedian for traditional software engineersLIGHTCAST · DICE · 2026

~2,000engineers estimated to genuinely fit the FDE role todayGARTNER · OCT 2026

4×how many more the industry could absorb, per the same estimateGARTNER · OCT 2026

Salaries are advertised medians, not realised pay. The supply figure is an analyst estimate; its method is not published.

Source: Lightcast/Dice via Fortune (salaries); Gartner via Channel Dive (supply)

Why now? Because the product changed shape. A chatbot that answers questions can be sold as a subscription. An agent that files a claim, updates a ticket or reconciles an invoice has to be connected to the systems where claims, tickets and invoices live — with the right permissions, on the right data, inside the customer’s security rules. Lightcast found that agentic-AI skills went from 0.06% of US job postings in 2024 to 0.23% in 2025. Every one of those agents needs somebody to wire it in. That is the structural demand behind the title, and it is why the largest AI companies have moved from hiring individual FDEs to building whole deployment businesses.

Exhibit 3

1. EARLY 2010sPalantir creates the roleEngineers embedded with customers, internally called “Deltas”; until about 2016 they outnumbered regular software engineers.
2. 2016Palantir launches FoundryMany FDEs move into core product engineering as field work becomes a platform.
3. EARLY 2025OpenAI stands up an FDE teamStarts with two engineers; more than ten by mid-2025, per The Pragmatic Engineer.
4. JUN 2025a16z: “the hottest job in startups”Argues services-led growth trades gross margin for a moat.
5. MAR 2026Salesforce triples its Agentforce FDE teamIn six months; 40–50% of moves into the role are internal transfers.
6. MAY 2026OpenAI launches the Deployment Company$4B from 19 firms; agrees to acquire Tomoro for a base of about 150 FDEs.
7. JUN 2026AWS commits $1B to a forward deployed unitStarting with hundreds of engineers on fixed, outcome-based pricing.
8. OCT 2026Anthropic launches Claude Frontier AcademyA $100M commitment to train 10,000 “Frontier Deployed Engineers” at partner firms by end of 2027.

Source: The Pragmatic Engineer; a16z; Salesforce; Constellation Research; Fortune; Anthropic

Origin and economics: why the role exists at all

The FDE is not new. Palantir created it in the early 2010s, and internally the engineers were called “Deltas”. The Pragmatic Engineer’s account of the role captures the distinction neatly: a Palantir product developer works on “one capability, many customers”; a Delta works on “one customer, many capabilities.” Until around 2016, Palantir employed more FDEs than conventional software engineers. Then it launched Foundry, and many of those FDEs moved into core product engineering.

That sequence is the whole economic logic of the role in miniature. Palantir’s customers — government agencies and large enterprises with messy, sensitive, siloed data — could not get value from software that was not integrated into their environment. So Palantir sent engineers to do the integrating. Those engineers saw the same problems repeat across customers, and the repeated solutions became a product. The FDE was not the business model; it was the research and development function for the business model, paid for by customers.

The margin-for-moat trade

Venture firm a16z made this argument explicit in June 2025. Implementation-heavy software companies start with lower gross margins and higher burn because every customer needs customisation. But once a company owns the place where a customer’s data and workflows enter the system, it gains a moat — the ability to raise prices and build a partner ecosystem — and margins rise over time. a16z’s examples were ServiceNow, which went public with a 63.2% gross margin and reported 79% in 2024, and Workday, which went from 54.1% to 75%.

Exhibit 4

Two companies chosen by a16z to illustrate its argument — not a representative sample. Survivorship bias applies: companies whose margins never recovered are not shown.

Source: a16z, Trading Margin for Moat (4 Jun 2025)

View data table

Company	Gross margin at IPO	Gross margin 2024
ServiceNow	63.2%	79%
Workday	54.1%	75%

The a16z piece also offered a useful snapshot of how seriously the frontier labs took this: at the time of writing, 22 of the 311 open roles on OpenAI’s careers page were in forward deployed or solutions engineering — roughly one in fourteen jobs at the company most associated with the model itself.

Exhibit 5

22 of 311OpenAI open roles in forward deployed or solutions engineering at the time of a16z’s count

22 of 311 open roles, about 7%. A point-in-time count of a careers page, not headcount.

Source: a16z, Trading Margin for Moat (4 Jun 2025)

Notice what the economics require. The trade only works if the field work flows back into the product. A company whose FDEs build bespoke code for each customer, with no route back to a shared platform, is not trading margin for moat. It is running a consultancy with software-company expectations — and it will not get software-company margins.

The evidence: demand is real, supply is thin, and the gap will be filled with titles

Three things are true at once, and the nuance matters for anyone hiring.

Demand is concentrated and well-funded. The postings growth in Exhibit 1 is real, but the more telling signal is capital. In May 2026 OpenAI launched the OpenAI Deployment Company with more than $4 billion from 19 investment firms, consultancies and systems integrators, led by TPG, and agreed to acquire the applied-AI firm Tomoro to give it a base of about 150 forward deployed engineers. In June 2026 AWS committed $1 billion to a forward deployed engineering unit starting with hundreds of engineers. In October 2026 Anthropic committed $100 million to train 10,000 “Frontier Deployed Engineers” at partner firms including Accenture, Bain, Capgemini, Deloitte and McKinsey by the end of 2027.

Supply is thin. Set those commitments against Gartner’s estimate of about 2,000 engineers who genuinely fit the role today, and an absorbable market of roughly four times that.

Exhibit 6

Tomoro team (OpenAI)~150

Genuine FDEs today (Gartner)~2,000

Absorbable demand (Gartner, 4×)~8,000

Anthropic training target10,000

Different kinds of number, shown together to make one point. The 8,000 figure is derived from Gartner’s “four times” estimate. The 10,000 is a training target, not trained engineers. Tomoro’s ~150 is an acquired team.

Source: Gartner via Channel Dive (pool, absorbable); Anthropic (training target); Constellation Research (Tomoro)

View data table

Measure	Engineers
Tomoro team acquired by OpenAI (May 2026)	~150
Engineers who genuinely fit the role today (Gartner)	~2,000
Market the industry could absorb (Gartner, 4×)	~8,000
Anthropic training target by end-2027	10,000

The gap will be filled with titles. When demand outruns genuine supply by this margin, two things happen. Companies rename existing roles — solutions engineers, sales engineers, technical account managers — as FDEs to compete for candidates. And candidates rename themselves. The Pragmatic Engineer lists Agent Engineer, Solutions Architect, Sales Engineer and Technical Delivery Engineer as titles for similar roles, and notes that some companies use FDEs mainly to help close deals while others treat the job as technical consulting. The word now covers several different jobs. That is precisely why the rest of this article focuses on function rather than title.

A caution on the data: the 1,000% growth figure is from a small base, so even large percentage swings involve modest absolute numbers. The Gartner estimate is a single analyst’s view with no published method. And the capital commitments are company announcements — intentions, not outcomes.

A framework: what the job actually consists of

Strip away the hype and the job is a loop. I describe it in six steps, and the sixth is the one most job descriptions leave out.

Exhibit 7

1. 01DiscoverFind the real problem behind the brief: the process, the data, the people, the constraint.
2. 02ScopeCut to something shippable that moves one number the customer already tracks.
3. 03Build in placeIntegrate with their identity, data and approval systems — on their infrastructure.
4. 04HardenSurvive real traffic: rate limits, odd formats, permissions, the first complaints.
5. 05Hand overRunbooks, training, monitoring; someone else operates it now.
6. 06Feed the productTurn what repeated into a feature, a connector or a template.

Framework by the author. Step 6 is the one that makes the economics in Exhibit 4 possible.

Each step has a characteristic failure. Discovery fails when the engineer builds what was asked for rather than what was needed. Scoping fails when nothing is cut. Building fails when the engineer works on a laptop with sample data instead of inside the customer’s environment. Hardening fails when the system is declared done at the demo. Handover fails when the FDE becomes a permanent part of the customer’s operations team. And product feedback fails silently — no one notices, until the third customer needs the same connector built from scratch.

OpenAI’s description of its own FDE process, as reported by The Pragmatic Engineer, maps closely onto the first five steps: a couple of days of early scoping on site, prototyping with synthetic data; a validation phase built around evaluations, with results reported before delivery; then delivery with engineers on site a few days a week. Its FDE team also contributes to OpenAI’s Agents SDK — step six in practice.

Deep dive 1: when you actually need one (and when you don’t)

Most companies hiring FDEs in 2026 need one of three other roles instead. The test is two questions: How ambiguous are your customers’ problems? And how hard are their environments to integrate with?

Exhibit 8

Solutions consultantAmbiguous problems, standard environments — discovery and configuration, light code

Forward deployed engineerAmbiguous problems in complex environments — scope, build, harden, own the outcome

Customer success / supportClear problems, standard environments — enablement and playbooks

Integration / solutions engineerClear problems, complex environments — connectors, data pipelines, SSO

Integration difficulty →Problem ambiguity →

Framework by the author.

The mechanism. Ambiguity determines how much discovery the work needs; integration difficulty determines how much engineering it needs. An FDE is the expensive combination of both. If your product is mature and every customer wants roughly the same thing, an FDE will be bored and expensive. If your customers want wildly different things but run on clean SaaS, a strong solutions consultant will move faster. If they want the same thing but run on a tangle of legacy systems, an integration engineer with good connectors is the answer. You need an FDE when both axes are high — usually regulated, data-heavy enterprises where the AI only creates value once it touches their systems of record.

How to place yourself honestly. Take your last ten closed or lost deals and answer four questions for each. Did the customer’s stated problem change materially during the sale or delivery? Did delivery require access to the customer’s internal systems — identity, data warehouse, ticketing, document stores — rather than an upload? Did someone write code that ran on the customer’s infrastructure? And did that code, or a generalised version of it, later ship to another customer? If most deals score yes on the first two, you are in the top-right quadrant. If most score yes on the first only, you are top-left.

The failure mode. The most expensive mistake I see is hiring FDEs to compensate for an immature product. Every deal needs heroics, so the company hires heroes — and the heroics become permanent, because no one has time to turn them into product. The symptom is the fourth question above scoring no: field work that never ships twice. If that is you, the hire you need is a product engineer, and the FDE budget is better spent fixing onboarding.

How to measure whether it is working. Three numbers, tracked per customer: time from contract to the first production use; whether the system is operated by the customer without the FDE after handover; and the share of custom work that became a shared feature, connector or template within two quarters. The third number is the one that tells you whether you are building a moat or a consultancy.

Deep dive 2: how to spot a fake

A tenfold jump in postings guarantees a wave of rebranded résumés. The tells are consistent.

Exhibit 9

	Real FDE	Résumé FDE
Describes past work as	A customer, a constraint, a shipped system, a number that moved	A tech stack and a list of models used
When asked “what broke?”	A specific incident, the root cause, the fix, the guardrail added	“It went smoothly” — or a story about a demo
On scoping	Explains what they cut, and why the client agreed	Built everything the client asked for
On environments	Names identity, networking, data-residency and approval hurdles	Assumes an API key and a notebook
On evaluation	Describes the test set, who labelled it, and the threshold for go-live	Quotes a benchmark score for the model
On handover	Runbooks, training, who operates it now	No answer — they were never there after launch
On the product	Can name something they built that later shipped to other customers	Every engagement was a one-off
Evidence	Can walk you through a real deployment (redacted)	Shows a polished demo or a tutorial repo

Framework by the author.

The mechanism. Faking is easy because the vocabulary is public. Anyone can learn to say “retrieval”, “agents” and “evals”. What cannot be learned from a course is the texture of production: the permission error that only appears for one department, the PDF format nobody mentioned, the rate limit that only bites at month-end. Real FDEs carry that texture in their stories. Their answers get more specific under follow-up questions; a fake’s get more general.

The single best question I know: “Tell me about the first week after go-live.” People who have done the job light up — that week is where rate limits, permission errors, unexpected document formats and the first user complaints arrive. People who haven’t done the job describe the launch.

The failure mode on the hiring side is over-correcting into “only hire people with the exact title.” Given the supply numbers in Exhibit 6, that pool barely exists. Salesforce’s experience is instructive: 40–50% of its FDE moves were internal transfers, and it says it values curiosity over credentials. a16z gives the same advice — hire for high agency, curiosity and “a healthy disregard for the status quo” rather than advanced degrees. The goal of spotting fakes is not to find people with the title; it is to find people with the behaviour, whatever they were called before.

Deep dive 3: how to interview and score

LeetCode tells you almost nothing here. Run an interview that looks like the job, and score it against explicit anchors so that the panel is measuring the same thing.

Exhibit 10

1. 01Deployment walkthroughCandidate walks through one real deployment: the brief, the constraints, what broke, the numbers.
2. 02DecompositionGive a vague business problem; they turn it into a scoped MVP and say what they would cut.
3. 03Stakeholder role-playAn interviewer plays a sceptical client owner. Watch how they handle pushback.
4. 04Integration take-homeConnect two systems that were not designed to talk, with messy data. Keep it small.
5. 05Debrief on failureAsk what they would monitor in week one and what they expect to break.

	Tested in	Score 1	Score 3	Score 5
Scoping judgement	Decomposition	Builds everything asked for	Cuts scope when prompted	Cuts unprompted, ties the MVP to one number the customer tracks
Production depth	Walkthrough, debrief	Describes the demo	Names generic risks	Names specific incidents, root causes and guardrails added
Integration skill	Take-home	Works only on clean inputs	Works, with brittle assumptions	Handles messy data, fails loudly, documents the edges
Stakeholder handling	Role-play	Concedes or argues	Holds position politely	Reframes the objection around the customer’s goal and agrees a next step
Ownership	All stages	Done means merged	Done means deployed	Done means someone else is using and operating it
Evaluation instinct	Walkthrough, take-home	No test set	Spot checks	A labelled test set and a go-live threshold agreed with the customer

Framework by the author. Score each dimension 1, 3 or 5 using the anchors; a 1 on judgement or ownership should be disqualifying regardless of the total. The table scrolls sideways on small screens.

Why these stages. Each one tests a step of the loop in Exhibit 7. The walkthrough tests whether the candidate has done the full loop before. Decomposition tests discovery and scoping, and is the stage I weight most heavily: the ability to turn “we want AI for claims” into a scoped, measurable first release is the rarest skill in the role. The role-play tests whether they can hold a scope under pressure without losing the relationship. The take-home tests building in place. The debrief tests hardening and handover.

Palantir’s own postings ask for engineers who own work end to end with minimal supervision and can talk to customer executives, with 25–50% travel; Anthropic’s ask for four or more years in technical customer-facing work, production LLM experience — prompting, agents, evals — plus high agency and low ego, with similar travel. Both are describing the same person: an engineer whose definition of “done” is the customer is using it, not the PR merged.

The failure mode. Two common ones. First, letting the take-home grow into unpaid consulting — keep it to a few hours and use synthetic data. Second, scoring on charisma: the role-play rewards confident talkers unless the rubric forces the panel to score the substance of the reframe. Write the anchors down before the first interview, not after.

Deep dive 4: building and structuring an FDE team

Hiring the right people is half the problem. The other half is putting them in a structure that keeps the economics in Exhibit 4 working. Companies that have done this publicly share one pattern: field work is always paired with a route back into product.

Exhibit 11

	Palantir	OpenAI	Ramp	Salesforce	AWS
Scale (as reported)	Still the largest FDE employer	Two engineers growing to more than ten (2025)	About 15 FDEs (2025)	Agentforce FDE team tripled in six months (2026)	Starting with hundreds (2026)
Time with customer	About 25% on site	On site a few days a week during delivery	Not public	Not public	Engagements of about 45 days
Route back to product	FDEs alternate with core product work; Foundry absorbed field work	Team contributes to the Agents SDK	FDEs embedded in core product engineering teams, in pods	Not public	Not public
Talent source	Hires from about one year post-college	Led by a former solutions architect	Prefers 5+ years for senior FDEs	40–50% internal transfers; six-week onboarding	Not public
Commercial model	Not public	Not public	Not public	Not public	Fixed, outcome-based pricing rather than billable hours

As publicly described by the companies or by reporting on them; not independently verified. The table scrolls sideways on small screens.

Source: The Pragmatic Engineer (Palantir, OpenAI, Ramp); Salesforce News; Constellation Research (AWS)

From those public patterns and my own delivery work, here is how I would structure an FDE function. This is my design, not an industry standard.

Pods, not lone heroes. Organise FDEs in pods of two to four, each paired with a named product engineer who owns the route back into the platform. A lone FDE at a customer is a single point of failure and has no one to generalise with. A pod can rotate people between customers without losing context, and the product liaison makes step six of the loop someone’s actual job. Ramp’s pods embedded in product engineering teams, and Palantir’s practice of alternating FDEs between customer and product work, are two versions of the same idea.

Keep FDEs off sales quotas. a16z is blunt about this: implementation leads rarely want a quota, and quotas drive counterproductive behaviour. An FDE on a quota is incentivised to promise scope that closes the deal and then live with it. Instead, tie FDE incentives to account outcomes — production adoption, retention, expansion — and align them closely with account executives without making them salespeople.

Measure the moat, not the hours. Track, per pod, the three numbers from Deep dive 1 — time to first production use, operated-without-FDE after handover, and the share of custom work absorbed into product. Add one more at the company level: the ratio of FDE effort to new annual revenue, watched over time. If that ratio is not falling as you add customers in the same segment, the field work is not compounding.

Build a career ladder that rewards handover. Without one, your best FDEs burn out on travel or leave for product roles — and the ones who stay are rewarded for becoming indispensable to a customer, which is the opposite of what you want. A workable ladder has four rungs. An FDE I delivers scoped work inside an engagement someone else leads. An FDE II leads an engagement end to end, including handover. A senior FDE leads multiple engagements and turns repeated work into product. A staff FDE or pod lead owns a segment — its playbooks, its connectors and its product roadmap input. Promotion evidence at every rung should include something a customer now runs without you, and above FDE II, something another customer now uses because you built it once. Make lateral moves into product engineering a celebrated path, not a defection: it is how Palantir turned field knowledge into Foundry.

Sell narrowly. a16z’s first recommendation is to choose customers with commonalities and start with narrow scope. Field work only compounds when the next customer resembles the last one. An FDE team spread across five unrelated industries learns five lessons once.

Case examples

Palantir: the field becomes the platform. For its first decade the FDE was Palantir’s core delivery model, and FDEs outnumbered product engineers until around 2016. Foundry’s launch that year moved many of them into core product engineering, and The Pragmatic Engineer reports that FDEs still alternate between customer embedding and product work. The lesson: the FDE function is most valuable when it is designed to make itself partly unnecessary — when the patterns it discovers become product.

OpenAI: a small team with a defined process. OpenAI’s FDE team began with two engineers in 2025 and grew past ten, working from eight cities across three continents. Its engagements run through scoping, eval-based validation and delivery, and The Pragmatic Engineer cites a John Deere project in Iowa that scaled personalised interventions for farmers in time for the growing season. By May 2026 the company had moved from a team to a business — the $4 billion Deployment Company, seeded with about 150 engineers from Tomoro. The lesson: when integration becomes the constraint on revenue, even model companies end up in the services business, and they formalise it fast.

Salesforce: growing the role from the inside. Salesforce tripled its Agentforce FDE team in six months, filled 40–50% of the moves internally, and built a six-week onboarding programme. The lesson: with a market pool of roughly 2,000 genuine FDEs, the scalable source of talent is your own engineers and solutions staff who already know your product — given a structured path, rather than a new title.

AWS: pricing the outcome, not the hours. AWS’s $1 billion unit, announced in June 2026, prices engagements on a fixed, outcome-based basis rather than billable hours, around a methodology of roughly 45-day engagements. The lesson: the cleanest answer to “isn’t this just consulting?” is a commercial model in which the vendor, not the customer, bears the cost of slow delivery — which forces the field work to become repeatable.

Counterpoints

Implications by stakeholder

Exhibit 12

	Founders and CTOs	Hiring managers	Engineers who want to become FDEs
The question to ask	Is integration the real constraint on our revenue — or is the product immature?	Which quadrant of Exhibit 8 is this role really in?	Can I show a system I built that someone else now operates?
The mistake to avoid	Hiring heroes to hide product gaps	Hiring by title from a pool of ~2,000	Collecting AI certificates instead of deployments
What to measure	Share of custom work absorbed into product; FDE effort per unit of new revenue	Rubric scores with written anchors; time-to-productivity of new FDEs	Before-and-after numbers from a real user; incidents handled
Where to find leverage	Narrow segment, outcome-based pricing, pods tied to product	Internal transfers from engineering and solutions teams	Your current employer’s messiest integration problem
First move	Run the four-question test on your last ten deals	Rewrite the job spec around the six-step loop	Ship one integration end to end and write up what broke

Framework by the author. The table scrolls sideways on small screens.

For founders and CTOs

Your decision is not “should we have FDEs?” but “is integration the binding constraint on our revenue?” If it is, FDEs are an investment in learning where your product must go, and you should structure them so that learning reaches the roadmap. If it is not — if deals stall on product gaps, pricing or trust — FDEs will mask the problem at a high cost. The commercial lesson from AWS is worth considering early: pricing on outcomes rather than hours aligns your incentive to make deployments repeatable.

For hiring managers

Write the job specification around the loop in Exhibit 7, not around a list of frameworks. Recruit from inside first — your own engineers and solutions staff who know the product and have shown customer instincts — and use the rubric in Exhibit 10 to make the bar explicit. Budget for onboarding: Salesforce runs six weeks. And protect your FDEs from quotas and from becoming permanent members of a customer’s operations team.

For engineers who want to become FDEs

The bar is not a title; it is a system running in someone else’s environment, and a story about how it broke. Experience requirements vary widely — Palantir hires about a year out of college, Ramp prefers five or more years for senior FDEs, Anthropic asks for four or more years customer-facing — so the realistic route for most engineers is to volunteer for the messiest integration work at their current employer, see it through handover, and measure the result. Expect 25–50% travel at many companies, and be honest with yourself about whether you want that.

What to do next: a 90-day plan

For a founder or engineering leader deciding whether, and how, to build forward deployed capacity:

Days 1–30: diagnose.

1. Run the four-question test from Deep dive 1 on your last ten deals, and place your company on the matrix in Exhibit 8.
2. List every piece of custom work delivered in the past year and mark which pieces were reused for a second customer.
3. If you are not in the top-right quadrant, stop here and hire the role your quadrant points to — or fix the product gap that is stalling deals.

Days 31–60: pilot one pod.

1. Staff one pod of two to three engineers, ideally including at least one internal transfer, paired with a named product engineer.
2. Assign it to two customers in the same segment.
3. Agree three metrics before work starts: time to first production use, handover completed, and custom work absorbed into product.
4. Keep the pod off quotas; tie its incentives to those customers’ adoption.

Days 61–90: decide.

1. Compare the second deployment’s effort with the first. If it was not materially cheaper, find out why before hiring more.
2. Write the career ladder and the interview rubric based on what the pilot taught you.
3. Decide to scale, restructure or stop — and write down the evidence for the decision.

For an engineer aiming at the role, the 90 days are simpler: pick one real integration problem at your current job, take it from discovery through handover, measure the before and after, and write a one-page account of what broke. That document is a better application than any certificate.

Limitations and methodology

• Postings growth is from a small base. A 1,000% increase in a niche title involves far fewer jobs than a 13% increase across all of tech. Postings also overstate hiring in a hot market.
• Titles are inconsistent. Different companies use “forward deployed engineer” for pre-sales, delivery and consulting roles. Growth in the title partly reflects relabelling of existing jobs.
• The supply estimate is opaque. Gartner’s figure of about 2,000 genuine FDEs is one analyst’s estimate reported secondhand; its method is not public. I use it for order of magnitude only.
• Salary data is advertised and US-centric. Medians from job ads are not realised compensation, and pay outside the US differs.
• Company accounts are self-reported. The Salesforce, OpenAI, AWS and Anthropic figures are the companies’ own descriptions or reporting on them. Commitments are intentions, not outcomes.
• The margin evidence is illustrative. a16z is an investor with an interest in services-led startups, and its two margin examples are survivors. Companies whose margins never recovered are invisible in that data.
• My frameworks are mine. The quadrant, the six-step loop, the rubric and the team design come from my own delivery work. They are tools for thinking, not validated instruments, and they have not been tested across a large sample of companies.

The behaviour outlasts the title

The forward deployed engineer exists because AI products that act inside a business only create value once someone wires them into that business — its data, its identity systems, its approvals, its odd document formats. That is a structural fact, and it is why the role has survived at Palantir for well over a decade and why the largest AI companies are now building deployment businesses around it. But structural demand for a function does not mean every company needs the title. Most need a solutions consultant, an integration engineer or a better product, and the ones that do need FDEs need them organised so the work compounds.