What an FDE Is, and Isn't

The definition, from the people who hire

Start with the employers, because they are the only people who have written the job down. Read what follows as primary evidence of what employers ask for and as T4 evidence of how the work is done: a post describes the job a company hopes to fill.

OpenAI's San Francisco posting, published on 11 September 2026, is the clearest single statement. FDEs "lead complex end-to-end deployments of frontier models in production alongside our most strategic customers", and the hire "will own discovery, technical scoping, system design, build, and production rollout". Success is measured "through production adoption, measurable workflow impact, and eval-driven feedback that changes product and model roadmaps" (OpenAI, FDE – SF; T4). Read that list as a sequence, from finding the problem to running the system. None of the success measures is "shipped a feature" or "closed a deal"; all three are true only once the customer is using the system.

Anthropic's Staff FDE posting, published on 14 October 2026, puts the same idea in one line: "Customers bring you in to lead, not only to implement: you decide what should be built, and then make sure it gets built well." The same post asks the FDE to "deliver production systems the customer can operate" and to "hand over systems the customer can run" (Anthropic, Staff Forward Deployed Engineer; T4). That gives two ends of the job. At the front, the FDE decides what to build. At the back, the customer runs it without the FDE.

The most useful sentence in these postings is a negative one. OpenAI's healthcare FDE posting, published on 6 August 2026, asks the hire to "Own the technical solution end to end, from customer discovery and workflow scoping through architecture, hands-on implementation, evaluation, production deployment, adoption, and handoff". Then it adds: "This role owns the technical solution; ownership of the commercial or executive relationship is not required" (OpenAI, FDE Healthcare – Seattle; T4).

That sentence draws the line this chapter uses. Owning the outcome is not the same as owning the account. The account executive owns the commercial relationship: the contract, the renewal and the price. The FDE owns whether the thing works in the customer's business. The two overlap at the sponsor, and they can be held by different people without the FDE becoming any less of one. What the FDE can't hand away is any stage between the problem and the running system.

So here is the definition, in this book's words. An FDE owns the customer's outcome across discovery, scoping, build, production and handoff, and writes the code as the means of getting there. Take away the front, and you have someone who builds what they are told. Take away the back, and you have someone who leaves before it works. Take away the code, and you have an advisor. Each of those is a real, often well-paid job. None of them is this one.

Five stages and a loop: what "owning" means at each

"Own" is the most abused word in job posts, so pin it down. At each stage, owning means holding a decision, not attending the meeting where someone else makes it.

• Discovery. You decide what the problem is. The customer's request is a hypothesis, and the FDE is the one who tests it against the real workflow. If the problem arrives already decided, on a ticket, you don't own discovery. Discovery is the chapter on doing it.
• Scope. You agree the success metric, its threshold and the "not now" list with the person who signs. If someone else sets the number and you are asked to hit it, you don't own scope. See Scoping and the First Win.
• Build. You write the production code, in their environment, and you make the architecture calls. Designing it for a partner or the customer's team to build is a different job, discussed below.
• Production. You stay until it runs on real traffic against the agreed threshold, through the security review and the eval climb. Leaving at the demo is the easiest way to stop owning the outcome while keeping the title.
• Handoff. You decide when the customer's team can run it without you, and you prove it. Production and Handoff calls this an acceptance test the customer's operators pass without you.

Then there is the loop. What the FDE learns in the field goes back to the product. OpenAI asks its FDEs to "Codify working patterns into tools, playbooks, or building blocks that others can use" (SF posting, T4). Decagon's Engineering Lead for Strategic Deployments, posted on 31 July 2026, is to "decide what Decagon should build, ship it, and productionize it so it benefits every customer, not just this one" (Decagon; T4). The loop isn't a sixth stage of the engagement. It is what makes the engagement worth the vendor's money, and Feeding the Product argues that it is what separates an FDE from a contractor. Keep it on the checklist.

Why insist on the code? Because the code is where the decisions turn out to be true or false. An advisor can recommend propose-only routing, a deterministic rule outside the model and a read-only identity. An FDE has to make those choices survive the customer's data, infrastructure and reviewers, and finds out in the process which ones were wrong. Salesforce's FDE director, Sarah Khalid, calls coding "table stakes", and its VP Ruth Hickin describes the FDE as "hacker meets customer value meets professional services person" (Salesforce, March 2026; T4, a company describing its own team). Code doesn't define the role, but you can't play without it. Even OpenAI's SF posting is less absolute than its summary: one bullet asks the FDE to "Build full-stack systems", another to "Contribute directly in the code when progress or clarity depends on it". The test is not hours spent coding but whether the production code is yours to write when it matters, or someone else's to write from your design.

One phrase circulates more than any other: the FDE as "startup CTO". Palantir's Forward Deployed Software Engineer posting says "As an FDSE your responsibilities look similar to those of a startup CTO: you'll work in small teams with minimal supervision and own end-to-end execution of high stakes projects" (Palantir, FDSE – US Government; T4). The Pragmatic Engineer quotes a version of it (Orosz, August 2025; T3), and Decagon's post has its lead operate "like the founding CTO of each" deal. Treat the phrase the way this book treats an echo: one company's self-description, repeated until it sounds like a finding. It is a fair summary of the ownership and a poor guide to the day. A startup CTO picks the market. An FDE works inside somebody else's company and its constraints, and plans to leave.

One title, several jobs

The title no longer tells you which job you are looking at. Three kinds of evidence show this, all weaker than they look.

The postings split three ways. Bloomberry analysed about 1,000 FDE job postings, supplied by the jobs-data company Revealera, and sorted them into three types (Bloomberry, November 2025, updated January 2026; T2):

• The "Builder FDE", 60% of posts: a software engineer who embeds with customers to build, deploy and maintain systems in production, with "70-90% coding".
• The "Sales Engineer+", 30%: "a solutions engineer or sales engineer role that got rebranded", which hands off to implementation teams and is marked "quota-carrying" (the article is inconsistent on this; elsewhere it says none of the roles are quota-carrying).
• The "Internal Tools Builder", 10%: "a GTM engineer or RevOps role that definitely shouldn't be called "forward deployed engineer" at all".

Hold that loosely: it is one analyst's classification, and the post describes no coding rules, no second reader and no test of agreement. The split is plausible, but it is not a measurement. What it does establish is that a sizeable share of roles carrying the title drop the build, the production stages or the external customer altogether.

The same company uses "engineer" for different jobs. Anthropic's "Applied AI Engineer, Enterprise" posting in London, published on 28 September 2026, takes enterprise customers "from first conversation, through technical evaluation, proof of value and procurement, to the decision to build". Then: "Once they have decided, you set their systems integration partner up to deliver, agreeing the target architecture and what good looks like, and you stay close as the customer's technical advisor on Claude throughout deployment, while the partner does the build" (Anthropic, Applied AI Engineer, Enterprise; T4). It is an honest description of a different job: by this chapter's test the build belongs to someone else. The posts that blur the line are the problem, not ones like this that draw it.

The job family tells you what the employer thinks it bought. The Chinese market makes this visible because the big employers file the role in different places. iFanr's APPSO column, republished by 36Kr on 29 August 2026, reports that Tencent's three 前线部署工程师 (FDE) postings sit in the product job family and ask for three to five years' experience. ByteDance titles the role "AI FDE 工程师", with no Chinese translation, and files it under R&D, across Feishu, Volcano Engine and its data platform. ByteDance's FDE internships, though, sit under "销售-销售支持", sales and sales support (iFanr/APPSO via 36Kr; T3, a journalist reading job boards). One title, three job families, sometimes inside one company. A posting's department is a better guide to whose targets you will be measured against than its title is. China's pay and the wider market are covered in Part IV, in the chapter on where FDEs work.

Employers also use other titles for the same work: Applied AI Engineer, Agent Deployment Engineer, Deployment Strategist, Forward Deployed Finance Engineer. Some name the non-coding partner role separately: Palantir's job board, read on 17 October 2026, lists Deployment Strategist postings beside its Forward Deployed Software Engineer ones. The error runs both ways. Some FDE-titled roles aren't FDE jobs, and some FDE jobs aren't titled that way. Searching job boards by title will mislead you in both directions.

None of this tells you how people in these roles spend their weeks. No study follows FDEs through engagements and records which stages they own. The evidence is what employers write down: enough to show the title is unreliable, not enough to say how often a job matches its posting.

The neighbours, by what they own

The clearest way to see the FDE is against the jobs on either side of it. Alan Descoins, CEO of the consultancy Tryolabs, gives a two-line test. "A consultant runs a discovery and hands you a strategy, then leaves before a line of code is written." "A contractor builds exactly what is on the ticket, but will not tell you the ticket is wrong and will not stay to see if anyone uses it" (Tryolabs, June 2026; T4, a firm describing its own field). The consultant owns the front without the back. The contractor owns the build without the front, and leaves before the back. The FDE has to own both ends.

The grid below extends that test to the five roles an FDE is most often confused with. It is this book's synthesis, drawn from the postings and sources in this chapter, not a measured finding. Read each row as the typical shape of the job. Any individual post can differ, which is what the checklist in 1.7 is for.

To use the grid on a posting, find the last stage the post gives the hire a duty for, and the verb it uses there. If the duties stop at the "technical win" or the signature, it is a sales engineer's job. If they stop at "architecture" or "advise", it is an architect's. If they stop at a recommendation or a roadmap, it is a consultant's. If the system never leaves the employer's own product, it is an applied AI engineer's. Only a post whose duties run through "production" to "hand over" describes the first row.

Two things fall out of the grid. First, every neighbour is a legitimate job. The FDE isn't better; it is accountable for something none of the others is: whether the system works in the customer's business after the vendor leaves.

Second, the applied AI engineer is the nearest neighbour on skills and the furthest on situation. The technical work is nearly identical. For that half of the job, the wiki's agent evaluation pages cover it. What the applied AI engineer doesn't have to do is find the problem inside another company's politics, work on infrastructure it doesn't control, or design its own departure. Those three things are most of what this book is about.

The sceptics are partly right

There are three serious criticisms of the role. The ownership test explains each one instead of dismissing it.

"It's AI engineering with a new label." Paden Gayle, whose O'Reilly book on the role is in Early Release, argues that "a lot of content labeled FDE is really AI engineering under a different name". He draws the boundary much as this chapter does: in his description, "one engineer owns discovery, scoping, build, deployment, verification, and the customer relationship" (O'Reilly live event page; T4, an author describing his own course). He is right. Most of what circulates under the FDE label teaches the build, the one stage the FDE shares with every AI engineer, which is why this book links to the wiki for the stack and spends its pages either side of it. One disagreement: Gayle puts the customer relationship inside the role. OpenAI's healthcare post explicitly leaves the commercial relationship out. This book sides with OpenAI: the FDE must hold the working relationship with the sponsor, but the deal belongs to sales.

"It's IT services with a better title." In March 2026 Gergely Orosz reported talking to engineers who took FDE roles and were disappointed. One said: "This FDE job was a typical IT services mindset," and "I quit 4 weeks later." Orosz's summary of the complaint is that such FDEs don't do much "software engineering" beyond integrating what the product team built, and "don't contribute back into the platform" (The Pragmatic Engineer, March 2026; T4, two anecdotes relayed by a newsletter). That is two people, not a survey. But the complaint is exact, and the ownership test predicts it. A role with no product loop and no say over the problem is a contractor's job. The engineers weren't disappointed by the FDE job; they got a job that had dropped the stages that make it one. Orosz's earlier piece had already drawn the line in the same place: "The difference comes down to that FDEs work with customers and also contribute to the product their company sells" (Pragmatic Engineer, August 2025; T3).

The same piece quotes Patrick Kellenberger of Betts Recruiting, via the Wall Street Journal: "Everyone wants them and there's only maybe 10% of the market that wants that role" (T4, a recruiter's estimate, relayed twice). Treat 10% as an impression, not a number. The point stands: many engineers who could do the job don't want the travel, the ambiguity, or the customer work, and they are not wrong to say no.

"It's drifting into consulting." In 2026 OpenAI and Anthropic each set up a separate deployment company backed by private-equity money. The cynical reading is that services revenue was too tempting, and the vendors built consultancies with better branding. The ownership test gives a narrower reading you can check. A deployment company can still run FDE engagements, but only if the field work still feeds a product. If it stops, the engineers in it are consultants who write code, and the disappointed hires above describe what that job feels like. Origins and Economics gives the dated facts and both readings. For a job seeker the practical point is short: if the offer comes from a deployment company, line 6 of the checklist below is the one to ask about first.

What the sceptics get wrong is the conclusion some draw: that the role is hype and will fold back into its neighbours. The distance between a capable model and a customer outcome, made of a misread problem, unreachable data, an unplanned review, an unagreed number and an unowned system, is real, and someone has to own it. The sceptics show that many jobs carrying the title don't. They don't show that the distance isn't there.

The composite: who would have dropped what

Part II follows one engagement, at a regional insurer, from the first sales call to the post-mortem. Here is that engagement replayed through the neighbours, to show what each drop would have cost.

The FDE didn't do it alone. The account executive held the contract, the lead negotiated the terms, and the claims director owned the threshold. Owning the outcome doesn't mean doing every task. It means no stage between the problem and the running system belongs to nobody. Each chapter of Part II, from Before the Engagement to When Engagements Fail, is about one place where it would otherwise fall through.

The template: "Is this an FDE job?"

Run this on a real posting before you apply, and again on the offer. It reads the post the way this chapter does: by stage, quoting the text for each answer. Mark each line Y (the post says so), N (it says otherwise) or ? (it is silent). A "?" is not a fail. It is a question for the first interview.

IS THIS AN FDE JOB?                 post: ____________  date: ______
Quote the post for every answer. Y = says so, N = says not, ? = silent

OWNERSHIP, DISCOVERY TO HANDOFF                          Y / N / ?
 1 Discovery: does the role find the problem, or get it   [ ]
   handed over on a ticket?  quote: ________________________
 2 Scope: does it agree scope and success criteria with   [ ]
   the customer?             quote: ________________________
 3 Build: does it write production code itself, or        [ ]
   design for a partner to build?  quote: __________________
 4 Production: does it stay until the system runs on      [ ]
   real traffic?             quote: ________________________
 5 Handoff: is "the customer runs it without you" named   [ ]
   as the end state?         quote: ________________________
 6 Loop: does field work feed the product, by a named     [ ]
   channel?                  quote: ________________________

SIGNALS THAT SHIFT THE READING
 7 Pay shape: base, or a base/variable split? ____________
 8 Team or job family: product / R&D / GTM / sales? _______
 9 Code: required, or "a plus"? __________________________
10 Who else is named alongside (AE, CSM, partner, PM)? ____

READING (take the first rule that matches)
 Mostly ? ............................ ask lines 1, 3 and 5 first
 N on 4-5 and a variable split ....... sales engineer, rebranded
 N on 3, or line 9 says "a plus" ..... strategist or architect:
                                       owns the problem, not the code
 N on 1-2 (problem arrives decided) .. contractor or delivery engineer
 N on 6 .............................. services; ask what happens to
                                       what you learn in the field
 1-6 all Y and code required ......... an FDE job, whatever the title

IF A LINE IS ?, ASK
 1 "Who decided what to build on your last engagement?"
 3 "Whose name is on the production commits?"
 4 "Where were you when it went live, and for how long?"
 5 "Who was running it three months after you left?"
 6 "Name one product change that came from the field."

Here it is filled in for a real posting chosen because it is hard to classify: Harvey's "Forward Deployed Finance Engineer, Buyout" in New York, published on 6 October 2026 (Harvey; T4, read as what the employer asks for).

IS THIS AN FDE JOB?   post: Harvey, FD Finance Engineer, Buyout
                      date: published 2026-10-06, read 2026-10-17

OWNERSHIP, DISCOVERY TO HANDOFF                          Y / N / ?
 1 Discovery                                               [Y]
   "lead discovery, demos, pilots, trainings, onboarding,
   and custom builds alongside our AEs and CSMs"
 2 Scope                                                   [?]
   "running live pilots"; scope and success criteria
   are not mentioned
 3 Build                                                   [?]
   builds "workflows in the firm's own templates and
   formats"; "Python, SQL ... is a plus"
 4 Production                                              [Y]
   "throughout the pre-sales process and stay with
   them well past it"; continues "post-close"
 5 Handoff                                                 [?]
   no end state named; "value compounds after the
   first deal" suggests the role stays on
 6 Loop                                                    [Y]
   "bring deal-team feedback back into the product"

SIGNALS THAT SHIFT THE READING
 7 Pay shape: OTE with a "75/25 Split" (figures in box)
 8 Team: Finance Engineering, beside AEs and CSMs; the
   post names "the pre-sales process"
 9 Code: "a plus"; Excel, modelling and prompting required
10 Alongside: AEs, CSMs

READING
 Not mostly ?. Line 4 is Y, so the sales rule fails.
 Line 9 says "a plus": the strategist rule matches.
 Owns the outcome from discovery onward and feeds the
 product, but the means is configuring the product's
 workflows, not writing production code. The variable
 split and pre-sales work pull toward the deal.
 Verdict: a domain deployment role near the Deployment
 Strategist end. A real job; not an FDE in this
 book's sense. Ask: what does the variable pay for?

The verdict is not a criticism. A former deal professional who builds a buyout fund's diligence workflow in Harvey's product, and carries the fund from pilot to daily use, owns a real outcome. What the checklist exposes is the means. The code is "a plus", so the role sits where Palantir's Deployment Strategist does: owning the problem and the adoption, beside the engineers rather than as one. If you want to write production systems, this post isn't it. If you are a deal professional who wants to turn deal work into product, it may be exactly right. The checklist doesn't choose for you; it stops the title choosing for you. Placing yourself on the four kinds of behaviour the job rewards is the subject of The Skill Map.

Two cautions on using it. First, a post is a hope, not a contract. A Y on paper earns the matching interview question anyway, because an answer about the last real engagement is better evidence than the post. Ask the person who would be your lead, not the recruiter: the lead was there. Second, a post that is mostly "?" usually means nobody has decided yet. That is room to shape the job, and also exposure to drift toward whichever neighbour the quarter's targets favour.