Chapter 1: The Rise of the FDE

"One of the challenges of building software for spies is: I don't know any spies." — Bob McGrew, early Palantir executive and former Chief Research Officer of OpenAI

1.1 First, a Story of a Dead Multi-Million-Dollar Project ​

The story always begins the same way. In the conference room of a large enterprise, a vendor's demo has just ended. The large language model answers every question fluently, the data dashboard dazzles, and even the most demanding executives can't find a flaw. The CEO decides on the spot: sign. The contract is worth millions of dollars; handshakes, photos, a press release.

Nine months later, the project is dead.

Not a dramatic death—a silent one. The system is still running, the servers are still on, but not a single business unit is actually using it. The vendor delivered every feature in the contract, and the enterprise paid every invoice. The only thing that never arrived was "value."

If you think this was just bad luck, the 2025 report *The GenAI Divide* from MIT's NANDA lab will tell you: this is the norm. They interviewed 52 organizations, collected 153 executive surveys, and reviewed over 300 public enterprise AI projects, arriving at a single conclusion: of the $30–40 billion burned, 95% produced no measurable financial return.

Before citing this 95%, the methodology needs to be laid out. After the report's release, criticism focused on three points:

• It defined "failure" as having no measurable impact on financial statements within six months—by that standard, nearly all early investments in the internet and cloud computing were "failures";
• Its measure of value recognized only profit, cost, and revenue—leading indicators like process speedups and employee adoption didn't count;
• The sample was dominated by large enterprises, and the failure data came only from the project sponsors' side. One commenter also pointed out a conflict of interest: the NANDA lab itself researches the agentic internet, and the report's proposed solution happens to point in its own direction. (Source: Appendix C)

These criticisms are all valid, but none of them overturned the directional judgment: enterprise AI projects broadly underperform—independent research from RAND, S&P Global, and others points to the same picture. So this book cites the 95% for its direction, not as a precise value; a failure rate precise to the digit is itself a kind of false precision.

More interesting is the way things fail. The report specifically noted: the problem is not the models. The models that dazzled in demos remain just as smart in production—it's just that they "don't retain feedback, don't store context, don't enter workflows"—they look like products but behave like exhibits.

Stanford's same-year aggregate data corroborates this: 88% of organizations are using AI, yet only a single-digit percentage of agentic applications actually make it into production. McKinsey delivered the final blow: only 6% of enterprises can say AI contributes more than 5% to their profits.

In the days when Fortune covered the report, a complaint from a manufacturing COO circulated in the industry: "Online, they say everything has changed. Back in our workshop, nothing has moved." (Source: Appendix C) That stings more than any data—his company doesn't lack budget or tools; what it lacks is someone to push the tools into the workshop's real workflows.

The report also contains a quieter comparison that votes directly for this book's thesis: systems enterprises build in-house succeed at only about one-third the rate of purchased mature solutions. The report's lead author said that nearly every enterprise they visited was trying to build its own tools—and building in-house is precisely the path with the most deaths.

He also told a story about a control group. Some startups founded by nineteen- and twenty-year-olds, using generative AI, reached $20 million in revenue in a year. Their playbook was the exact opposite of established enterprises': pick a single pain point, punch through it, and bind tightly to customers who would actually use their product. Older companies always want to swallow everything in one bite, while the young ones take a small bite, break through, then take the next bite. (Source: Appendix C)

In fact, this chasm wasn't dug in the AI era. China's enterprise software industry has been lying in it for over a decade: big companies demand customization, vendors lose money on every deal, the delivered code is abandoned once the team leaves, and everyone ends up as "the client's outsourcing shop." An enterprise software veteran on the podcast *Hard Ground Hackers* put it bluntly: "Customization is the natural enemy of SaaS; this curse can only dissolve naturally when the market matures." The American version is more dignified, but the script is similar: sales signs the deal, implementation comes in, six months later they deliver a "feature-complete but unloved" system, followed by endless wrangling.

In the end, it's the same wall: the place where software is built and the place where value is created are not the same place. On this side of the wall, requirements get relayed through tickets, meeting notes, and weekly reports, losing fidelity with each retelling; on the other side, the customer's real workflows hide in spreadsheets no one documents, in conventions passed down by word of mouth, in the tacit knowledge of "you'll have to ask Old Wang about that." The software industry has invented countless ladders over the wall—requirements documents, user research, implementation methodologies, customer success systems—but the wall remains.

Until one company decided: no more climbing the wall—send the people over.

1.2 Palantir's Victory ​

In 2003, Silicon Valley had just crawled out of the ruins of the dot-com bubble. Peter Thiel and a few Stanford-educated young people founded a company named after *The Lord of the Rings*—Palantir, the seeing-stone, the mythical stone that could see afar. What they set out to do sounded like science fiction: build data analysis software for US intelligence agencies, connecting fragments scattered across countless classified databases into a picture, helping analysts catch terrorists.

This business had a premise that would make any product manager collapse on the spot. Years later, early executive Bob McGrew recounted the story vividly on YC's Lightcone podcast:

"When we started, our goal was to build software for the intelligence community—to put it plainly, software for spies. And one of the challenges of building software for spies is: I don't know any spies, and you probably don't either. Even if you happened to find a spy and asked them, 'How exactly do you do your work?' they usually wouldn't tell you."

No user interviews, no requirements documents, no usability testing. The first lesson of internet startup methodology was rendered entirely void here. One of the founders, Stephen Cohen, came up with a charmingly clumsy solution: build a demo, show it to people at the intelligence agencies, and ask what they thought. They didn't hold back: "This thing is terrible—it has nothing to do with what we do." Cohen didn't retreat; he asked a follow-up: "Then how would you want it to be different?" Then he pulled out a notebook, wrote everything down item by item, went back and revised, and brought it back again.

This clumsy loop was the embryo of the FDE. It contained two intuitions later proven priceless: first, customers in complex domains don't know what they want until they see something that works; second, the fastest way to learn what customers want is to put the people who build things next to the people who use them.

The person who upgraded this intuition into company strategy was Shyam Sankar, employee number 13. As Palantir moved from its first customer to its second and third, the team discovered a counterintuitive fact: what each customer wanted differed in subtle but critical ways. The standard solution is to extract commonalities, build a general product, and say no to differences. But Palantir's customers were the CIA, the FBI, the US military on the battlefield—saying no meant being out.

Sankar did the opposite: build a platform flexible enough to customize, then station engineers on-site at the customer to finish the last mile.

His most crucial move was changing the accounting for this. In the software industry's ledger, "customizing for a single customer" is called services—the enemy of margins. Sankar flipped it: the cost of on-site customization should be booked as product discovery. Every pitfall engineers step into at the customer's site is a signpost for the platform's next evolution.

Sankar himself was the first Forward Deployed Engineer, and his earliest on-site experience was the prototype scene for the role. Around 2007, the biggest source of American casualties in Iraq was roadside bombs, and the counter-IED operations center set up to fight them allowed Sankar to bring a small team and a "still very rough" product into a SCIF to work side by side for two weeks. A SCIF is a physically isolated classified space where even speakerphones are banned. Sankar came up with a brute-force workaround: he strapped a phone to his head with an elastic band to free up his hands for coding—one ear listening to analysts' feedback, the other to colleagues from Silicon Valley headquarters. Nineteen hours a day for two weeks: demo, ingest data, collect feedback, fix on the spot. At the end, the analysts said: this thing is useful. Sankar himself was wrecked, and called CEO Karp: "This isn't sustainable, we're done." Karp's answer later became company culture: turn that "unsustainability" into an institution. (Source in Appendix C)

Years later, colleagues recalled that even when Sankar criticized people, there was no emotion in it. Once, he was having a pleasant chat with his colleague Meagher at an airport café when the man's inbox suddenly received a sternly worded critical email from him—written and sent on the spot, while sitting across the table. "There were no personal attacks in it, only one subtext: to win, I owe you these truths." (Source in Appendix C)

This playbook was soon tested in blood on the battlefield. Palantir engineers on site discovered that soldiers didn't need fancy intelligence dashboards at all—they just wanted a small tool to mark "this road is suspicious" on a map—roadside bombs were the biggest killer of patrols. The engineers threw together a crude map tool on the spot: soldiers could tap to flag dangerous road segments, visible to the whole unit in real time. The tool saved lives and was later hardened into a standard platform feature. It could never have been born in any headquarters conference room—only in that moment when engineers and soldiers looked at the same road together.

On the commercialization side, there was first a near-death experience. Palantir's first enterprise-facing product was called Metropolis, and the market response was dismal—only a few financial firms were grudgingly using it. The second attempt, Foundry, finally got traction, and the turning point was Airbus: in the Toulouse factory, a fuel pump fault on the A380 kept recurring, and Airbus's own engineers had spent two years without a clue. Palantir's people came in, hooked the sensor data into the platform, and cracked the case in two weeks—during climb, fuel sloshed away from the pump. A trivial fix that reportedly preserved an order worth tens of billions of dollars. Airbus's head of digitalization later said publicly: "The same problem used to take us twenty-four months to investigate." (Source in Appendix C) Airbus became Palantir's staunchest advocate in Europe, building its entire data platform Skywise on top of it, connecting tens of thousands of aircraft and more than fifty thousand users. What came later was even more interesting: the platform turned from customer into channel—today more than 150 airlines run on Skywise.

There's also a piece of gossip worth recording. Legend has it that Palantir's software was involved in the 2011 operation that killed bin Laden. The claim has never been confirmed, nor refuted—journalists writing biographical coverage of Palantir deliberately left this ambiguous footnote in place. True or not, the rumor itself is Palantir's best sales weapon. (Source in Appendix C)

Before 2016, the number of Palantir Forward Deployed Engineers at one point exceeded the number of platform engineers. A software company with more than half its engineers not writing product at headquarters, but scattered across customer sites around the world. Wall Street couldn't make sense of it for years, dismissing it as "human wave tactics" and "more like a consulting firm."

Then, time gave the answer. In 2023 it launched its artificial intelligence platform AIP, paired with a playbook called "bootcamps" (detailed in Chapter 8), compressing the nine-to-twelve-month enterprise software sales cycle down to weeks. In Q4 2025, its "Rule of 40"—revenue growth rate plus adjusted operating margin (non-GAAP): a software industry health metric where 40 counts as passing—hit 127%; in Q1 2026, 145%. Quarterly bookings of $4.26 billion (bookings, total contract value basis), net revenue retention (NRR; called NDR in Palantir's financial reporting) at 139%, and $7.2 billion in cash on hand.

On the earnings call, Karp said only one thing: "We are a species of one." The market cap at one point surged past $400 billion. (Source in Appendix C)

Those who once laughed at its human wave tactics fell silent. Over twenty years, Palantir proved one thing: that wall cannot be climbed with a ladder, but it can be climbed by people. And these wall-climbers got an official name—Forward Deployed Engineer.

Sankar later publicly claimed credit for coining the name on the American Optimist podcast. His definition was anything but official: a Forward Deployed Engineer is the kind of person who "eats the pain and produces the product."

Of course, there's another account of the origin. One venture capital firm's research found that IT services companies embedded engineers at customer sites even earlier than Palantir—but let's set that controversy aside for now; Chapter 7 will return to it with data.

1.3 What Is an FDE ​

A One-Sentence Definition ​

The definition this book adopts comes from the best explicator of this model, Bob McGrew—early in his career an engineer at PayPal, later an early Palantir executive, and then Chief Research Officer at OpenAI; ChatGPT and GPT-4 both came out of the teams he led:

A Forward Deployed Engineer is an engineer stationed at the customer site, filling the gap between "what the product can do" and "what the customer needs."

"Stationed at the site" means your working context is embedded in the customer's world: joining the customer's group chats, reading the customer's data, attending the customer's meetings, getting to know the person who "knows why the process is the way it is"—not necessarily sitting in the customer's office every day. The "gap" is the reason this role exists: where the product works out of the box, you're not needed; the deeper the gap, the more you're needed—intelligence, finance, manufacturing, healthcare, legal.

"Engineer" is the most crucial qualifier: you write production code, not reports. When Palantir chose the name, it deliberately kept the words "Software Engineer" to emphasize to the world: this is not a consulting role. As for "Forward Deployed," it's a military term for troops deployed at the front—putting your most combat-effective people closest to the problem.

What It Is Not ​

First, what it is not.

It is not pre-sales. Pre-sales work ends before the contract is signed; the goal is winning the deal, and the deliverable is slides. An FDE's work enters deep water only after the contract is signed; the goal is winning the outcome, and the deliverable is a system running in production. Pre-sales makes the customer believe "this can be done"; the FDE makes it actually happen.

Nor is it on-site outsourcing—a distinction that matters especially for Chinese readers, because "engineers on site" has a long and unsavory history in China. Qimeng Technology, the first domestic service provider to fly the FDE banner, drew the line between itself and on-site staffing in three sentences on its website:

• On-site staffing is paid by the hour; FDEs deliver by phase and are accepted on results;
• On-site staff write everything from scratch; FDEs do engineering on top of a product foundation;
• On-site engagements drag on longer and longer, and when the people leave the system stops; FDEs leave when the work is done, leaving capability behind in the system and the customer's team.

Jove, head of FDEs at Cresta, a Silicon Valley AI customer service company, drew this boundary in even finer detail in a video conversation. His team is expanding from 30 to 100 people this year, and his judgment is: an FDE only makes sense when bound to an AI platform—if you're just doing traditional data integration and system setup, it's hard to distinguish from a traditional implementation engineer or outsourcing. He also has one hard rule for hiring: in the age of agents, not being able to write code is like being illiterate.

Another notable mechanism is the dual mandate: FDEs are not only responsible for making the deployment succeed, but also carry the metric of "making the product more mature" — what is learned in the field must feed back into the platform. (Source in Appendix C)

It is not consulting. Consultants deliver recommendations per project and are not responsible for execution; FDEs are accountable for the system's final operation, with the endpoint being "the customer's team can use it independently." The collaboration between Anthropic and fintech company FIS is a case in point: engineers embedded at FIS co-built an anti-money-laundering agent, compressing investigations from hours to minutes, but the stated goal of the collaboration was not to deliver a system, but to "transfer knowledge so that FIS can build agents itself in the future." The consulting business is built on the customer's continued need; the standard for whether an FDE has succeeded is exactly the reverse — only when the customer no longer needs you one day does it mean you have succeeded.

Buyers do the same math. A technology leader at JPMorgan put it bluntly when discussing co-building with platform vendors: "What we want is not more consultants, but engineers who can build things that don't yet exist."

It is also not the traditional product engineer. Product engineers face abstract users — personas (what users look like), funnels (how many people go from visit to payment), daily active user counts; FDEs face concrete customers — a bank's risk control department, a farm in Iowa, a patrol unit on the outskirts of Baghdad. In Palantir's official blog post "Dev versus Delta," there is an official division of these two roles: platform engineers are responsible for "one capability, serving multiple customers," while Forward Deployed Engineers (internal codename "Delta") are responsible for "one customer, mobilizing multiple capabilities." What platform engineers pursue is a feature that works everywhere; what FDEs pursue is thoroughly solving the problem of the one customer in front of them first.

Nabeel Qureshi, who spent nearly eight years doing forward deployment at Palantir, put this discipline bluntly: "Screw generalizability" — first save the customer in front of you; whether it can be reused for the next one is the platform team's business.

How this trend took off ​

Why did a role invented in 2003 only become a top star in 2025?

The most direct trigger was generative AI. Large models created an unprecedented gap: anyone can produce a stunning demo in five minutes, but hooking the demo into an enterprise's real data, permissions, compliance, and workflows is an order of magnitude harder. Model companies gradually figured it out: the next battleground lies in deployment capability. The deployment lead at a logistics AI company put it even more bluntly: AI implementations rarely fail on the model — they almost always fail on context.

The demand side voted just as plainly. Goldman Sachs rolled out its in-house AI assistant across the entire bank, covering tens of thousands of employees during internal testing; Klarna's AI customer service agent took over two-thirds of customer service sessions in its first month online; even universities are acting — Syracuse University opened Claude to all students and faculty, and required training to be completed before accounts were activated.

This trend did not blow up overnight. As early as July 2025, Semafor published an article asserting that this "plainly named role" would transform the AI industry.

The numbers sketch how steep the curve is: according to official statistics from the job platform Indeed, in April 2025 there were only 643 jobs in the US with the FDE title; a year later, that became 5,330 (by Indeed's job-matching methodology), a 729% increase. Other institutions' figures are even more dramatic — 800%, 1,165% — with varying statistical methods but entirely consistent direction. On YC's job board, over a hundred startups posted this position that barely existed three years ago.

The venture firm a16z (Andreessen Horowitz) directly called it "the hottest job in tech," adding a vivid analogy: enterprises buying AI is like your grandma getting an iPhone — she wants to use it, but needs you to set it up for her.

A series of reports from the Financial Times in November 2025 is the best slice for observing this wave. OpenAI's head of forward deployment in Europe, Fournier, said the team was only established a year ago and is about to expand to 50 people, "demand has exceeded our expectations"; Anthropic's head of applied AI, DeJong, put it more interestingly: "A Fortune 500 bank's needs and an AI-native startup's are two entirely different species." — so her team grew fivefold in a year. Palantir's UK lead, Prentjohn, condensed the company's creed into one sentence: "Software only has value when it truly matters to the end customer." Even the CEO of model company Cohere, Gomez, came out in support: "We embed engineers at the start of the contract, and pull back once the customer is running smoothly." (Source in Appendix C)

The intensity of the talent war also shows in a string of hard numbers. OpenAI's forward deployment function was officially announced by Colin Jarvis on social media in January 2025, with a mission of just one sentence: "help customers push systems into production"; the team started with 2 people and grew to 52 in a year. Salesforce, which wrote "we don't do implementation ourselves" into its textbooks, publicly committed to hiring 1,000 FDEs; Google Cloud posted 59 positions at once, with CEO Kurian personally going online to call for "builders who want to stand at the center of the agent era"; Box's CEO Lev publicly asserted that this would become one of the most sought-after positions in tech.

Databricks went even further, reorganizing its former professional services division wholesale into an FDE organization, serving more than 1,900 customers in twelve months. Even Deloitte, which makes its living selling consulting, established a dedicated FDE business line in December 2025. Europe hasn't been idle either — from Mistral to Lovable, star startups' hiring focus is shifting from research talent to deployment talent. (Source in Appendix C)

This trend has even reached the government's field of vision. At the end of 2025, Shanghai held the country's first FDE-themed training program, jointly organized by six government bodies including the Municipal Party Committee's Organization Department and the Municipal Commission of Economy and Informatization. Interestingly, the composition of the first cohort: not engineers, but heads of municipal state-owned enterprises and key industry regulators — training the demand side first, then the supply side. The goal of the supporting program was equally plain: connect a hundred enterprises, build a thousand agents, and drive ten thousand developers to transform.

The official characterization of this role is "special forces in the AI field." It is rare in the history of the software industry for a role to become so hot that the government steps in to run training programs.

Then came the giants voting with their feet. On May 11, 2026, OpenAI announced the founding of a "deployment company": majority-owned by itself, joined with 19 top capital firms including TPG, Bain Capital, and Brookfield, with initial investment exceeding $4 billion; media reported a pre-money valuation of about $10 billion, along with the acquisition of a consulting firm with 150 deployment engineers. Hours later, Anthropic was reported to be forming a comparable joint venture with Blackstone. The two largest model companies, on the same day, elevated "deployment" from a cost center to a strategic asset — the capital markets voted for FDE in the most expensive way.

Why is the capital market willing to vote this way? The venture firm Foundation Capital did the math openly: they estimate this wave targets a market on the order of $4.6 trillion — half is the payroll enterprises pay to roles like sales, marketing, and engineering, and half is spending on IT services and outsourcing. In other words, what software charges against is shifting from the "tool budget" to the "labor budget." In a16z's words: software no longer just helps workers do their jobs — software itself is the worker.

Of course, there are also cool-headed skeptics. The Wall Street Journal laid the question on the table in its reporting: this approach looks more like consulting than software; embedded talent is too expensive, and whether it can scale remains an open question. This is a serious challenge — Chapter 7 of this book will address it head-on.

The deepest reason, as McGrew saw through it: "AI agents are a category with no dominant player yet, so there's a massive amount of product discovery to do." What CRM software should look like had a standard answer twenty years ago; what an agent should look like, nobody knows—including the customers themselves. The answer can only be found on-site at the customer. McGrew put it even more plainly on Sequoia Capital's Training Data podcast: Palantir's AI platform is valuable precisely because it isn't a model, but rather the layer that lives "outside the model, dealing with the rest of the enterprise"—the stronger the models get, the more valuable this layer becomes.

Tech analyst Ben Thompson offers a longer historical frame: multi-year, deeply embedded delivery isn't a Palantir quirk, but a return to the software industry's norm of forty years ago—his judgment is that services and integration teams will fully return, and this generation of AI companies must learn to sell from the top of the customer's organization down.

In 2003, Palantir invented the FDE because it "didn't know how spies work"; in 2025, the entire industry is collectively embracing the FDE because it "doesn't know how agents should work inside enterprises."

1.4 The FDE's Responsibilities and Traits ​

A Résumé Born for This Role ​

If you want to answer "what kind of profession is an FDE," McGrew's résumé is practically the standard answer.

His first job was at PayPal, as an early engineer. That group later became known as the "PayPal Mafia," profoundly shaping all of Silicon Valley. After leaving, he joined Palantir in its startup days, rose all the way to executive, and personally witnessed the FDE's evolution from stopgap measure to company strategy. When he managed product and engineering teams, he offered a famous metaphor: Forward Deployed Engineers build "gravel roads" to value on-site at customers, and the product team decides which gravel roads are worth widening and paving into "highways" serving the next ten customers. He later summed up the whole model in one sentence: doing non-scalable things, at scale.

Later, he became OpenAI's Chief Research Officer, leading the development of ChatGPT, GPT-4, and the o1 reasoning model. In other words, this is someone who built the platform on one side of the wall, crossed over to the field on the other side, and ultimately built with his own hands the very technology that raised that wall even higher.

An interesting scene took place at an AI conference hosted by YC in 2025. McGrew expected founders to crowd around asking "how did you invent ChatGPT," but instead everyone chased after the same question: how does Palantir's FDE model actually work? The person who invented ChatGPT was most pressed about his delivery methodology.

Three Layers of Traits ​

Synthesizing over twenty job postings from various companies and firsthand accounts from practitioners, the FDE's traits can be summarized in three layers.

The first layer: a technical generalist broad enough. An FDE doesn't need to be the deepest expert in any one field, but must be able to independently solve full-stack problems on-site at the customer (from interface to database, all by oneself): able to write code, debug APIs, understand data pipelines, deploy to the cloud, gauge the temperament of large models, and also understand the "utilities" of enterprise environments—single sign-on (log in once, access everywhere), permissions, and compliance certifications. The job market has a clear price tag for this combination: GetPerspective's Forward Deployed Engineer Salary Report, released in early 2026, shows that mid-level FDEs at top AI labs have a median total annual compensation of about $385,000, senior about $610,000, and principal over $1 million—higher than most pure R&D roles at the same level, because the market knows how scarce such people are. (Source in Appendix C)

The second layer: the ability to translate technology into business outcomes. This is the watershed between FDEs and ordinary engineers. A frontline practitioner's words are widely quoted: "The model is usually the cleanest part. The hard part is finding the workflow nobody documented, the data source people actually trust, and the person who knows why the process is the way it is." Palantir's hiring bar puts it even more bluntly: "The candidate's expressiveness, clarity, and ease of communication should make me happy to have them run a meeting with a customer."

Interviews also screen for this translation ability. OpenAI and Palantir FDE interviews have a signature segment called "problem decomposition": you're handed a huge, ambiguous real-world enterprise problem, and for sixty minutes you don't write a single line of code—they only watch how you ask follow-up questions, how you scope the problem, how you establish order amid chaos. The interviewer's advice: understand the problem before diving in—slow is smooth, smooth is fast. In an ordinary interview, "I optimized the query by 40%" is a perfect answer; in an FDE interview, the perfect answer is: "I optimized the query by 40%, which gets the customer's analysts their reports two hours earlier every day, and tripled the team's throughput." Technical achievements must be converted into the customer's language.

The third layer: ownership, plus a bit of "rebelliousness." A saying circulates among practitioners specifically describing the accountability this role demands: "The deployment goes down at 2 a.m. You don't file a ticket, you don't blame another team, you don't go back to sleep. You fix it. Period." Palantir also has a subtler expectation for business-side roles: deep industry knowledge combined with the courage to be a "rebel"—able to see the absurdity in the customer's status quo, and bold enough to push for tenfold improvements, not ten percent. CEO Karp's behavioral benchmark back in the day was the "French waiter": embedded in the service process, sensitive to real needs, while possessing enough confidence and taste to guide customers from "what they think they want" to "what's actually good for them."

What a Day Looks Like ​

In daily practice, an FDE's time is roughly divided like this: forty to fifty percent immersed on the customer side writing code and tuning systems, twenty to thirty percent aligning direction with customer management, decomposing problems, and making architecture decisions, ten to twenty percent distilling patterns learned in the field back into the company's product line, and the rest on eval optimization and knowledge sharing—writing playbooks, internal evangelism, training customer teams.

This schedule hides an important message: an FDE is not an "engineer sent abroad," but an "engineer with a two-way mission"—delivering results to the customer on one end, feeding intelligence back to the company on the other. This is also the theme of the next two sections.

1.5 Everything Speaks Through Results ​

If the FDE's work creed had to be summed up in one sentence, it would be: everything speaks through results. Palantir executive Mebrhi broke it down into two plain questions: "Does it actually work? Does it actually matter?"—and according to him, the FDE model is one of the company's "biggest secrets."

First, let's distinguish "data" from "results." Enterprise software history has never lacked projects with good-looking data and terrible results: feature checklists 100% ticked off, but only 5% of people using them; systems with four nines of availability (online 99.99% of the time), while business departments would rather keep using spreadsheets. Of the 95% of failed projects in that MIT report, the vast majority weren't lacking data reports—the numbers were all there, but the value never arrived, because no one was accountable for "that line on the financial statement."

The FDE model institutionally ensures that "results" don't get diluted, through three specific mechanisms.

• Payment tied to results: In its early government projects, Palantir made extensive use of "pay only when it works" arrangements. McGrew recalled it bluntly: "Early on, it was reasonable for the startup to bear all the risk—you pay us once it works." This logic has evolved into something more refined in the AI era: Sierra charges by "resolved conversations," no resolution, no charge; many FDE service providers deliver in phases and accept results-based acceptance. Once billing is tied to results, the entire behavior of the delivery team gets re-sorted—you'll no longer spend three weeks polishing a feature nobody uses, because "nobody uses it" comes out of your own pocket. Platform vendors are following suit: Databricks has written milestone-based, outcome-aligned pricing options into its official delivery model.
• Move success measurement to before work begins: The first step of an FDE project is not writing code—it is defining "what success means" together with the customer. Palantir's bootcamp requires the customer to first lock in an extremely focused core battlefield—"reduce scheduling conflicts on a certain production line by 30%"—not "explore AI-empowered manufacturing"—precisely to prevent the project from drifting into the unfalsifiable under the banner of "exploration." The OpenAI and John Deere collaboration is a textbook example: first review hundreds of real work cases together with agronomy experts, build a custom evals system, and only then start iterating on the model. The final number—"chemical usage reduced by up to 70%"—was not a marketing line packaged after the fact; it was a target set before work began.
• The final judge is behavioral change in the customer's organization: That report contains a pointed finding: only about forty percent of enterprises provide employees with official AI tool subscriptions, while as many as ninety percent of employees use personal consumer-grade products to solve work problems daily. This means many "successfully launched" projects are actually in a state of "official systems idling while employees go around them." In the FDE philosophy, the milestone is not the day the system goes live, but the day the customer's team changes how it works. Sierra deliberately names the role "AI agent engineer," and when explaining hiring criteria, Møller said: only take on two kinds of problems—ones that are genuinely hard, and ones with genuine business impact—and both must hold at the same time.

"Let results speak for everything" sounds like common sense, but in execution it offends the entire structure of interests: 1) Sales can no longer over-promise, because the delivery team is accountable for results; 2) The customer's IT department can no longer get by with a "feature checklist," because the business unit's usage rate becomes the acceptance criterion; 3) The FDE themselves cannot claim exemption with "I finished it as specified," because whether the requirements themselves were right or wrong is also on their account. This is why the role is expensive—and why it is worth the expense.

1.6 The Four Faces of the FDE Within a Team ​

An FDE lives in four worlds at once; he is the connector among these four worlds.

• To the customer, he is an "embedded product manager + full-stack engineer": He observes the customer's real work like an anthropologist—the most valuable discoveries often come from "watching," not "asking"—and like an entrepreneur, he builds things on the spot in the field. Palantir institutionalized this two-person pairing: the Deployment Strategist (internal codename "Echo") is responsible for understanding the customer's mission, stakeholders, and adoption path, while the Forward Deployed Engineer (internal codename "Delta") handles technical implementation. Working as a pair, one diagnoses and one builds—neither is dispensable.
• To the company's product line, he is the "outpost and intelligence officer": This is the most fundamental difference between FDEs and traditional delivery teams. The cost of traditional implementation is a cost of sales—every person-day spent (billed per head per day) must be earned back from the contract; a healthy FDE organization treats field work as R&D—when three customers hit the same integration gap, that is not three troubles, that is a piece of product intelligence; when five deployments all need the same workflow, it should be abstracted into the platform's next standard capability. Former Palantir engineer Barry recalls that key components of the Foundry platform were born at customer sites in Zurich, Houston, São Paulo, Toulouse, and elsewhere, grew bottom-up, and eventually fed back into products generating billions of dollars in annual revenue. (Source: Appendix C)
• To sales: Enterprise customers have been let down too many times and are immune to all slides. The FDE rebuilds trust with two moves: first, hands-on work—building something that runs on the spot, on the customer's own data, in the customer's own environment; second, honesty—daring to say no to the customer's wrong premises. Palantir's bootcamp industrialized this trust-production process: customers bring real data, a deployable prototype is built in one to five days, and executives click through it with their own hands. Early bootcamps had a paid conversion rate of only 5% to 10%, while the company disclosed that later conversion rates approached 75%. (Source: Appendix C)
• To the organization itself: Palantir has produced a strikingly dense community of entrepreneurs—an interview on Lenny's Podcast gave one figure: nearly one-third of product managers there started their own companies after leaving. This is not surprising—an FDE's daily training is to build something valuable end-to-end and get people using it, in an environment of constrained resources, ambiguous requirements, and complex stakeholder relationships—almost a complete rehearsal for founder training. Srinivas, who later founded Decagon; Møller, who built Sierra's AI agent engineering team; and several authors of the most widely circulated methodology articles in this industry all came out of Palantir's forward deployed engineering roles. One company's talent spillover became an entire industry's talent infrastructure. (Source: Appendix C)

Taken together, these four identities amount to one thing: the way the organization understands its customers has changed—from secondhand information relayed through layers, to firsthand experience touched by engineers' own hands in the field.

1.7 How to Recruit FDEs ​

First, a cold splash of water: the FDE is one of the hardest roles to hire for in the software industry, because it requires one person to be excellent simultaneously on two dimensions that usually trade off against each other.

Former Palantir engineer Barry put it plainly in his memoir: Palantir's standard for hiring FDEs is "engineers who could get into Google or Facebook"—because they go to customer sites to build systems, not to tune parameters; but technical skill alone is far from enough—forward deployed people also need creativity, judgment, and presence in front of customers. He added a stinging remark: this is far more expensive and difficult than hiring a traditional pre-sales team.

Breaking down hiring-market practice, FDE recruitment has three key stages.

• Candidate profile: Hire "curious bulldozers," not "refined craftsmen." a16z's advice to startups used the phrase "curious doers": strong initiative, a lack of deference to the status quo, and hunger for customer problems. McGrath put it more concretely: an FDE team needs two kinds of people—"domain rebels": people who know the industry but don't worship its conventions; and "prototype speedsters": those who prioritize speed over perfection and accept that the first version will be thrown away and rewritten. Conversely, two types favored in traditional engineering culture are red flags for the FDE role: the "craftsman" who places code elegance above customer outcomes, and the "loyal executor" who treats every customer word as gospel. In its early years, Palantir simply put the filter at the very top of the funnel: a high-profile embrace of defense work, below-market salaries, and frighteningly long hours—Qureshi called this the "bat signal," effective only on its own kind.
• Interviews: Replace formulaic tests with "problem decomposition." As mentioned earlier, this stage is the soul of the FDE interview: give the candidate a vague, sprawling problem with real business rough edges—"a bank's compliance team manually reviews thirty thousand transaction alerts daily, ninety percent of which are false alarms; what would you do"—and then observe for sixty minutes. What is being assessed is not the answer but the process: whether they clarify constraints before acting, whether they distinguish root causes from symptoms, whether they remember a real user sits at the other end of the system, and whether they can clearly articulate trade-offs. Palantir also embeds about twenty minutes of behavioral questions in each technical round, and explicitly rejects candidates who are technically strong but culturally mismatched—the most important item in the culture check is a sense of order in the face of ambiguity.
• Compensation structure: Accept a hybrid structure of "engineer salary + variable bonus tied to company operating metrics." Market data from early 2026 can serve as an anchor: the median total annual compensation for a Palantir Forward Deployed Engineer is about $215,000; mid-level FDEs at top AI labs earn about $385,000, senior ones about $610,000; Anthropic's base salaries for these roles range from $200,000 to $300,000. Another notable detail is bonus design: Palantir's bonuses are often tied to operating metrics such as customer expansion, sitting somewhere between an engineering bonus and a sales commission; a16z's advice is to align incentives with the account manager, but don't put hard sales quotas on FDEs—that would steer behavior toward closing deals rather than delivering outcomes. One author who combed through fifty job postings offers a simpler litmus test: check whether the compensation package includes sales commission—where commission makes up a large share, it's mostly pre-sales with a trendy title. Compensation structure is also part of role definition: how you pay people shapes how they behave. (Sources in Appendix C)

1.8 How to Become an FDE ​

A different perspective: if you're an engineer, product manager, or consultant who wants to enter this fast-growing market, what's the path?

Start with a self-assessment: this role's glamour and its costs are two sides of the same coin. In practitioner communities on forums, discussions about FDEs have an unusual honesty. The positives: the best combination of technical substance and brand endorsement, one of the few roles where you build technical, business, and customer resources simultaneously. The costs: 25% to 50% travel is the norm—OpenAI's job posting explicitly states travel can be up to 50%; your work rhythm is defined by customer urgency, not your own schedule; and one recurring warning—the risk of burnout is real.

One comment: "Some see it as a brand springboard, others say it's consulting with a cool title—both are right. The difference is whether your company feeds field learnings back into the product, or sells you by the person-day." That sentence is both a criterion for choosing an employer and the theme of Chapter 7 of this book. (Sources in Appendix C)

Now the money in China. The dollar figures above are just background noise for most Chinese readers; in the first half of 2026, the domestic hiring market had already put a RMB price tag on this role: ByteDance offers its Doubao Forward Deployed Engineers 35,000–70,000 RMB per month with a 15-month salary structure; Ant Digital Technologies offers 40,000–60,000 with 15 months; Zhipu's FDE lead gets 60,000–80,000; Tencent Cloud 35,000–65,000 (the latter two didn't disclose the number of salary months); Alibaba Cloud 20,000–50,000 with 16 months. Converted to annual packages, these roles roughly fall between 300,000 and just over 1,000,000 RMB—"a million a year" is within reach at the high end of top roles, but it's not the industry average. (Sources in Appendix C)

The pay spread under the same title is more telling than the hierarchy gap. An industrial software company in Tangshan was hiring an "AI Delivery Engineer (FDE)," requiring a master's degree and on-site work in manufacturing, at 8,000–16,000 RMB per month—a gap of nearly ten times versus Zhipu at the widest. Behind the pay spread lie differences in platform foundation, customer quality, and pricing model. So when evaluating domestic opportunities, don't first check whether the business card has the three letters FDE; measure with the ruler from Chapter 8 of this book: does this company get paid for outcomes, or for headcount.

Then practice translation: most engineers already have sufficient technical foundations; what's scarce is the craft of "translation"—specifically three kinds: translating business problems into technical problems (Chapter 2), translating technical solutions into language executives understand (Chapter 3), and translating field experience into knowledge the team can reuse (Chapter 7). To practice these three, real reps beat classes: join one pre-sales engagement, do one on-site deployment stint, deliver training for one real user, then see in which kind of discomfort you grow fastest.

For interview prep, rewrite your résumé to be "customer-outcome oriented." The principle was stated earlier; let me stress it again: every technical achievement on your résumé must complete the last mile into customer language. "Built a retrieval-augmented generation (RAG, where the model looks up material before answering) system" is engineer language; "the RAG system I built cut customer service first-response time from 4 hours to 8 minutes, and the customer proactively proposed expansion at renewal" is FDE language. Also prepare two kinds of stories: one about establishing order amid unclear requirements, and one honest failure—Palantir-style interviewers are obsessed with "tell me about a real failure," because the essence of this job is advancing amid uncertainty, and someone who won't admit failure has no capacity to evolve.

When choosing a company, ask three questions in return. First, "What is your product platform?"—an FDE without a platform foundation is pure labor outsourcing. Second, "How does field learning flow back into the product?"—ask them to describe a recent example of field insight becoming a product feature; if they can't, that's a red flag. Third, "Who does the FDE report to?"—reporting into product or engineering usually means the model is taken seriously; reporting into sales means beware of becoming a pre-sales labor pool.

All of the above is written for engineers. What about people who don't write code? There's a place, and Palantir reserved it long ago: in that two-person pairing from Section 1.6, the Deployment Strategist codenamed "Echo" doesn't write code—the job is understanding the customer's mission, stakeholders, and adoption path. Looking further along this line, the change management in Chapter 4, the "train the trainer" mechanism in Chapter 5, knowledge-operations teams like Dewu's that embed in business teams to transfer tacit knowledge, and the technical content marketing in Chapter 3 are all entry points for non-engineering backgrounds. The common requirement of these roles happens to be the home turf of people from operations, consulting, and content: untangling the human stuff.

The last question can only be answered honestly: how far can this path go? No one has walked it to the end. The role is too new; there's no sample of a complete cycle yet, and only the structure is visible. The attrition side is real—the travel intensity and customer-urgency-driven rhythm mentioned earlier both get heavier with age and family stage. The appreciation side is also real—customer trust, industry judgment, and cross-organizational prestige all compound with tenure.

There are roughly three exits: 1) return to the product line—those who temper field experience into platform thinking are natural candidates for product leadership; 2) start your own company—nearly a third of product managers who left Palantir founded their own companies; 3) go to the customer side—after reading the state-owned enterprise stories in Chapter 8, you'll know that what customers lack most is precisely people who understand the vendor's playbook. Which one holds will only be answered in five years. The only certainty now is one sentence: this profession prices "endurance," but only if you're at a company that treats field learning as an asset—otherwise all you accumulate is tenure.

1.9 The FDE's Everyday Toolbox ​

Finally, here is the current tool landscape for this role. Tools will become obsolete, but the capability layers behind them won't. Five layers, from underfoot to behind you.

• Platform foundation layer. The premise of the FDE model is "bringing the platform to the field"; otherwise it degenerates into custom development. Palantir's Foundry and AIP center on something called the "ontology"—modeling an enterprise's data, logic, and actions into a semantic layer so that AI runs on a foundation that "understands the business"; OpenAI's model APIs and agent toolchain; Sierra's agent platform. When evaluating any FDE opportunity, the thickness of this layer is the first priority.
• AI engineering layer. The daily craft after 2025 includes: prompt engineering and context management; retrieval-augmented generation (RAG); evals: building quantifiable yardsticks for fuzzy business quality—this is the signature skill that distinguishes the AI-era FDE from traditional implementation engineers; agent architecture: tool calling, multi-agent collaboration, and keeping humans in the loop at critical junctures; and engineering optimization of cost and speed.
• Data and integration layer. Nearly every FDE project spends its first week wrestling with this layer: data pipelines, enterprise system connectors, permissions and identity authentication, vector databases for AI retrieval, and data governance and anonymization (hiding sensitive information). Qureshi also has a rule of thumb: of enterprise data problems, 95% is ingestion, cleaning, and joining—not analysis at all—70% of project progress gets stuck at this layer, but it never shows up in the demo.
• Delivery and collaboration layer. Working within a customer's security perimeter means "dual adaptation": you must master your own modern toolchain while also being able to bend to the customer's environment—it may be an intranet physically isolated from the internet, deployment may only be possible in the customer's cloud environment, and you may not even be able to access code hosting sites. Containerization (the technology for packaging up and taking environments with you), infrastructure as code (managing server environments with code), and contingency plans for "getting the environment running even in a meeting room with no internet" all belong to this layer.
• Knowledge accumulation layer. This is the most easily overlooked layer, yet it determines whether the team can escape "revenue growing linearly with headcount": playbooks, component libraries, deployment checklists, and the writing habit of rewriting "a solution for one customer" into "a pattern for a class of customers." Chapter 7 will expand on this in detail.

Taken together, the five-layer toolbox forms the complete profile of this role: built on a platform foundation, with engineering as the craft, accountable for customer outcomes, while staying connected to the company's product line.

Over the next seven chapters, we dive into the heart of the methodology, starting from the most fundamental choice of any project—how to make sure you are solving the right problem.