What does a forward deployed engineer actually do day to day?
Updated
A plain account of FDE daily work: discovery, building with the customer, production delivery and handover.
A forward deployed engineer works inside the customer organization and ships systems that survive contact with real data, real permissions and real change windows.
The short answer
An FDE discovers the real problem with users, builds a small working system with them, puts it into production under customer constraints, and hands it over with docs and training.
A typical week
Monday: discovery. Two or three interviews with operators, not executives. The output is a one page brief: who does the work today, where it breaks, what good looks like in numbers.
Tuesday to Thursday: build. Small slices, each demoable. A typical slice: connect one source, normalize five fields, show the result to one user, fix what they point at. Repeat.
Friday: readout and hardening. A production readout for stakeholders: what shipped, what the numbers say, what breaks next. Then runbook updates, access reviews and a rollback check.
Worked example: returns triage at a fictional retailer
Context is fictional and labeled as such. A fictional retailer, Northwind Retail (fictional), processes 400 returns a day across two warehouses. Staff triage by email and a shared spreadsheet.
Week 1, the FDE shadows two shifts and finds the real cost: 35 minutes per disputed return, mostly spent finding the original order. The brief sets one target: cut lookup time under 3 minutes for 9 of 10 cases.
Week 2, the FDE ships a lookup page over the existing order store: scan the return label, see the order, the items and the refund path. No new database, read only, behind the customer SSO. Four users test it on live labels.
Week 3, edge cases: split shipments, gift orders, partial refunds. Each gets a rule plus a fallback to manual review with a reason code. The runbook lists the three most common failures and the fix for each.
Handover includes: the lookup page, the rule table, the runbook, a 30 minute training recording and a named owner on the customer side. The FDE leaves; the page stays up.
Decision table: what the FDE does and does not do
| Situation | FDE does | FDE does not do |
|---|---|---|
| Vague request | Runs interviews, writes acceptance criteria | Starts building from the ticket text |
| Blocked integration | Ships a narrow adapter with tests | Replatforms the customer system |
| Model request | Compares rules, retrieval and models on cost and error modes | Picks the newest model by default |
| Launch | Plans rollout, rollback and owner training | Ships on Friday without a contact |
Checklist: a healthy FDE day
- Talk to at least one real user before writing code.
- Ship one slice that someone outside your laptop can click.
- Write down one assumption with an owner and a check date.
- Leave the system more operable than you found it: one doc, one alert or one test.
Related reading
- FDE Foundations Module 1 covers the role boundary.
- The delivery loop guide covers discovery to handover.
- The readiness quiz shows which modules to revisit.
Straight answers
Frequently asked questions
Is an FDE a salesperson?
No. An FDE ships working software at the customer. Demos explain decisions; delivery is the job.
Does an FDE write code daily?
Most days yes: integrations, data checks, small services and fixes inside customer constraints.
What is the main deliverable?
A running system plus a handover package the customer team can operate alone.