The FDE Role
- Trace the FDE lineage from Palantir to the current AI-lab wave and explain why the role exploded with LLMs
- Describe the three hats — consultant, product manager, engineer — and when each is worn in an engagement
- Differentiate FDE from solutions engineer, sales engineer, and product engineer on concrete axes
- Walk the engagement lifecycle from discovery to handoff and name the deliverable of each stage
- Read real FDE job postings critically and map your own evidence to their requirements
| Spaced-rep warm-up: Week 23 due cards + check what fired in prod overnight | 10 min |
| ELI5 + tech read; write the three hats and lifecycle from memory | 20 min |
| Guided: job-posting dissection + lifecycle mapping | 35 min |
| Practice: three-hats reflex drill | 15 min |
| Project: FDE positioning memo | 25 min |
| Quiz + flashcards | 10 min |
Builds on: Day 105 — Explaining LLMs to non-technical stakeholders · Day 146 — Communicating quality to stakeholders · Day 160 — AI system design
When an armed force buys a new radar system, the manufacturer doesn't just ship crates and a manual. It sends a field engineer who lives on the base for months: someone who knows the radar's guts cold, but spends most days learning the BASE — how this squadron actually flies, what the maintenance chief worries about, which workflow the manual's authors never imagined. The field engineer adapts the system to the base, radios design flaws back to the factory, and by the end has quietly become the most trusted person on site: the one who speaks both languages.
A forward-deployed engineer is that person for software. Palantir institutionalized it — engineers embedded with customers, building against real messy data until the product fit — and the AI wave revived it at scale, because LLM products are powerful but shapeless: what an AI assistant should DO at an insurance firm versus a freight company only becomes clear inside their walls. The FDE goes in with three hats in the bag: consultant (diagnose the real problem), product manager (decide what to build first), engineer (build it, on production-quality instincts). The rarest skill is knowing which hat the current hour requires.
FDE roles at AI labs and AI-first startups are among the best-paid, fastest-growing engineering jobs of 2026 precisely because the skill mix is scarce: people who can both pass Day 160's design round AND sit with a claims manager for an hour without opening a laptop. Everything you have built for 161 days is the engineering half; Weeks 24–25 train the deployed half. Even if you never take the title, every senior AI engineer is part-FDE now — the ambiguous, customer-shaped problem is the job. Understanding the role also transforms your job search: you will read postings today the way employers write them.
One engagement, three hats — a day in the forward-deployed life
step 1 / 59:00 AM, on-site at a logistics customer. The stated request: "We want an AI chatbot for our ops team." An FDE's first move is NEVER to build it. Hat one goes on: the consultant.
Guided practice
Dissect two job postings like an examiner
20 minBelow are two condensed-but-realistic postings. For each: (1) underline every distinct skill claim; (2) tag it C/PM/E for the hat it belongs to; (3) write the interview question you would expect it to generate; (4) note the strongest evidence YOU currently have, naming a specific artifact from your 161 days.
Posting A — "Forward Deployed Engineer, AI Platform (Series C, fintech vertical)": "You will embed with 2–3 enterprise customers at a time, owning engagements from technical discovery through production. You'll scope and build LLM-powered workflows (document processing, agent-assist) on our platform, integrating with customer systems (core banking APIs, SharePoint, Snowflake). You'll define success metrics with customer stakeholders and instrument evaluations to prove them. Expect 25–50% travel. Requirements: strong Python + production API experience; hands-on LLM app experience (RAG, tool use, evals); ability to run a room of mixed technical/executive stakeholders; security-review fluency (SOC 2 environments)."
Posting B — "Forward Deployed Software Engineer (AI lab, applied team)": "Work with strategic customers to turn frontier-model capability into deployed products. Prototype rapidly (days, not months), then harden what works. Translate ambiguous business problems into technical plans; write proposals and architecture docs executives approve and engineers can build. Debug production issues in customer environments. Requirements: full-stack shipping ability; excellent written communication; comfort with ambiguity; experience making latency/cost/quality trade-offs in LLM systems."
- Finish with a gap list: the two claims across both postings where your evidence is thinnest. (Common honest answers at this point: "run a room" and "customer-environment debugging" — Days 167 and 172 exist for exactly this reason.)
Map the lifecycle onto your capstone — as if you had been the customer
15 min- Draw the six lifecycle stages (discovery → scoping → pilot → evaluation → hardening → handoff) as a table.
- For each stage, fill two columns: "deliverable an FDE would produce" and "the closest artifact I already have," citing real files from your capstone repo (requirements came from the Day 119 brief; eval report from Day 140; cutover evidence from Day 161…).
- Mark the honest holes — you never DID discovery (the Day 119 brief was handed to you) and you have no proposal. Those two holes are precisely Days 163–165's work.
- Write one paragraph: "If the capstone had been a real engagement, the moment it would have failed is…" — arguing from a specific stage. (Strong candidates usually pick discovery: building the right thing was assumed, not established.)
On your own
The three-hats reflex drill
15 minFor each situation, name the hat that should be on, the FIRST move it dictates, and the classic mistake of wearing the wrong hat. Answer in three lines each, then compare with a peer or the AI tutor.
- Kickoff week. The VP who bought the pilot says "we need an AI chatbot for procurement." Nobody can say who will use it.
- Mid-pilot, the customer's engineers ask you to also ingest a legacy Oracle system "while you're here" — two weeks of work, not in scope.
- The demo is Thursday; extraction accuracy on their scanned invoices is 70% and the fix is genuinely hard.
- Post-pilot review. Usage data shows only 3 of 40 intended users touch the tool weekly.
Hints: 1 is consultant (discovery before design — "chatbot" is a solution claim, not a problem); 2 is PM (scope guard: log it, price it, trade it); 3 is a judgment call — engineer hat says fix, PM hat says re-scope the demo honestly around what works (the honest path wins, Day 167 explains why); 4 is consultant again — usage failure is a discovery failure until proven otherwise.
Your FDE positioning memo
Write docs/fde_positioning.md (one page, three sections). Evidence map: the ten most FDE-relevant artifacts from your 161 days, each with one sentence of "so what" written for a hiring manager (not "built a RAG app" but "shipped a monitored, fallback-protected doc-QA service with a measured 30% cost reduction and an eval-gated CI"). Gap plan: your three thinnest claims, each tied to the coming day that trains it (163–174). Positioning paragraph: 120 words, first person, the kind you would paste into an application — what problem you deploy against and what proof you carry. This memo becomes your Day 180 job-search launch material.
Common mistakes & misconceptions
- Treating FDE as "sales with extra steps." FDEs own outcomes and code after signature; the center of gravity is deployed working software, not the deal.
- Treating FDE as "normal engineering, remote from HQ." The consultant and PM hats are half the job; engineers who skip discovery build beautiful wrong things.
- Wearing the engineer hat during discovery — proposing architectures in the first meeting. The customer's stated solution ("we need a chatbot") is data about their problem, not a spec.
- Reading job postings as checklists to feel behind on. Postings are unions of wishes; map evidence to the core claims and let strong artifacts argue for you.
- Underestimating the writing load. Proposals, requirement docs, status updates — FDEs are judged on documents executives forward; Day 164–165 treat writing as an engineering discipline.
- Assuming the product does not matter because you can custom-build anything. The FDE's economic job is harvesting patterns back into product; pure bespoke work is consulting in disguise.
Q1. A customer's VP opens the engagement with "we need an AI chatbot for procurement." The FDE's correct first move is…
Q2. The cleanest single axis separating an FDE from a sales engineer is…
Q3. Mid-engagement, usage data shows almost nobody uses the delivered tool. Which hat diagnoses this, and what is the leading hypothesis?
Go deeper — curated resources
- Read one real posting tonight — Find a live FDE posting from an AI lab or applied-AI startup and run today's dissection protocol on it. Postings drift fast; the protocol is the durable skill.
- Both postings dissected with hat-tags, expected questions, and evidence
- Lifecycle table filled with real artifact citations and honest holes
- fde_positioning.md committed with evidence map, gap plan, and paragraph
- Quiz ≥ 2/3
← Back: Day 105 (the stakeholder explainer) and Day 146 (communicating quality) were early reps of the consultant hat; Day 160's design skill is the engineer hat's crown; Week 23's production evidence is what makes your positioning memo credible.
Forward →: The next six days run the engagement lifecycle in order: discovery (163), requirements (164), proposal (165), prototype (166), demo (167), full simulation (168). Day 174 runs it again under pressure with objections and scope changes.
Unlocks: D163 Customer Discovery & the Mom Test · D169 Enterprise Integration · D171 Stakeholders & Trade-off Navigation