[Long-form, 10,000 words] After dissecting 50 job descriptions, I broke down the "FDE (Forward Deployed Engineer)" into an identification framework
Behind the 95% failure rate of AI implementation hides a mysterious role with a $600,000 annual salary — the Forward Deployed Engineer (FDE). This hybrid role that both writes code and works with clients, both delivers projects and feeds insights back into the product, is becoming a key hub for enterprise AI transformation. This article deeply dissects the four core capabilities of the FDE and its dual nature, provides five stress-test questions to distinguish real positions from fake ones, and draws a transition roadmap for professionals from different backgrounds.
I. Background and Preliminary Conclusions: From "Why Is This Role So Weird" to Breaking Out a Framework
Let me start with a number that sent chills down my spine.
In 2025, the MIT NANDA team released a report called "The GenAI Divide: The State of AI in Business 2025." One line from the report went viral worldwide: companies have spent $30 to $40 billion on generative AI, but 95% of projects have produced no measurable impact on the company's P&L.
Note that the report repeatedly emphasizes one point: what sank these projects was not that the models weren't smart enough, nor that policies forbade their use, but that these tools were never installed into real workflows. The models work great in the lab, but the moment they enter a client's factory floor, bank counter, or hospital back office, they stop running.
(That 95% figure later became controversial in academia; some said the definition of "success" was too strict. But even with a discount, the gut feeling of "powerful models, miserable implementation" is a consensus across the industry.)
So here's the question: the models are already strong enough — who is responsible for actually putting them to use?
The answer is the protagonist of this article — the FDE, Forward Deployed Engineer, usually translated into Chinese as "Forward Deployed Engineer," with some also calling it "frontline deployment engineer."
I first noticed this role on job boards. Honestly, I was baffled. Its hiring requirements seemed to stitch several roles together: it requires writing code, like an R&D engineer; it requires being embedded with clients all day, like a Sales Engineer; it requires managing project timelines and being accountable for final outcomes, like a project manager. Even more outrageous is the pay — OpenAI's job posting offers $220,000 to $280,000 plus equity, and according to data from job aggregation platforms, the top of the industry can reach $300,000 or even over $600,000.
A role that looks like it "does a bit of everything" — why does it command such high pay? Is it really a new profession, or just "senior Sales Engineer" with a new skin and an AI label slapped on to attract hires?
To figure this out, I went through every FDE job description I could find — dozens of them — plus official explanations from several leading companies and retrospectives from frontline practitioners. After going through them all, I reached the following conclusions. In case you don't have the patience to read all ten thousand words, let me put the conclusions up front:
- It is not a new profession, but a "new combination of old capabilities." The FDE compresses two things that were originally split between two groups of people — "being able to write production code" and "being willing to make decisions on-site at the client" — into a single person. What's scarce is not any single one of these, but the combination.
- The gap between real and fake FDEs is enormous. More than half of the positions on the market carrying the FDE title are actually Sales Engineer or implementation roles renamed. There is one hardest criterion for telling them apart — the compensation structure, which I'll cover below.
- For ordinary job seekers: don't rush in yet. The bar for its hybrid skill set is very high, but it is also one of the few positions in the past two years that lets people with "average technical skills + strong business instincts" overtake on the curve.
- For those wanting to switch into this role: there is a clear path. Whether you currently write code, do product work, or work in data/Sales Engineering, the gaps you need to fill differ, and I've drawn a map in Section 5.
If you just want to know "what should I do," you can jump straight to Section 5. If you want to understand "what it really is and avoid being fooled," walk through it with me from the top.
II. First Definition: Copying Responsibilities from JDs, and Failing to Grasp the Point
The dumbest way to understand a role is to pull out the job requirements and compare them. That's what I did at first.
I copied the responsibility descriptions from dozens of JDs into a spreadsheet, looking for commonalities. After copying them all, I discovered something awkward: every company writes it differently, and every one writes it beautifully.
Some emphasize "deep co-creation with clients," some emphasize "rapidly advancing prototypes to production environments," some emphasize "identifying reusable patterns and feeding them back into the platform." Each one sounds right on its own, but pieced together, you still can't say what this person actually does every day, or how they differ from the "Solutions Architect" next door.
This is the flaw of copying responsibilities: a JD is written for recruiting purposes; it piles on every flattering responsibility but never tells you which one is the lifeblood of the role.
So I changed my approach: instead of looking at what it "claims to be responsible for," I looked at what capabilities it "actually requires." I consolidated the requirements that appeared repeatedly across dozens of JDs and initially extracted four capability dimensions:
Dimension 1: Technical implementation — can you actually get things running. Not drawing architecture diagrams, not writing solution documents, but actually sitting down to write code, debug data pipelines, and integrate the model into the client's old, messy systems so it can run in production. An industry comparative analysis put it bluntly: FDE job descriptions generally require that a person spends most of their week writing and delivering production code. This completely separates it from roles that "talk but don't build."
Dimension 2: On-site translation — can you understand what the client doesn't say out loud. The client says "I want an intelligent customer service bot," but the real pain point behind it may be "my returns process requires sign-offs from three departments, and customers have been complaining for three months." The FDE must be able to translate this vague, hidden, even self-unarticulated problem on-site into a concrete task that AI can solve.
Dimension 3: Cross-domain transfer — can you get up to speed in a different industry. Today you're doing risk control at a bank; tomorrow you might be doing planting recommendations at an agricultural machinery company. The FDE can't be an expert in every industry, but they must be able to figure out the ins and outs of an unfamiliar industry within two or three weeks and find the point where AI can plug in.
Dimension 4: Product feedback — can you turn one client's problem into a capability for all clients. This is the most critical and most easily overlooked one. The solution the FDE pioneers at one client cannot stay with that client alone; part of it must be distilled and written back into the company's product, so the next client doesn't have to blaze the same trail again.
At this point, I thought I was done. But I soon discovered a logical problem hidden in these four dimensions — they are not on the same level.
(Listing responsibilities lets you "know this role exists," but to "see through this role," you have to dig one level deeper.)
III. Self-Refutation: The True Core of the FDE Is a "Duality"
I stared at those four dimensions for a long time, and the more I looked, the more something felt off.
Technical implementation, on-site translation, cross-domain transfer — these three, frankly, are what "a very strong Sales Engineer/implementation person" should also possess. If it were only these three, then the FDE really would just be a senior Sales Engineer with a new skin — why should they earn twice as much?
What truly sets the FDE apart is the fourth: product feedback. And it shouldn't sit alongside the first three — it is the "other hand" of the entire role.
So I overturned the first version and re-broke the core of the FDE into a pair of opposing forces, which I call the FDE's duality:
Left hand — delivery-oriented: completely nail "this one client." Dive into the client's environment, use the client's real data, work within the client's various constraints, and build a usable system with real impact. Be accountable for the final outcome for this client — not just hand over a document and walk away.
Right hand — product-oriented: turn "this one client's problem" into "a product capability." While delivering, keep observing: are the pitfalls this client hit ones other clients will hit too? Can this solution be abstracted into a feature or template in the product? Then write that part back, so the company's product keeps growing stronger.
These two hands are both indispensable, and they naturally pull against each other. The left hand says "move fast, just get this customer live for now," while the right hand says "slow down, think about whether this can be generalized." A true FDE is someone who bounces back and forth between these two forces, searching for balance.
This core idea actually explains the "origin" of the FDE role.
It was first created by the data company Palantir around twenty years ago, circa 2010, with the internal codename "Delta" (until 2016, Palantir had more Deltas than regular engineers). The term "Forward Deployed" itself comes from the military—referring to soldiers sent to the front lines, acting on the battlefield on the spot, rather than staying in rear command posts. Palantir's early customers were intelligence and defense agencies, whose requirements simply couldn't be researched through normal channels (much of it was classified), and whose systems were too complex to deliver remotely. So Palantir did something that looked very strange at the time: it embedded its own engineers directly inside customer organizations, staying for months at a stretch, writing code and tuning systems on-site.
Even more clever was its pairing mechanism, called "Echo-Delta": Echo is the person who understands the industry, responsible for figuring out where the customer's real problem lies; Delta is the engineer, responsible for building the solution. Working as a pair, one handles "translation" and the other handles "implementation."
Palantir's official description of this role is quite interesting: it says the FDE's responsibilities are closer to those of a startup's CTO—within a small team, taking full responsibility for a high-risk endeavor from start to finish. There's another line that stuck with me: ordinary R&D is "building one feature for many customers," while an FDE is "unlocking many capabilities for one customer."
See? Palantir doesn't treat the FDE as after-sales support—it treats the FDE as the "tentacles of the product." What engineers figure out on the front lines gets brought back and turned into product (after its Foundry platform launched in 2016, a large number of FDEs flowed back to work on this core product, bringing their front-line experience with them). This is the right hand—the source of the product feedback loop.
To help you tell them apart at a glance, I've put the FDE side by side with several of the most easily confused roles (this is also my main basis for distinguishing real from fake when analyzing JDs):
In this table, the last row—compensation structure—is the key weapon for the "debunking" later on. Remember it.
(The first three capabilities are the entry ticket; the fourth hand is the FDE's moat. Compressing "delivery" and "product" onto one person—that's why the role commands such high pay.)
Four. The Stress Test: How to Tell a "Real FDE" from a "Reskinned Role"
At this point, the definition is clear. But having worked in product for a long time, I have a occupational habit: any definition that looks perfect has to be stress-tested against extreme cases before you know whether it holds up.
Why stress-test? Because as I said earlier, almost all FDE job requirements are written beautifully. Just reading the JD, you simply can't tell which is a real FDE and which is a "reskinned role"—an HR trick of slapping the FDE label on a pre-sales position to make hiring easier.
Conventional questions won't reveal the truth (ask "does this role involve writing code?" and the answer will always be yes). So I've prepared five "stress test questions"—when you're evaluating a role, going through interviews, or even already on the job and wondering whether it's real, poke at it with these five questions one by one.
Question one, and the hardest one: How is the money paid? Is there a sales commission? This is the industry's most honest touchstone. A real FDE gets base salary + equity, because they're accountable for "whether the customer uses it well," not for "whether the deal gets signed." Once you find that a role's compensation includes things like "sales commission / performance bonus," it's most likely a pre-sales (SE) role with a trendy new name. Where the money is tied is where the responsibility lies—this one can't be faked.
Question two: How much of this person's day is spent writing code that actually ships? If the answer is "mainly writing proposals, making PPTs, occasionally building a demo prototype," that's a Solutions Architect. A real FDE spends most of their time committing code in the customer's codebase, getting pipelines working, and getting up in the middle of the night to debug an interface that won't run. It's a "builder," not a "designer."
Question three: Is there a channel for what they figure out to flow back into the product? This one specifically targets "fake FDEs." Ask: after this role discovers a good solution, can it—and should it—be distilled into a product feature? If the company has no such feedback channel at all, and the FDE finishes one customer and then starts the next from scratch, then it's just "an outsourcer wearing an engineer's vest," and the right hand is useless.
Question four: Do they come in before the deal is signed, or after? Coming in before the deal is signed, mainly to help sales dispel customer doubts, is pre-sales. A real FDE comes in after the deal is signed and is on the hook for "whether this thing actually works in the end."
Question five: When facing a vague or even self-contradictory requirement, is this role expected to "take it all as given," or expected to "dare to push back"? Palantir has a famous internal metaphor: the ideal FDE should be like a seasoned waiter at a French restaurant—he knows the entire serving process, can sense what you really want, and has the confidence to talk you out of a bad choice—rather than just bringing you whatever you order. Someone who only does "whatever the customer says" can't be a real FDE.
Filter with these five questions, and the "reskinned roles" on the market will basically reveal themselves.
By the way, here's a particularly telling detail I discovered while digging through the data: FDE job postings are actually not as numerous as pre-sales or Solutions Architect postings. The reason isn't that the role is unimportant—quite the opposite. Pre-sales and architect roles can be hired in batches because the product is mature and the playbook is fixed—just hand ten people the same manual. But the very premise of an FDE's existence is that "the playbook hasn't been written yet." Since it can't be standardized, naturally fewer are hired, yet the demand gap is louder. This is also the fundamental reason its salary keeps getting bid up: from January to September 2025, monthly postings for FDE roles worldwide surged by more than 800%, while the number of people who can do this job is pitifully small.
(For ordinary roles, look at what the JD says; for scarce roles, look at what the JD doesn't dare say—compensation structure, proportion of coding, product feedback channel: these three spots can't hide the truth.)
Five. The Methodology: How Exactly Should You Use This Framework
After all this analysis, it comes down to one question for you: What can I do with this after reading it?
Here are concrete actions for three types of people—just follow along.
If you're a job seeker trying to judge whether a role is worth taking
Turn the five stress test questions from the previous section into your own "JD reading checklist," and run through it whenever you see a role with the FDE label:
- Does the compensation structure include sales commission? (Yes → most likely a reskinned pre-sales role, be cautious)
- Do the responsibilities mention hard work like "writing production code / working in the customer's codebase"? (No → leans architect or pre-sales)
- Is there any mention of "distilling solutions into product / feeding back into the platform"? (No → the right hand is useless, poor growth potential)
- Do they come in for pre-sales or to own delivery outcomes? (See whether it emphasizes "closing the deal" or "being accountable for results")
- Does it welcome you voicing objections to requirements? (You can ask directly in the interview: "If I judge that the customer's requirement direction is wrong, how much room do I have to overturn it?"—the reaction says a lot)
Only when three or more of the five answers are "yes" is it a real FDE worth going for.
If you want to transition into FDE, fill different gaps depending on your background
I've drawn a "gap-filling map" for four common backgrounds—find where you fit:
- If you come from an engineering background: You already have the technical hand; what you're missing is the "people" part on the right. Deliberately practice: explaining a technical matter clearly in front of customers/business stakeholders, hearing the unspoken real need behind their words, and daring to make the call in meetings. Seek out projects that face outward directly and hold you accountable for results—don't stay stuck in the backend.
- You come from a product/business background: On-the-spot translation is your strength; what you lack is "hands-on ability." You don't need to become an algorithms expert—most FDEs don't need to train models—but you must be able to skillfully call LLM APIs, write prompts, understand and build a simple AI agent workflow, and run evals. Once you fill in this set of "application-layer engineering skills," your business instincts will immediately pay off.
- You come from a data/algorithms background: You understand models, but you easily get stuck in "tuning metrics." What you need to add is "business-results awareness" and "delivery speed"—don't chase perfection in model tuning; first get something that solves a real customer problem up and running quickly.
- You come from a pre-sales/solutions background: You're the closest—just missing one hand: the ability to write code yourself and take responsibility for production outcomes. Upgrade from "doing demos" to "building things that can go to production," and your cost of switching is the lowest.
If you just want to understand this trend and set a direction for yourself
Remember one sentence and that's enough: Over these two years, the most valuable position in the tech world is shifting from "making models stronger" to "actually putting models to use."
The evidence is solid. At the end of 2024, OpenAI began building an FDE team; by May 11, 2026, it had established a company dedicated to enterprise deployment, "OpenAI Deployment Company," with over $4 billion in startup funding from a consortium of 19 investment institutions led by TPG, and it acquired Tomoro, a UK company founded in 2023 with about 150 FDEs. Almost at the same time (May 4), Anthropic, together with Blackstone, Hellman & Friedman, and Goldman Sachs, formed a joint venture of roughly $1.5 billion, sending Claude and its engineers into the core businesses of mid-sized companies—starting with companies invested in by those institutions—and planning to expand its application teams, including FDEs, to five times their current size. Salesforce is even more direct, publicly committing to build an FDE team of about 1,000 people, organized in small squads, with one squad embedded at a single customer for months at a time.
This is also starting to emerge in China, and it's not just a concept. On November 29, 2025, Shanghai held the country's first FDE-themed training program (jointly organized by the Shanghai Municipal Party Committee Organization Department, the Municipal Commission of Economy and Informatization, Shanghai Innovation Institute, etc., with Ding Xiaodong of Shanghai Innovation Institute as the lead lecturer). Even more notable is the policy level: the "Shanghai Three-Year Action Plan for Supporting the Transformation and Upgrading of Advanced Manufacturing (2026–2028)" issued by the Shanghai Municipal Government Office in January 2026 explicitly states the goal of cultivating a "Forward Deployed Engineer" workforce. There are voices from the corporate side too—Li Jing, Vice President of StepFun, has publicly said that project managers who understand AI products are in extremely short supply, and the industry is poaching them at high salaries. This shows the wind has genuinely arrived.
For those of you in mobile internet, this means: product managers who merely "build features" and people who merely "write requirements" are seeing their value diluted; while those who can go down to the customer site and personally turn a vague business problem into something that runs, makes money, and feeds back into the product are becoming more and more expensive.
(You don't necessarily have to become an FDE, but you'd better understand why FDEs are expensive—because they represent what the next generation of valuable skills looks like.)
VI. Boundaries of Validity and Summary
The biggest fear in writing product analysis is overstating things. So before wrapping up, I need to clearly mark what this article "doesn't say," to avoid being misread.
First, this is a "present progressive" role; its definition is still changing. FDEs have only been hot for a year or two at most, and different companies understand the role very differently. The framework I've given is to help you "see through most situations," not a ruler that fits every company.
Second, don't benchmark the salary figures directly against China. The figures like $200K and $600K in the article reflect the market at top US AI companies. The salary systems for similar roles in China are completely different—don't take these numbers to negotiate with HR; it would be awkward.
Third, that 95% figure—I used it as a hook, but I never treated it as gospel. The MIT report's definition of "failure" is rather strict, and there are differing views in academia. What's truly useful about it is not the specific number, but the direction it points to: the bottleneck for AI adoption has shifted from "whether the model works" to "whether anyone can install it into the business."
Fourth, FDE does not mean "a person who can do everything." It doesn't require you to train large models (that's the algorithms engineer's job), nor is it about being both a salesperson and customer support. Its core is just two things: delivery + feedback. Don't imagine it as a superhuman who does everything.
Finally, back to the opening image that sent chills down my spine: a group of companies spends astronomical sums buying AI, then watches helplessly as employees keep manually organizing data in Excel, AI-generated reports are riddled with errors, and finance can't sleep over this wasted investment.
The reason FDEs overnight became the role every industry is scrambling for is essentially not that they're some kind of god, but that this "last mile" pit is simply too deep, too expensive, and too widespread—and there are far too few people willing to jump into the pit and weld the model to the business with their own hands.
Models will keep getting stronger, until eventually everyone's are about the same. But "actually putting powerful things to use" will always require a specific person, embedded at a specific customer, solving a specific problem.
How much that person is worth—the hiring market over these two years has already given the answer.
And what you can do is, after reading this, look at that checklist and think clearly about one thing: When it comes to the next wave of valuable skills, how many of them do you actually hold in your hands?
Sources (all publicly verifiable)
MIT NANDA team, "The GenAI Divide: State of AI in Business 2025" ("95% of enterprise AI projects show no quantifiable return," $30–40 billion invested; that figure is contested in academia)
Palantir official blog "A Day in the Life of a Palantir Forward Deployed Software Engineer" and its recruiting pages (FDE/FDSE, Delta, "unlocking many capabilities for one customer")
Salesforce official blog "Today's Hottest Role: Forward Deployed Engineer" (Salesforce's commitment to a 1,000-person FDE team; the 800% surge per Indeed and Financial Times analysis; Palantir early 2010s, Delta, more Delta than engineers before 2016)
The Pragmatic Engineer, "What are Forward Deployed Engineers, and why are they so in demand?" (origin of the role, creative-CTO, relationship to adjacent roles, Foundry and FDE boomerangs)
OpenAI official announcement "OpenAI launches the OpenAI Deployment Company," Cooley law firm and Constellation Research reports (OpenAI Deployment Company with over $4 billion in startup funding from 19 institutions led by TPG, acquisition of Tomoro with about 150 FDEs, May 11, 2026)
Blackstone and Goldman Sachs Asset Management official press releases, Fortune / CNBC / TechCrunch (Anthropic's roughly $1.5 billion joint venture with Blackstone, Hellman & Friedman, and Goldman Sachs, aimed at mid-sized companies, May 4, 2026)
OpenAI FDE position on builtin ($220K–$280K range); job aggregator data ($300K–$600K range, for reference only)
Comparative analysis of roles at Exponent, Perspective AI, Paraform, etc. (FDE vs Solutions Architect vs Sales Engineer: timing of involvement, share of coding, differences in compensation structure; "compensation structure is the most honest litmus test")
The Paper, Sina Finance (citing the Shanghai Municipal Commission of Economy and Informatization), Jiefang Daily · Shangguan News, Shanghai Innovation Institute official website (Shanghai's first FDE training program starting November 29, 2025, the "Hundred-Thousand-Ten Thousand" initiative, StepFun's Li Jing's remarks)
Shanghai Municipal Government General Office, "Shanghai Three-Year Action Plan for Supporting the Transformation and Upgrading of Advanced Manufacturing (2026–2028)" (proposing to cultivate a "Forward Deployed Engineer" workforce)
This article is an industry analysis; all cited data is subject to the original sources. Figures such as salaries and hiring numbers change over time—please refer to the latest public information.
This article was originally published on Everyone Is a Product Manager by @james chan. Reproduction without the author's permission is prohibited.
Cover image from Unsplash, under the CC0 license
