What an FDE Actually Is — What Result Is This Person on the Hook For?

The price of greatness is responsibility. — Winston Churchill, Harvard address, 1943

In 2026, three people all have "Forward Deployed Engineer" on their business cards. Their jobs look nothing alike.

The first spends about 75% of every day on model optimization and engineering code. The second serves ten customers at once, splitting time evenly between meetings and development, always on call for production issues. The third sits in a customer's office gathering requirements, builds a prototype with AI on the spot, and hands it to the backend team once it's confirmed.

Same title. Three different jobs.

So judging whether a role is really an FDE role can't rest on the business card. It has to rest on what result the person is on the hook for, and how far that responsibility goes.

I. First, Admit It: The Title Doesn't Help

Define FDE off any single company's job posting, and you won't get the full answer.

The same title can mean completely different jobs and requirements. Baseten lists model optimization and infrastructure engineering as the core of the role¹. A European company's 2026 remote FDE listing asks for Python, SQL, and the ability to build a PoC². One FDE at a major Chinese tech company described a different routine in a Linux DO forum post: visit customer sites to gather requirements, build a prototype with AI, then hand it to the backend team once it's confirmed³. Three companies, one title, three different jobs.

The reverse also happens: some roles carry the full weight of FDE work under a different name. A company might call it "Solutions Engineer," "Delivery Engineer," "AI Application Architect," or simply "the person on the Customer Success team who writes code."

This isn't just naming chaos. FDE took shape inside specific companies first, and different organizations then adopted it on their own terms — so the job's shape naturally varies. But the core responsibility underneath tends to look much the same.

II. A Condensed Definition

To understand why FDE exists at all, start with Bob McGrew. He lived through Palantir's FDE model firsthand, then went on to become OpenAI's Chief Research Officer. On a Y Combinator podcast, he summed up the role this way: an FDE delivers many capabilities to a single customer. A traditional software engineer does the opposite — builds a single capability for many customers⁴.

A product engineer turns one capability into a general-purpose product and ships it to many users. An FDE faces one specific customer and has to wire several capabilities into that customer's systems, permissions, workflows, and working relationships — get them running, and keep them running. McGrew breaks the process into four moves: get on-site, prototype fast, iterate continuously, wire it into production. All of it happens on-site, at the customer.

At Palantir, the people doing this work split into two teams: Echo and Delta. Echo is the business front line — on-site analysts and account managers who decide what problem the customer should solve. Delta is the technical front line: deployment engineers in the strict sense, who turn the plan into a system that actually runs⁴⁵. Chinese companies often don't split the work across two teams at all — the same person or small group carries both⁵.

This division doesn't run along seniority, tech stack, or whether someone knows machine learning. It splits along exactly one line: who decides what to do, and who makes it happen.

One clarification before moving on: FDE refers to both a role and an organizational unit. Its complete form isn't one person — it's a small team stationed at the customer. Echo/Delta and the Chinese trio in Chapter 26 are the same small team, cut two different ways; a solo FDE is that same unit, compressed into a single person. Most of this book takes an individual's point of view, but behind that "individual" always stands a team that can be split apart or merged back together.

III. Where an FDE's Time Actually Goes

Job descriptions don't always reflect the real work; calendars usually tell the truth better. Het Trivedi, an FDE at Baseten, publicly broke down his own time: about 75% on software engineering and model optimization, 15% on technical consulting, 10% on customer relationships¹.

These numbers clear up two common misconceptions. An FDE isn't a "presales rep who happens to code," closing deals mainly through conversation — engineering eats most of the time. Nor is an FDE just an outsourced coder sent in to write to spec — real time still goes into understanding the problem and working with the customer.

This is one company's design for the role, not an industry average¹. But it makes one thing clear: FDE work is mostly engineering, and that engineering has to happen inside a customer relationship. This pattern comes back again and again later in the book: what you're responsible for is where your time goes.

That's a U.S. sample, though. Chinese FDEs likely spend more time untangling business problems and maintaining customer relationships. One practitioner said about 60% of their time goes to exactly that, with technical work taking a smaller share — Chapter 18 works through the full China time breakdown.

IV. The Four Responsibilities

On a Chinese developer forum, one FDE summed up their workflow this way: "Dig into the business → design the process-improvement plan and technical architecture → build → train / roll out gradually / adjust business processes → feedback / monitor / fix / optimize cost"⁶.

This process breaks down into four categories of responsibility an FDE has to carry.

A complete FDE is on the hook for all four at once.

1. Discovery — deciding which of the customer's scenarios is actually worth doing. Not building whatever the customer asks for, but sorting a "vague wish" into a "problem worth solving." (Chapter 6)
2. Production — getting it running safely, stably, and maintainably in the customer's real environment, not stuck in a demo. (Part Three)
3. Adoption — making sure real users actually use it; going live isn't the same as being used. (Chapter 15)
4. Feedback — carrying what was learned on-site back into the product, so the next customer moves faster. (Chapter 22)

Looking back at that forum post: "dig into the business" is Discovery, "build" is Production, "train / roll out gradually" is Adoption, and "process improvement, distilled" is Feedback. It lines up closely with the four responsibilities (see Figure 1-1).

Figure 1-1: FDE responsibility isn't a single handoff — it's a four-stage loop of Discovery, Production, Adoption, and Feedback.

Carrying all four at once is what makes the complete form of FDE. Carrying just one or two can still be part of FDE work — that isn't a ranking. Most roles only cover one piece to begin with; what matters is knowing which piece is yours.

V. Three FDEs, Same Week

The following is an anonymized composite, used to demonstrate how the four responsibilities apply.

P, a model-platform FDE. Mornings are spent tracking down latency spikes in the customer's model inference. Afternoons, he walks the customer's algorithm team through the trade-offs of a batch-processing interface. His responsibility centers on Production — discovery comes from platform colleagues, driving adoption is the customer's own team's job, and feedback flows through the platform roadmap. On the four-part map, he mostly sits in the second box.

M, a multi-customer FDE. Ten active customers, fifty hours a week, split evenly between meetings and building. Morning: signs off on a data interface design in a joint session with Customer A. Midday: handles a production alert for Customer B. Evening: writes a status report for Customer C. He touches all four responsibilities, but none of them gets enough time — his risk isn't capability, it's attention diluted across ten customers.

W, an on-site prototyping FDE. Inside the customer's office: mornings go through requirements with the business team, midday assembles the confirmed workflow into a clickable prototype with AI tools, afternoons hand the prototype to his company's backend team to build the production version. Discovery and prototyping are his; Production and Feedback live elsewhere. On the four-part map, he covers only part of the first box.

All three carry the FDE title. Mapped against the four responsibilities, they carry very different loads.

Which one is the "real" FDE? All three earn the title. The more useful question is where each one sits. Only once the position is clear does it make sense to talk about performance metrics, career transitions, or business models.

VI. To Close

This chapter comes down to three sentences:

• FDE isn't a fixed job description — it's a responsibility structure: accountability for results that actually run, stay maintainable, and can be measured inside a customer's business.
• Don't judge by the title. Check four things instead: does the code go to production, does field experience flow back into the product, is adoption someone's job, and how far does the accountability for results actually extend.
• Wide variation under the same title is the norm. The four-part map measures position, not rank.

With the standard set, a new question shows up immediately: where exactly does this responsibility structure end and its "old neighbors" — presales, consulting, outsourcing, customer success — begin? That's Chapter 2.

---

Footnotes

1. Baseten, "What I Learned as a Forward-Deployed Engineer Working at an AI Startup" (Het Trivedi) ↩ ↩² ↩³

2. European remote FDE job listing (reposted by @afahmy_dev on X) ↩

3. "Anyone Out There Actually Doing FDE Work?" (linux.do thread) ↩

4. Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩ ↩²

5. Tencent Research Institute, "FDE Model: Industry Observations and Practice"; Si Erxun, "The FDE Delivery Paradigm Revolution" ↩ ↩²

6. linux.do thread, post #2580046 ↩