How to Use This Book
Most of what is written about Forward Deployed Engineers is confident and unsourced, so this book grades every claim and tells you how far to trust it. Use it by situation: find what is going wrong, go to that page, and take the template with you.
Who this book is for, and three ways to read it
This book is for two kinds of reader: engineers who want the Forward Deployed Engineer job, and engineers who already have it. Both need the same thing, which is an honest account of what the work is and how it goes wrong. Its argument fits in one sentence. The model was never the hard part. The distance between a capable model and a customer outcome is made of a misread problem, data nobody can reach, a review nobody planned for, a number nobody agreed and a system nobody owns once the vendor leaves. The FDE is the person paid to own that distance.
There are three ways in.
- You want the job. Read Part I for what the role is, where it came from and the skill map that describes it level by level. Then read Part IV on where FDEs work and how they get hired. Part II will make more sense once you have watched one engagement end to end.
- You are doing the job. Go straight to the Part II chapter for the phase you are in. Each one follows the same order: what the phase is for, the next step of the running example, the playbook, a template (blank, then filled in), the signals that the phase is failing, and a checklist for moving on. Start with Before the Engagement if the pilot hasn't been signed yet, Discovery if you are on site, or Scoping and the First Win if you have to commit to a number. If you lead FDEs or are planning your next level, Part IV has Leading FDEs and Levels, Burnout and What Comes Next.
- Something has gone wrong. Use the situation index below. It starts from the symptom ("accuracy is stuck around 80%", "the sponsor changed jobs") and points to the page that deals with it.
It helps to know what the book is not. It is not interview preparation: company-by-company guides already exist, and the Getting Hired chapter sums them up and links out. It is not a course on the AI stack, because the rest of this wiki already is one, and chapters link to it rather than repeat it. And it is not a history of Palantir. The role's origins get one chapter, because the economics behind them still decide how pilots are priced.
How the evidence is graded
Every case and figure in the book carries a tier, stated in the sentence that uses it. There are four.
The line between T2 and T4 is measurement: a vendor's or customer's own measured result is T2, while its advice, doctrine, stated targets or opinion are T4.
Job posts need a word of their own. As evidence of how the work is actually done, a job post is T4: it is what a company hopes the job is. As evidence of what employers ask for, the same post is primary. The book says which of the two uses it is making.
One admission belongs at the front. Independent, measured evidence on how FDE engagements run barely exists. Vendors publish their wins, customers publish their adoption numbers, and almost nobody outside either side measures anything. Of the ten strongest cases this book draws on, the only one with an independently measured outcome is a failure: the MyCity chatbot above. That doesn't make the rest worthless. It means a T2 success story should be read as the vendor's best account of itself, and the book will tell you when that is all there is. Where a whole chapter rests on thin evidence, the chapter says so at the top.
Echoes: one number, many headlines
An echo is a single self-reported figure that several outlets repeat until it looks independently confirmed. Writing about FDEs is full of them, because the role became fashionable faster than anyone measured it. Two examples show the pattern.
The job-posting growth figures. One widely shared figure has FDE postings rising from 643 in April 2025 to 5,330 in April 2026, an increase of 729%. Another has them rising more than 800% between January and September 2025. Both trace back to Indeed's own postings data, relayed through Business Insider and the Financial Times and then re-relayed by many sites in English and Chinese (Scaler, Storyboard18; both T3). The two figures cover different windows, so they can't be combined into one growth rate, and the number of outlets repeating them adds no confirmation. It is one source, counted many times.
Morgan Stanley's 98%. Morgan Stanley's own press release says "98% of Financial Advisor teams have adopted" its OpenAI-based assistant (Morgan Stanley, T2). OpenAI's enterprise guide repeats the number as "98% of Morgan Stanley advisors use OpenAI every day" (OpenAI, T2). Teams that have adopted a tool and individuals who use it every day are different measurements. Along the way the figure changed what it was counting.
The rule in this book: where we find an echo, we name it, and we trace the number to its source.
Composites: the messy middle, labelled
Nobody publishes the messy middle of an engagement. Vendors publish the launch, customers publish the adoption figure, and the weeks in between, when the data wasn't there and the sponsor went quiet, stay private. Yet those weeks are the job. So Part II follows one composite engagement from the first sales call to the post-mortem, one step per chapter.
A composite is invented, and the book never pretends otherwise. Three rules hold it to the evidence:
- It always sits in a box marked Composite, so it can't be mistaken for a reported case.
- It uses ranges, never point figures, and it never names or hints at a real company.
- Every step ends by citing the real, sourced pattern it dramatises, so you can check the pattern even though the story is made up.
Here is how it begins.
The insurer. A regional property-and-casualty insurer with somewhere between 2,000 and 5,000 staff. It runs an on-premises claims system and a large document store, and has a strict model-risk function. Its new chief operating officer wants AI to show results within the year. The vendor is an AI platform company. Its team is one mid-level FDE (the protagonist), a senior FDE lead working part-time on the account, and an account executive. As Before the Engagement opens, sales has already promised the insurer a free three-month proof of concept with "a customer chatbot". Over the ten chapters of Part II that promise becomes a paid pilot, the chatbot turns out to be the wrong problem, and the real one (claims documents nobody has time to triage) gets scoped, built, evaluated, handed off and, finally, stalled. The pattern behind the opening: Palantir's S-1 records pilots run "at no or low cost… at a loss" (T2), and the free proof of concept is the term the next chapter sets out to change.
Verified boxes: facts with a shelf life
Some facts go out of date within months: pay bands, headcounts, which company hired whom, product names, the date a policy took effect. The book puts these in a box stamped with the month they were checked, so you can see how old each one is. The argument around a box never depends on it. Delete the box and the chapter still stands. Here is one.
O'Reilly's The Forward Deployed Engineer by Paden Gayle is in Early Release: 2 of its 12 chapters are available, and the publisher's record gives a publication date of 25 December 2027 (O'Reilly, T2: self-described). The chapters out so far cover the role's boundaries and discovery. When it is finished it will be a serious companion to this book. The two differ mainly on evidence: this book grades every claim.
The situation index
Find the row that sounds like your week. Each row links to the chapter that deals with it, and to the section where one fits.
The index is the page to come back to. New rows will be added where readers keep landing in situations the book doesn't yet cover.
A note on the term
There is no settled Chinese name for the role. The Chinese edition uses 前线部署工程师, the most common rendering in the press and the title Tencent uses in its job ads. A Beijing municipal policy document of July 2026, 京发改〔2026〕1185号, uses 前沿部署工程师 instead (Beijing Municipal Government, T2), and other outlets use 前置 or, in Taiwan, 前線. One rendering, 前端部署工程师, is misleading: 前端 means front-end, and the role has nothing to do with front-end development. The book says this once, here and in the glossary, and then uses one term throughout.
The book is written for readers in both languages, so neither market is an afterthought. English readers will find the Chinese market, its titles and its pay covered in Part IV. Chinese readers will find the US data graded in exactly the same way, echoes included.
Bookmark the situation index. When an engagement goes sideways, start from the symptom rather than the table of contents. If you want the same evidence-graded treatment of AI across the whole software lifecycle, the companion book is From SDLC to AI-Driven SDLC.