A practical, straight-to-the-point field manual for the role The New Stack calls "AI's hottest job" and a16z calls "the hottest job in tech."
#
📑 Table of Contents
- ⚡ TL;DR
- 🧭 Part 1 — What an FDE Actually Is
- 📈 Part 2 — Why the Role Exploded (2025–2026)
- 🛠️ Part 3 — The 5-Phase Deployment Method
- ⏱️ Part 4 — How FDEs Spend Their Time
- 🧰 Part 5 — The Skill Stack
- 🚪 Part 6 — How to Break In (30/60/90)
- 🎯 Part 7 — Interview Prep
- 🏗️ Part 8 — For Founders: Building an FDE Function
- ⚠️ Part 9 — The Honest Caveats
- ✅ The One-Page Checklist
- 📚 Companion Reads
- 🔗 Sources
#
⚡ TL;DR
A Forward-Deployed Engineer (FDE) is a software engineer who embeds inside a customer's environment, builds a working production system on top of your product, and then contributes what they learned back to the core product. Think "one customer, many capabilities" — the inverse of a normal dev's "one capability, many customers."
The role was invented at Palantir (internally called "Deltas") in the early 2010s. In 2025–2026 it exploded across the AI industry because models don't deploy themselves: MIT's State of AI in Business 2025 found that 95% of enterprise GenAI pilots show no measurable business impact — not because the models are bad, but because the gap between a capable model and a working production outcome is human engineering work. That gap is the FDE's job.
This playbook covers: what the role actually is, the 5-phase deployment method, the skill stack, a 30/60/90 plan, how to break in, compensation, and how to build an FDE team if you're a founder.
#
🧭 Part 1 — What an FDE Actually Is
The one-sentence definition
An FDE alternates between being embedded with customer teams (understanding the domain, shipping solutions on their infrastructure) and embedded with core product engineering (turning field lessons into product). — Pragmatic Engineer
Palantir's own framing is the clearest mental model:
| Traditional Dev | Forward-Deployed Engineer (Delta) | Focus | One capability, many customers | One customer, many capabilities | Measures success by | Feature shipped | Impact on the customer's goal/metric | Works on | The core product | The customer's outcome (+ the product) | Mindset | "How do I generalize this?" | "How do I get this to work?" |
The closest official job description, from Palantir: "FDE responsibilities look similar to those of a startup CTO: you'll work in small teams and own end-to-end execution of high-stakes projects."
What it is NOT
Not a consultant. Consultants make one-off recommendations and leave a slide deck. FDEs ship a running production system and stay long-term. The deliverable is working software, not a 60-page PDF. #
Not a pure Solutions Architect (SA). SAs advise, build MVPs/PoCs on anonymized/offline data, and rarely write code on customer infrastructure. FDEs write production code directly on customer infrastructure, in far more ambiguity. #
Not a Sales Engineer. Most FDE roles are not quota-carrying (only ~8% mention OTE, 0% carry a quota), even though FDEs are central to closing and expanding deals.
The three-part mental model
An FDE is a blend of:
Software engineer — writes production-grade code, debugs distributed systems, owns operational stability. #
Domain/customer partner — sits with users, scopes ambiguous problems, builds trust, navigates org politics. #
Platform engineer — feeds field lessons back into the core product (this part is de-emphasized where FDEs don't contribute to the product).
Every company has its own flavor. Some weight FDEs toward closing sales, some toward customer success, some toward core-product contribution. Read each job description carefully — the title is the same, the job varies.
#
📈 Part 2 — Why the Role Exploded (2025–2026)
The demand signal is not hype. A timeline of recent moves:
OpenAI stood up its FDE team in early 2025 (2 → 10+ engineers across 8 cities, 3 continents). In 2026 it launched the OpenAI Deployment Company — a $4B+ majority-controlled venture (TPG-led; Bain, Capgemini, McKinsey as founding partners) and acquired London applied-AI consultancy Tomoro (~150 engineers) on day one. #
Google Cloud — CEO Thomas Kurian: "The era of the pilot is over. The era of the agent is here." Google opened 59 FDE roles in week one across 8 countries with a ladder from FDE II → FDE IV, and plans to hire hundreds. Listed U.S. base bands: $127K–$183K (Applied FDE) up to $183K–$265K (FDE IV), before bonus/equity. #
Anthropic embedded FDEs inside FIS to co-build an agentic anti-money-laundering platform (Bank of Montreal, Amalgamated Bank as early adopters); the model is embed → build → transfer knowledge so the customer can scale independently. #
ServiceNow + Accenture launched a joint FDE program embedding engineers together inside customer environments. #
Ramp built a ~15-person FDE org organized into pods.
The root cause: the deployment gap
Multiple independent data points say the same thing:
95% of enterprise GenAI pilots show no measurable P&L impact (MIT NANDA, 2025). #
70–85% of enterprise AI projects never reach production. #
42% of companies abandoned most AI initiatives in 2025 (up from 17% in 2024).
- Only 32% of enterprise leaders report sustained, enterprise-wide AI impact (Accenture).
As Box CEO Aaron Levie put it: "Deploying agents is far more technical a task than most people realize — often far more involved than deploying software." With agents, you're not shipping software, you're shipping a work output inside the enterprise and the customer expects you to take them from current state to end state in one motion.
#
🛠️ Part 3 — The 5-Phase Deployment Method
This is the operational core of the playbook — a repeatable arc for any engagement. (Synthesized from OpenAI's FDE process and practitioner field manuals.)
How to read it: phases run top-to-bottom, but two gates can send you backward — if the scoped work isn't the most valuable thing (re-scope) or if the economics don't hold (walk away). The dotted lines are the strategic payoff: field intelligence flows back into the core product, making every next deployment faster.
Phase 1 — Insertion (First 72 hours) Goal: Build situational awareness. You arrive with a question, not a plan: "Where does work actually happen here, and where does it break?"
Do:
- Sit with the people who do the work, not the people who manage them.
- Watch. Ask "dumb" questions. Note the tools, the workarounds, the tribal knowledge that lives in one person's head.
Resist standard vendor onboarding. You're not a vendor; you're a temporary member of their team. Establish that distinction fast.
Deliverable — a Situational Awareness Map (not code, not a deck):
- The actual workflow (not the documented one — they diverged years ago).
- The systems involved and how data moves between them (or doesn't).
- The manual steps people have stopped questioning.
- Decision points where expertise matters vs. where it's just pattern-matching.
- The political landscape: who owns what, who's threatened by automation, who's championing it.
Phase 2 — Discovery & Extraction (Find the leverage point)
Goal: Find the highest-leverage intervention — not the most interesting or most technically challenging problem. The one that, if solved, makes the most visible difference to the most people in the shortest time.
OpenAI calls this the validation phase: "Is what we scoped out actually the most valuable thing we can do?" Often it isn't — the problem described during the sales cycle is rarely the one that matters most once you're inside.
The toolkit (tools, not methodology): #
Eval frameworks first. Define what "working" means in measurable terms before writing production code. Build evals with user input and labeling. #
Data pipeline scaffolding. Connect to the customer's real data — APIs, legacy DBs, flat files — not a sanitized sample. #
Rapid prototyping. A working demo on real data in 2 weeks beats a proposal deck in 6. Show, don't tell.
Phase 3 — Relationship Formation (Where technical people fail)
Goal: Earn adoption. The cast of characters inside the org matters as much as the code.
The line-of-business (LoB) owner is your buyer's buyer. The executive sponsor signs the check; the LoB owner decides whether your work actually gets used. If they feel threatened, they kill it with passive resistance you'll never see. #
Trust forms by fixing something small in week one — a script that kills a 20-minute daily task, a dashboard someone's been begging for. Tangible proof you understand their world.
- Technical integration is necessary but not sufficient. Example: OpenAI spent 6–8 weeks on technical scaffolding at Morgan Stanley, then 4 more months running pilots and iterating with advisors → 98% adoption. Humans must trust the system, which means they must trust you first.
Phase 4 — Unit Economics (The part nobody talks about)
Goal: Compress time-to-value. If you get a customer to production value in 5 months instead of 15, the delta in revenue recognition, expansion timing, and retention is worth multiples of the FDE's cost.
Rules of thumb:
- Target ratio: 1 FDE : $2M–$5M ARR influenced. (Palantir's FDE-heavy model helped take it from $0 → $2.8B+ revenue.)
- FDEs typically don't carry quota, but their success directly enables account expansion.
When the economics DON'T work — walk away if:
- ACV is below ~$200K (FDE cost exceeds account value).
- The real blocker is political, not technical.
- There's no internal champion to own the system after you leave.
- It's a vague "prove AI works" engagement with no committed use case.
Phase 5 — What You Leave Behind (Durable value)
A consultant leaves a document. An FDE leaves a running system + the organizational muscle to operate it.
The handoff package:
Production system — runs on the customer's infra, processes their data, delivers measurable results. Not a PoC. #
Evaluation framework — automated evals, monitoring dashboards, escalation criteria. Without this, the system rots within 90 days of your departure. #
Runbook — every operational procedure documented, ideally as automated workflows inside the system. #
Internal champion enablement — identify the owner in week 1, embed them from week 2, make them independent by the end. #
AI substrate — the real payload: connectors, pipelines, eval frameworks, and workflow patterns that make the next AI initiative faster and cheaper. You're leaving behind a layer of encoded institutional intelligence, not a chatbot.
#
⏱️ Part 4 — How FDEs Spend Their Time
A representative split (from analysis of 20+ job postings; varies by company): | Activity | % of time | What it looks like | Customer-embedded implementation | 40–50% | Sit with users, build custom solutions, integrate systems/data/APIs, deploy to prod, own stability | Technical consulting & strategy | 20–30% | Set AI strategy with leadership, scope ambiguous problems, architecture guidance, exec presentations | Platform contribution | 15–20% | Fixes/features to the core product, reusable components, influence roadmap with field intel | Evaluation & optimization | 10–15% | Build evals, optimize model performance, benchmark, monitor production | Knowledge sharing | 5–10% | Document playbooks, share field notes internally, train customer teams for handoff |
Travel: 25–50% on-site is standard. Palantir expects ~25%; healthcare AI firm Commure up to 50%. Environments can be unconventional — factory floors, air-gapped facilities, hospitals, farms (an OpenAI FDE literally worked with farmers in Iowa for the John Deere project).
How OpenAI structures the customer-facing arc
Phase 1 — Early scoping (a couple days on-site): map processes, find value areas, prototype with synthetic data, prioritize. #
Phase 2 — Validation: confirm the scoped thing is the most valuable thing; agree on validation criteria; build evals with user labeling; hill-climb on evals; present a final report vs. objectives. #
Phase 3 — Delivery (a few days/week on-site): get real data, build (often at your own offices), demo, ship the smallest unit that is a complete end-to-end solution.
Internal-facing rhythm (so field intel compounds)
- Bi-weekly knowledge-sharing with Research.
- Fortnightly readouts with Head of Product / PMs.
- A shared "FDE Field Notes" channel.
- Quarterly bootcamps to reunite a globally distributed team.
The feedback loop is the strategic payoff. At OpenAI, FDEs working a voice call-center deal built evals showing the model wasn't good enough, took that data back to Research, improved the model, made the customer the first to deploy the advanced solution — and the improvements shipped into the Realtime API for everyone. Win-win.
#
🧰 Part 5 — The Skill Stack
Aaron Levie's "syllabus" for the role, expanded:
Technical — foundations
CS fundamentals + real shipping experience (most roles want a solid SWE background; senior roles want 5+ years, though exceptional new grads get hired). #
Systems thinking — how the pieces fit, where data flows and breaks. #
Languages: Python (dominant), TypeScript/JavaScript, SQL, some Java/C++. #
Data engineering: ETL, pipelines (Spark, Airflow), wrangling legacy/messy data. #
Cloud & infra: AWS/Azure/GCP, containers, CI/CD, IaC. #
Frontend: React/Next.js, streaming UIs for LLM responses.
Technical — AI-specific (the differentiator vs. classic FDEs)
Foundation models & LLM integration — model selection trade-offs (proprietary vs. open weights, 7B on-prem vs. 1T in cloud), prompt engineering across model families, long-context management. #
RAG architecture — from simple vector search to hybrid search, query rewriting, reranking, self-corrective retrieval. #
Fine-tuning — when it beats RAG; LoRA/QLoRA/DoRA; hyperparameters, layer selection, memory. #
Agents — multi-agent orchestration, tool use, MCP, agentic CLIs, the "Skills" layer. #
LLMOps & deployment — serving (vLLM, TGI, TensorRT-LLM), cost optimization, observability. #
Evaluation — building evals, LLM-as-judge, hallucination detection, drift monitoring. Evals are the FDE's most important and most underrated skill. #
Agentic chaos management — the classic FDE handled deterministic pipelines; the AI FDE forces stochastic models to behave reliably via guardrails, retries, and evals.
Non-technical — the actual differentiator
Palantir's hiring bar: "Candidate has eloquence, clarity, and comfort in communication that would make me excited to have them leading a meeting with a customer."
Communication & writing — explain AI to non-technical execs; write clear proposals. (As one practitioner put it: AI is garbage-in/garbage-out, so writing is more important than ever.) #
Customer obsession — empathy for pain points, building cross-hierarchy trust, managing expectations. #
Problem decomposition — scope ambiguity, question every requirement, decide fast with incomplete info. #
Extreme ownership — "startup CTO" energy: PoC in days, production in weeks. #
Comfort with ambiguity — the FDE's default working condition. The model can do almost anything; the FDE figures out what it should do, for whom, on what timeline, at what cost. #
Adaptability & travel — unconventional environments, fast context-switching.
#
🚪 Part 6 — How to Break In (30/60/90) The path is additive: if you're already an engineer, you bolt the AI-agent and customer layers on top.
Self-study foundation
- Work an AI-engineering curriculum (LLM fundamentals → RAG → agents → MCP → evals → deployment patterns).
- Daily hands-on practice in coding agents: Claude Code, Cursor, Codex.
- The thing that separates an AI engineer from an FDE is customer context — and the only way to get it is to ship something to a real user (internal users count).
A concrete 90-day ramp
Days 0–30 — Build the stack. Ship 2–3 end-to-end projects: an enterprise document-Q&A RAG system, an eval framework, a customer-support automation agent. Make them run in production, not in a notebook. #
Days 31–60 — Add customer context. Find one real user (a coworker, a small business, an internal team). Do a mini-Phase-1: map their workflow, find a leverage point, ship a small win in week one, then deliver an end-to-end solution. Write up the case study. #
Days 61–90 — Package & interview. Build a portfolio that demonstrates production readiness (architecture diagrams, eval results, monitoring). Prepare STAR stories for each value. Practice customer-scenario and live-coding rounds.
Transition paths by background
SWE → Leverage production/reliability instincts; upskill on LLM tech + evals + customer comms. #
Data scientist/ML → Leverage eval rigor; add full-stack deployment + customer-facing practice. #
Consultant/SE → Leverage stakeholder management; add deep coding + production deployment.
#
🎯 Part 7 — Interview Prep
FDE interviews test a rare combination across five dimensions:
Technical conceptual — explain RAG, fine-tuning trade-offs, attention, hallucination detection, observability clearly. #
System design — design production AI systems under real constraints (support chatbot at scale, doc-Q&A over millions of pages, moderation pipelines). #
Customer scenarios — navigate ambiguity, compliance constraints, performance gaps, timeline pressure, and live-demo failures. Tests judgment and communication. #
Live coding — implement a RAG pipeline / eval framework / token optimization under time pressure while narrating your thinking. #
Behavioral — demonstrate extreme ownership, customer obsession, velocity, and comfort with ambiguity through specific stories.
Approximate evaluation weighting (from FDE-hiring coaches): Customer obsession stories — 30% Technical versatility — 25% Communication excellence — 25% Autonomy & judgment — 20%
Common rejection reasons: over-indexing on pure technical depth instead of breadth/adaptability; underestimating stakeholder management; no genuine enthusiasm for customer interaction; missing business context in technical decisions; weak prep for scenario questions.
The trap: most candidates use generic SWE prep and completely miss the customer-scenario, communication, and judgment dimensions.
#
🏗️ Part 8 — For Founders: Building an FDE Function
When FDEs make sense
- You sell to enterprises/traditional orgs where bureaucracy, not technology, is the real blocker.
- Your product needs deep integration with proprietary data and messy internal systems.
- Deals are large enough (ACV ≥ ~$200K, ideally with $2M–$5M ARR influence per FDE).
- You want a tight field-intel → product feedback loop.
Operating principles (from Ramp / OpenAI / Palantir)
Pods, not lone wolves. Ramp runs FDEs in pods that also embed in core product engineering teams. #
Bias to motion. Prove out brick walls fast, then re-scope to the most useful achievable thing. #
Make field intel flow back. Field-notes channels, regular research/product readouts, contribute to core SDKs/product (OpenAI's FDE team is a major contributor to the Agents SDK). #
Empower like CTOs. Give them end-to-end ownership and the authority to say "no" to low-value meetings and scope. #
Protect handoff. Bake the leave-behind (evals, runbooks, champion enablement) into the engagement definition, not as an afterthought.
Hiring
- Index on eloquence + ownership + range, not just LeetCode.
- Look for people who've shipped projects start-to-finish in the real world.
- Distinguish from SA/SE roles in your JD so candidates self-select correctly.
The career upside (your pitch to candidates)
FDE is a launchpad: the role builds the complete founder skill set — technical depth, customer understanding, rapid execution, business judgment. As SVPG notes, people who succeed in this model disproportionately go on to product leadership and founding startups. a16z frames the macro: "Software is no longer aiding the worker — software is the worker," and someone has to install it.
#
⚠️ Part 9 — The Honest Caveats
The role will bifurcate into deployment FDEs (execute known playbooks at scale — partially automatable) and pathfinder FDEs (zero-to-one novel problems — increasingly valuable). #
Enterprises will insource it. The smartest companies will build internal FDE teams rather than rely on vendors. Whether you're the embedded vendor or the internal counterpart, the skill stack is the same. #
Consulting firms will try to rebrand ("Forward Deployed Advisors"). It won't work if they still ship slides instead of code. The difference isn't the title — it's whether you ship a running system. #
Longevity is debated. As engineers, PMs, and leaders become AI-fluent, some of this work gets absorbed. Either way, the stack you build to do FDE work is the most durable, transferable AI-era skill set available right now.
#
✅ The One-Page Checklist
Before an engagement
- [ ] ACV and ARR-influence justify an FDE (≥ ~$200K ACV; aim $2M–$5M ARR/FDE).
- [ ] There is a committed use case and an internal champion who will own the result.
- [ ] The blocker is technical, not purely political.
**Phase 1 — Insertion (72h)**
- [ ] Sat with the people who do the work; produced a Situational Awareness Map.
- [ ] Identified workflow reality, data flows, manual steps, and the political landscape.
Phase 2 — Discovery
- [ ] Found the highest-leverage intervention (visible, fast, broad).
- [ ] Defined "working" with an eval framework
before building.
- [ ] Connected to real customer data; shipped a working demo in ~2 weeks. Phase 3 — Relationships
- [ ] Fixed something small in week 1.
- [ ] Identified and won over the line-of-business owner.
Phase 4 — Economics
-
[ ] Compressing time-to-value (target 5 months, not 15). Phase 5 — Leave-behind
-
[ ] Production system + evals + runbook + enabled champion + reusable AI substrate.
#
📚 Companion Reads
The FDE job sits at the intersection of building AI systems, engineering judgment, and customer/business outcomes — so these other playbooks in this collection go deeper on the individual muscles an FDE has to combine:
Build the AI system the FDE deploys
Sharpen the engineering & design judgment
Lead, sell, and build the business around it
Interview & skills
#
🔗 Sources
- Gergely Orosz, "What are Forward Deployed Engineers, and why are they so in demand?" — The Pragmatic Engineer (Aug 2025). https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- Matthew Burns, "Forward deployed engineer is AI's hottest job as OpenAI and Google race to hire," — The New Stack (May 2026). https://thenewstack.io/forward-deployed-engineer-fde-openai-google/
- Jennifer Riggins, "Why the forward deployed engineer is tech's hottest job," — The New Stack (Jan 2026). https://thenewstack.io/why-the-forward-deployed-engineer-is-techs-hottest-job/
- Chetan Conikee, "The Forward Deployed Engineer Playbook: A Practitioner's Field Manual," — Beyond Boundaries (Feb 2026). https://conikeec.substack.com/p/the-forward-deployed-engineer-playbook
- Sundeep Teki, "Forward Deployed AI Engineer: Career & Technical Guide," (2025–2026). https://www.sundeepteki.org/advice/forward-deployed-ai-engineer
- Palantir, "Dev versus Delta: Demystifying Engineering Roles at Palantir." https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87 · "A Day in the Life of a Palantir Forward Deployed Software Engineer." https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
- a16z, "Services-Led Growth: The hottest job in tech." https://a16z.com/services-led-growth/
- MIT NANDA, State of AI in Business 2025 (PDF). https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
- OpenAI,
*"The OpenAI Deployment Company."* [https://openai.com/business/the-openai-deployment-company/](https://openai.com/business/the-openai-deployment-company/)
- Public job postings:
OpenAI FDE · Google Cloud Applied FDE · Ramp · Salesforce · Commure · Gecko Robotics · Matta · Lindy.
Compiled June 2026. The FDE role is evolving fast — treat this as a living playbook.