Four ways through this wiki

An encyclopedia is a bad place to start learning, because it has no opinion about order. This page supplies one: four routes, each with a reason for the sequence, and each ending somewhere useful rather than at the last article.

If you have twenty minutes

Read three things in this order. What a forward deployed engineer is for the definition, the four responsibilities for why they stay in one person, and the metric definition table because it is the artefact that separates this job from a demo. If those three make sense, the rest of the site is elaboration.

Path one — entering the field

Built for an engineer who can already build and wants the job. The order moves from what the role is, to what it is judged on, to how to get in.

1. What an FDE is and how it differs from presales and consulting — the boundary you will be asked about in every interview.
2. The four responsibilities — the loop, and why the fourth part is the one that makes the role worth having.
3. The capability model — six areas, and the evidence for each.
4. How people become FDEs and whether you need a degree — entry paths without the mythology.
5. The delivery method and scoping — the vocabulary you will need in the room.
6. The discovery question bank and the six-step requirements interview — run one session on a process you already know. This is the exercise that changes how you interview.
7. What an interview tests and where the roles are.
8. What FDE pay actually is — read it before you read a job listing, so the number on the listing has a denominator.
9. If you intend to work independently rather than join a team: where the first clients come from and which deals to refuse. Read the second one first; the arithmetic is less pleasant and more useful.
10. Optional, and the most useful optional on the site: training programmes, which explains what a course can and cannot buy before you spend anything.

Path two — deciding whether to build a deployment function

Built for a founder or a product lead who has customers asking for things that do not fit the roadmap.

1. The 2026 market landscape — what is being bought, by whom, and at what scale.
2. Why FDE now — the structural reason the role appeared rather than a fashion.
3. Five levels of enterprise AI maturity — where your customers actually sit, which decides what you can sell them this year.
4. The four responsibilities — specifically the fourth, because that is the one that produces compounding value.
5. Five ways to organise FDEs — build, partner, integrator, studio, or internal. The choice is made by who owns the customer relationship, not by headcount.
6. The five stages and the seven-day sprint — the method you would be buying.
7. Six gates to production — the distance between a demo someone liked and a system someone depends on.
8. Three pricing models — priced per head, per stage, or per result; the customer's data maturity picks for you.
9. The seven-figure quote that died — why coverage and quote eligibility are different questions.
10. The four-week rule and the readout template — how you would know whether it is working.
11. The sunset clause — the exit, planned on day one.

Path three — you are the customer

Built for the team on the receiving end, who has been sold "AI transformation" and wants to know what a good deployment looks like from the inside.

1. What an FDE is — so you can tell the role from a sales engineer.
2. Is an FDE a pre-sales role — the questions that reveal which one you are dealing with.
3. The discovery question bank — the questions you should be asked. If nobody asks them, that is the finding.
4. The stakeholder map — who on your side has to be in the room, and what happens if only IT is.
5. Working inside your security boundary — what to settle before any data moves.
6. Ten clauses to insist on in a statement of work — the document that decides whether the project is arguable in month three.
7. Designing the test set before the system — how acceptance is settled before anyone writes code, and what "not verified" has to look like on the form.
8. The runbook — what you should be handed at the end, and how to test it.
9. The four-week rule — the only question that matters in month two: is it still being used, by whom, without anyone chasing.

Path four — the practitioner's shelf

For someone already doing the work, who does not need the introduction. These are the pages people come back to.

The metric table · scoping and pricing · the first-week prototype · debugging on site · the escalation path · a 200 is not a business fact · the evaluation harness · the readout · the runbook · the six-section anatomy · the glossary.

The cases, if you only read four

The bakery for a deployment that worked and what it cost, the seven-figure quote for one that was technically right and still died, the 120,000-yuan system for what an outsourced build fails to buy, and the four-week, 1,506-turn review for what actually speeds up when a team adopts AI heavily and what does not.

What is deliberately not here

No course rankings, no salary leaderboard, no "top ten tools". Those pages age badly and they invite the reader to substitute a purchase for a practice. Where the site does discuss programmes and pay, it says what the numbers are and who reported them, including when the source is a community survey rather than an official one.

If a page you want does not exist, the submission form exists for exactly that. A question asked twice becomes an article.