How to Use This Book

12 min read

H
Part I · The Role

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.

H.1

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.

H.2

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.

Tier
What it means
An example from this book
T1
Measured, primary and independent of the vendor.
The Markup, Documented and THE CITY tested New York City's MyCity business chatbot themselves and found it telling businesses to break the law. The city took it down on 4 February 2026 (The Markup).
T2
Measured and primary, but reported by the vendor or the customer itself.
Palantir's 2020 S-1 filing, which says pilots run "at no or low cost" and "at a loss", and breaks out revenue and margin by customer phase (SEC).
T3
Secondary reporting: a journalist or analyst relaying what someone else measured or said.
The Register's report that 45 NHS trusts, fewer than a quarter, were actively using the Federated Data Platform by the end of 2024 (The Register).
T4
Anecdote, opinion or a job post.
OpenAI's FDE posting, which says the FDE owns "discovery, technical scoping, system design, build, and production rollout" (OpenAI, via Thrive Capital).

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.

H.3

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.

H.4

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.

H.5

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.

H.6

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.

Situation
Go to
Why
Sales promised a free, open-ended proof of concept
The pilot's terms decide whether anything ships. Change them before you start.
Nobody can name who signs if the pilot works
A pilot without a sponsor who owns the KPI has nobody to convert it.
The pilot has no end date
Open-ended pilots drift. Fix the duration and the exit criteria in writing.
The customer asked for "a chatbot"
The stated problem is a hypothesis. Go and watch the work before agreeing to it.
Every stakeholder describes a different problem
Record each one's definition of "better", then find the business lever they share.
You're asked to pick a model before seeing the workflow
The model choice comes last. The workflow decides what the model has to do.
The use case is safe, but nobody would notice if it worked
Pick high stakes and small scope. An edge case wins nothing.
Nobody has measured how the process performs today
Without a baseline there is no win to claim. Measure it in week one.
The executive wants a demo on Friday
Demo the real workflow on real or redacted data, and say what isn't done.
Scope grows in every meeting
Write it on the "not now" list instead of refusing it.
No production-like data access by the end of week one
An early warning sign. Build on sanitised fixtures and escalate the access.
They want the agent to write back into a legacy system
Writing back is harder than reading. Defer it and deliver into an existing queue.
Security sent a 200-question questionnaire
Split it three ways and answer the AI questions from one answer sheet you send first.
"Will our data train your model?"
Usually the gating question. Answer it with retention terms, not reassurance.
User-uploaded documents feed the agent
That is an indirect prompt-injection path. Let the agent propose, never act.
Accuracy is stuck around 80%
The last stretch to the threshold is usually where the weeks go. Grow the eval from real failures.
The eval scores are fine, but users hate it
Have the experts label a sample of overrides; add the dimension the eval is missing.
You have to tell the sponsor it isn't good enough yet
Bring the bad news early, with a plan and a date.
Their infrastructure forbids the service you planned on
Design for their constraints from the start, not for your reference architecture.
A rule must never be broken by the agent
Enforce it in code outside the model.
You leave in two weeks and only you can run it
Run a handoff drill: their team deploys, breaks and recovers it from the runbook alone.
It works, but nobody uses it
Trust takes longer than the build. Plan for the adoption months.
You built the same thing for the third customer
That is a product feature waiting to be written up with evidence.
The sponsor changed jobs
Priority shifts are a leading cause of failure. Re-sponsor or reset the scope fast.
Should you walk away?
Decide with the sponsor, against the exit criteria you wrote down before you started.
You're asked to promise deterministic outputs
Know which commitments are load-bearing before you make one.
Is this role right for me?
Start from what the job is actually like, sceptics included, then place yourself on the map.
You're preparing for a decomposition interview
Treat the round as discovery on a clock: the lever, the first win and the number before the architecture.
Two offers with the same FDE title
Place the employer first: ask what it buys with an hour of your time, then compare pay.
You've just been made an FDE manager
Measure thresholds crossed and signal sent to product, not hours billed.
More engagements, but no promotion
Volume repeats the same evidence. Plan one piece of work that happens without you.
No gap between engagements in a year
Count site, pager and back-to-back engagements, and ask for the gap in writing.

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.

H.7

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.