The Forward Deployed Engineer Playbook: A Practitioner’s Field Manual (Early Draft)

This is a living document. I’m writing it before I fully live it — because I’m about to put on the FDE hat myself. This playbook will evolve as I document what actually works and what doesn’t. If you’re an FDE, a founder about to become one, or an enterprise leader trying to figure out how to deploy these people — I want your edits. Seriously. This isn’t meant to be a finished product. It’s meant to be right. Comments Open

This Is Not a Deloitte [or] a Sales Engineer Playbook

Let me be clear about what this document is not.

It is not a 200-slide deck with a “transformation maturity model” and a “digital readiness assessment framework.” It is not a playbook that bills $450/hr for discovery, produces a 60-page PDF of recommendations, and then leaves. It is not something you hand to a junior consultant who learned about your industry last Tuesday.

The Big Four model — PwC, Deloitte, Accenture, McKinsey — was designed for a world where the deliverable was the document. Where “strategy” lived in a PowerPoint and “implementation” was somebody else’s problem. That world is dying.

The FDE model exists because AI doesn’t work like ERP. You can’t spec it in a boardroom, hand it to an integrator, and come back in 18 months. The failure rates prove it: 70-85% of enterprise AI projects never make it to production. MIT’s NANDA research found that only 5% of integrated AI pilots extract measurable P&L impact. And 42% of companies abandoned most of their AI initiatives in 2025 — up from 17% in 2024.

The gap isn’t technology. It’s the space between the technology and the actual work. FDEs exist in that space.

Phase 1: Insertion

The first 72 hours inside an enterprise tell you almost everything. Not from meetings — from the gaps between meetings.

An FDE doesn’t arrive with a plan. They arrive with a question: Where does work actually happen here, and where does it break?

This means you’re not starting in the CTO’s office. You’re starting in the places where people are frustrated. The ops team that manually reconciles data between two systems every morning. The compliance analyst who copy-pastes from a PDF into a spreadsheet 400 times a month. The support engineer who spends 70-80% of their time debugging the same class of failure (this was the exact finding when OpenAI’s FDE team embedded at a European semiconductor company).

What insertion actually looks like:

You show up. You ask to sit with the people who do the work. Not the people who manage the people who do the work. You watch. You ask dumb questions. You take notes on everything — the tools they use, the workarounds they’ve invented, the tribal knowledge that lives in someone’s head and nowhere else.

The enterprise will try to route you through the standard vendor onboarding process. Resist this. You’re not a vendor. You’re a temporary member of their team. The faster you establish that distinction, the faster you get to the real problems.

The first deliverable is not code. It’s a map.

A situational awareness document that captures:

• The actual workflow (not the documented one — those diverged years ago)
• The systems involved and how data moves between them (or doesn’t)
• The manual steps that people have stopped questioning
• The 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

This map is what separates an FDE from a consultant. A consultant would spend 4-6 weeks producing this as a deliverable (slide deck). An FDE produces it as scaffolding for the work they’re about to do.

Phase 2: Discovery and Extraction

Once you have situational awareness, the real work begins: finding the highest-leverage point of intervention.

Not the most interesting problem. Not the most technically challenging one. The one that, if solved, would make the most visible difference to the most people in the shortest time.

Colin Jarvis at OpenAI calls this the “validation phase” — you land on site, and the first question is: “Is what we scoped out actually the most valuable thing we can do?” Often, it isn’t. The problem the enterprise described in the sales cycle is rarely the problem that matters most once you’re inside.

The tools of extraction:

This is where the FDE pulls out their actual toolkit. Not a methodology. Tools.

• Eval frameworks — before you build anything, you need to define what “working” means in measurable terms. OpenAI’s FDE team builds evals with user input and labeling before writing a single line of production code.
• Data pipeline scaffolding — you need to connect to the customer’s actual data, not a sanitized sample. This usually means wrangling APIs, legacy databases, flat files, and things that should embarrass the enterprise but don’t because they stopped noticing.
• Rapid prototyping environments — you need to show, not tell. A working demo built on real data in 2 weeks beats a proposal deck reviewed in 6.

What’s emerging:

There’s a new class of tooling being built specifically for this workflow. Tools that capture agent exploration patterns and crystallize them into reusable workflows — so the next FDE walking into a similar enterprise doesn’t spend three weeks rediscovering what the last one already learned. Think of it as institutional memory for the deployment process itself. There will be others. The point is that the FDE role has been tooling-starved, and that’s about to change.

The Big Four have their methodologies. FDEs will have their toolchains. The difference is that toolchains compound — each engagement makes the next one faster. Methodologies just get longer.

Phase 3: Relationship Formation

Here’s where most technical people fail. And here’s where the FDE role diverges most sharply from “really good engineer who sits with customers.”

An FDE works with a specific cast of characters inside every enterprise. Understanding who they are and what they need is not optional — it’s the job.

The ICP map inside the org:

The relationship dynamic that matters most: the line-of-business owner. This person is your buyer’s buyer. The executive sponsor signed the check, but the LoB owner decides whether your work actually gets adopted. If they feel threatened, they’ll kill your project with passive resistance and you’ll never even see it happen.

How trust actually forms:

It doesn’t come from presentations. It comes from fixing something small in the first week. A script that eliminates a 20-minute daily task. A dashboard that surfaces information someone’s been asking for. Something tangible that demonstrates you understand their world.

OpenAI’s FDE team spent 6-8 weeks on the technical scaffolding at Morgan Stanley. But then they spent another four months running pilots, collecting feedback, and iterating with wealth advisors. Because technical integration is necessary but not sufficient. You need the humans to trust the system, which means you need the humans to trust you first. The result: 98% adoption.

Phase 4: Unit Economics — The Part Nobody Wants to Talk About

Here’s where it gets interesting. The traditional enterprise AI implementation timeline looks like this:

That compression is where the economics work. If you can 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.

The leverage ratio that matters:

The best FDE teams target a ratio of 1 FDE : $2M-$5M in ARR influenced. Palantir’s FDE-heavy model is part of how they went from $0 to $2.8B+ in revenue. The FDE doesn’t carry a quota — only 8% of FDE roles mention OTE and exactly 0% are quota-carrying. But the FDE’s success directly enables the account team’s expansion.

When the economics don’t work:

• Customers with ACVs below $200K — the FDE cost exceeds the account value
• Engagements where the real blocker is political, not technical
• Organizations with no internal champion who will own the system after you leave
• “Prove AI works” engagements with no committed use case

Phase 5: What You Leave Behind

This is the part that separates an FDE engagement from consulting. A consultant leaves behind a document. An FDE leaves behind a running system and the organizational muscle memory to operate it.

The handoff package:

• Production system — not a prototype, not a POC. A system that runs on the customer’s infrastructure, processes their data, and delivers measurable results.
• Evaluation framework — the customer needs to know if the system is working, degrading, or failing. This means automated evals, monitoring dashboards, and escalation criteria. Without this, the system rots within 90 days of your departure.
• Runbook — every operational procedure documented. Not in a wiki that nobody reads. In the system itself, as automated workflows wherever possible.
• Internal champion enablement — the person or team who will own this after you leave needs to be identified in week 1, embedded in the work from week 2, and capable of operating independently by the end.
• AI substrate — and this is the important one. What you’re really leaving behind isn’t a single system. It’s a layer of automation that the organization can build on. A substrate — connectors, data pipelines, eval frameworks, workflow patterns — that makes the next AI initiative faster and cheaper.

Reducing the variance between expert and explorer:

This is the endgame. Every enterprise has two kinds of people: experts who know how things work, and explorers who are trying to figure it out. The gap between them — in time, in quality, in confidence — is where most enterprise inefficiency lives.

What AI substrates do, when deployed well by FDEs, is compress that gap. The explorer gets access to the expert’s patterns. The expert gets freed from answering the same questions. The institutional knowledge that used to live in one person’s head now lives in a system that scales.

This is what durable value looks like. Not a chatbot. Not a copilot. A layer of encoded institutional intelligence that makes the whole organization faster.

What Comes Next

I’m writing this in February 2026. In six months, I’ll have done this work myself with another companion member — walked into enterprises with my product, built the situational awareness map, found the leverage points, shipped production systems, and handed them off.

Some of what I’ve written here will be wrong. Some will be incomplete. Some will be right but for reasons I don’t yet understand.

I’ll update this playbook as I go. With specifics — what the first week actually looked like, which tools worked and which didn’t, what the customers said vs. what they meant, where the unit economics held and where they broke.

What I believe will change about this role in the next 24 months:

• New toolchains will emerge — purpose-built for the FDE workflow. Tools that capture deployment patterns across engagements and make them reusable. Tools that automate the discovery phase. Tools that generate eval frameworks from observed workflows. We’re building one. Others will build more.
• The role will bifurcate — into “deployment FDEs” who execute known playbooks at scale and “pathfinder FDEs” who work on novel, zero-to-one problems. The former will be partially automated. The latter will become more valuable.
• Enterprises will hire their own — the smartest companies won’t wait for vendors to send FDEs. They’ll build internal FDE teams that work across their own AI initiatives. The FDE playbook becomes an internal competency, not just a vendor service.
• The consulting firms will try to rebrand — Deloitte will call their consultants “Forward Deployed Advisors” or something equally hollow. It won’t work, because the difference isn’t the title. It’s whether you ship code or ship slides.

An Invitation

This document is deliberately unfinished. If you’re an FDE — at Palantir, OpenAI, Ramp, Scale, Databricks, or anywhere else — I want to know what I’m getting wrong. If you’re a founder who’s done this work, tell me what I’m missing. If you’re an enterprise leader who’s worked with FDEs, tell me what mattered and what didn’t.

The best playbooks are written by the people who run the plays.

Reach me at chetan@modiqo.ai