💻 The Forward-Deployed Engineer 🤖 Playbook 📖

⚡ 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:

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.)

flowchart TD
    Start([Engagement starts]) --> P1
    P1["Phase 1 - INSERTION first 72h<br/>Sit with people who do the work<br/>Deliverable: Situational Awareness Map"]
    P2["Phase 2 - DISCOVERY and EXTRACTION<br/>Find highest-leverage point<br/>Define working with evals first<br/>Ship working demo in ~2 weeks"]
    P3["Phase 3 - RELATIONSHIP FORMATION<br/>Fix something small in week 1<br/>Win over the Line-of-Business owner<br/>Run pilots and earn adoption"]
    P4["Phase 4 - UNIT ECONOMICS<br/>Compress time-to-value 15mo to 5mo<br/>Target 1 FDE per 2M-5M USD ARR"]
    P5["Phase 5 - LEAVE-BEHIND<br/>Production system plus evals<br/>Runbook plus enabled champion<br/>Reusable AI substrate"]
    P1 --> G1{Most valuable thing?}
    G1 -- no, re-scope --> P1
    G1 -- yes --> P2
    P2 --> G2{Economics viable?}
    G2 -- no --> Walk([Walk away])
    G2 -- yes --> P3
    P3 --> P4 --> P5 --> Done([Durable value: system runs without you])
    P2 -. field intel .-> Product[Core Product and Research]
    P3 -. field intel .-> Product
    P5 -. reusable patterns .-> Product
    Product -. faster next deploy .-> Start

    classDef gate fill:#faae2b,stroke:#c98a00,color:#000;
    classDef terminal fill:#1b998b,stroke:#127068,color:#fff;
    classDef product fill:#6a4c93,stroke:#4d3370,color:#fff;
    class G1,G2 gate;
    class Start,Done,Walk terminal;
    class Product product;

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):

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