The encyclopedia

What a Forward Deployed Engineer is, where the role came from, and how to tell it apart from presales and consulting.

• What a forward deployed engineer is responsible forThe role is defined by three responsibilities that must hold at once — embedded in the customer's environment, owning the production result, feeding it back.
• Why the role appeared nowExecution became cheap and understanding did not, so the bottleneck moved to the part of the work that was always the real risk.
• Presales, consulting, implementation, FDE: four jobs behind one confused titleThe four roles differ on who signs off, who builds, who carries acceptance risk and what success means — and one succeeds by making itself unnecessary.
• Four responsibilities, and the argument for keeping them togetherFinding the real problem, building the narrow version, making it used, and carrying it back into the product. Split the fourth off and the role becomes consulting with a shell.
• Four ways through this wikiThe same forty articles arranged for an engineer entering the field, a company deciding whether to build deployments, a customer-side team, and anyone with twenty minutes.

Who becomes an FDE, how people actually get in, what the ladder looks like, and what the job pays.

• How people actually become forward deployed engineersSix capability areas, the evidence that proves each one, and why temperament — not the technology stack — is the scarcest input.
• The ladder, and what pay actually tracksFive levels from demo-capable to organisation-affecting, the signal at each transition, and why identically titled roles span roughly tenfold.
• What an FDE interview actually testsThree rounds, eleven questions, and the one habit that fails candidates who are technically strong: answering with a technology before naming a metric.
• Where the roles are listed, and why the listings misleadLabs, deployment shops and vertical SaaS post under three different names. A map of where FDE roles actually appear, and how to read a listing that never uses the word.

The capability model: engineering depth, domain fluency, delivery judgment, and the parts of the job no course teaches.

• Six capabilities that only work togetherWhy the FDE capability model fails as a checklist, which combinations break first, and what evidence to demand in an interview.
• Seven questions for the first two weeksThe seven questions an FDE must answer before quoting, what a good answer sounds like, and what self-deception sounds like.
• Three maps: money, authority, who losesReconnaissance produces three maps in a fixed order — money flow, authority flow, and who loses. The third one decides feasibility.
• Shadow systems: the process that actually runsThe real process lives in spreadsheets, group chats and handwritten ledgers. How description drifts from execution, and how to extract the one that runs.
• What leaves the human loopOne test decides what an agent can own — whether the input can be delivered into an interface. Three data cases and three ways out-of-the-loop fails.
• Debugging where you cannot deploy a fixThe customer's environment removes the two things engineers rely on — reproduction and fast iteration. Four constraints, and the order of moves that still finds the fault.
• The three people who decide whether it survivesSponsor, owner and operator carry different powers and are often different people. A map of who can spend, who can adopt, and who can quietly kill a deployment.

How a deployment actually runs: scoping, definition, build, handover, retreat — with the checkpoints that keep it honest.

• Five stages, four handoversEach stage ends with an exit condition and a named artefact; projects die at the seam where that artefact never changes hands.
• The five columns that make a goal testableMetric definition, data source, a window of at least four weeks, exclusion rules and a named arbiter turn agreement into an acceptance test.
• The right to quote is earned, not assumedFour translations turn a complaint into a number, four blocks make a quote, and a finished investigation is what gives an FDE the standing to send one.
• The prototype that keeps the right to be dislikedThe first-week prototype has five minimum conditions, and the one teams drop is the one that matters: it must let the customer reject it at no cost.
• Four weeks is the shortest honest test of aliveGoing live is an event and activation is a habit; a feature counts as alive only after four consecutive weeks, and a disable rate above 30% removes it.
• The sunset clause, written on day oneFive fields fix when a deployment ends, what the review must produce and who the FDE is afterwards, so extraction is designed rather than improvised.
• Working inside someone else's security boundaryWhat an FDE has to settle before touching customer data: the four questions that decide architecture, and the three habits that keep a deployment legal after it ships.
• Who gets called, and what they are toldAn escalation path is a list of names and thresholds agreed before anything breaks. Four levels, two sentences per update, and the review that has to end in a change.
• Seven days, one round of real evidenceA day-by-day plan for the first field cycle, and the three artefacts it must produce. The point is not to finish — it is to arrive at day eight knowing something you could not have guessed.

Anonymised deployments dissected the same way every time: the ask, the real problem, the build, the result, and what broke.

• Halving bakery waste by asking for the numbersA 23-shop bakery chain cut annual waste from RMB 1.3m to 0.6m without new cameras, because the forecast was already sitting in its stores.
• The seven-figure quote that hit 100% and died the same dayA proposal that covered every stated requirement was rejected within a day. Coverage and quote eligibility are different questions, and only one of them is about the customer.

Who is hiring, how the deployment company model works, what the Chinese market looks like, and where the money actually is.

• The 2026 deployment wave, read as numbersModel labs and integrators stood up deployment organisations within two weeks in May 2026. The figures describe a channel being bought, not a hiring trend.
• China's FDE bottleneck is not the engineersRoughly 60 million firms, broad awareness of AI, and on the order of a thousand people willing to take delivery work. The constraint sits in pricing and platforms.
• What a training programme can and cannot buyBootcamps, cohort courses and 32-week academies each sell something different. What a paid programme reliably provides, what it cannot, and how to judge one before paying.

Reusable artefacts: discovery question sets, scoping templates, handover checklists, and the documents buyers actually sign.

• The six-section anatomy: the one shape a finished deployment may takeWhy every finished deployment is written up in the same six sections, in the same order, and what each position is protecting.
• Anonymizing a case: three layers and a recombination testEntities, numbers and time are the item checks. The hard part is what three harmless details say together.
• The discovery question bankFour sets, thirty-one questions, and what a bad answer sounds like — the interview that turns "we want AI" into a number, a data source and a named owner.
• The one-page readoutSix blocks, ten minutes, and a decision at the end. A template for the meeting where a deployment is continued, narrowed or stopped — and the four ways these meetings fail.
• The runbook someone else can operateNine sections a handover needs, the test that proves it works, and why a runbook written by the person leaving is usually missing the only part that matters.

The vocabulary of forward deployment, defined once so the rest of the site can use it precisely.

• FDE glossary: one rendering per termTwenty-two terms, one fixed translation each, and the three things this site will not let anyone rename.

The questions people actually ask before entering the field, answered without the sales voice.

• Is an FDE a pre-sales role?No. The job title decides nothing and the responsibility scope decides everything — four boundary rules and three questions to ask.
• Do you need a computer science degree?No employer requires one, and some paths are easier without the wrong one. What the role actually screens for, and which fundamentals it will not let you skip.
• How much travel, and whether it can be remoteThe on-site share that actually makes the method work, the arrangements that reduce it honestly, and the deployments where a remote FDE produces a different job.
• How long before you run a deployment yourselfThe usual shape — weeks shadowing, weeks co-delivering, a first owned module around month three — and the three things that decide whether it is faster or much slower.