Working Like a Forward Deployed Engineer

14.1 The Rise of the Forward Deployed Engineer

The role was invented at Palantir in the early 2010s. Palantir's customers, intelligence agencies and later large enterprises, worked on problems so closed and so specific that ordinary product development could not reach them. So Palantir sent engineers to sit inside the customer's operation for months at a time, building working software on the customer's real data and feeding what they learned back to the product teams. Internally, the company drew a memorable distinction between its two kinds of engineers: a product developer serves one capability for many customers; a forward deployed engineer serves one customer with many capabilities. The role, Palantir liked to say, looks a lot like being a startup CTO, embedded in someone else's company.

For a decade this stayed a Palantir curiosity. Then enterprise GenAI arrived and rediscovered Palantir's problem at scale: the technology works in demos and stalls in deployment, because the hard part is not the model but the encounter between the model and a specific organization's workflows, data, politics, and risk tolerances. Chapter 2 called this the adoption paradox: adoption is nearly universal while transformative results remain rare. The FDE is the industry's answer to that paradox. OpenAI created its FDE team in 2025 and grew it across eight cities within a year. Anthropic built an enterprise deployment arm with major financial-services partners, embedding engineers directly at client sites. Google Cloud posted dozens of FDE openings. Job postings for the title grew roughly eightfold in a single year, and one venture firm dubbed it the hottest job in tech, with compensation to match, commonly in the $300,000 to $600,000 range. Deployment, not model capability, is now the bottleneck of the industry, and companies pay accordingly for people who can clear it.

Why should an EMBA student care about a job description? Because the FDE role is simply the personification of the skill this book has been building chapter by chapter: the ability to stand between a frontier technology and a real business, and make the two meet. Executives who can work this way, or at minimum recognize, hire, and manage people who can, are the ones whose AI initiatives will escape the pilot graveyard described in Chapter 10.

14.2 The FDE Method: Embed, Scope, Build, Prove

Strip away the title and the FDE way of working is a repeatable method. It has four movements, and none of them is exotic; what is distinctive is the sequence, the speed, and the insistence on real workflows over slideware.

Embed. FDEs spend a quarter to half of their time physically or virtually inside the customer's operation, watching how work actually happens rather than how the org chart says it happens. The discovery questions are managerial, not technical: Where does expensive human judgment get spent on routine cases? Where does work queue up? What does a mistake cost, and who notices it? The output of embedding is a shortlist of candidate workflows, each with a named owner, a measurable baseline, and a definition of "better."

Scope. From the shortlist, the FDE picks the first target using a filter you now have the vocabulary for: a workflow that is frequent enough to matter, checkable enough to verify (recall the loop-engineering rule from Chapter 3: autonomy requires verifiability), and forgiving enough that early errors are survivable. Scoping ends with success criteria written down before any building starts, typically an evaluation set: twenty to a hundred real examples of the task, with what a good output looks like for each. If the client cannot produce examples of the task, that is a red flag worth surfacing in week one, not month six.

Build. Then the FDE ships a working prototype in days, not quarters, using exactly the stack from Part II: a frontier model over an API, retrieval over the customer's documents, tools connected through the Model Context Protocol, and a thin harness with the permission lines drawn deliberately. The prototype is deliberately narrow and deliberately real: it runs on the customer's actual data, in front of the people who do the job today. Nothing surfaces hidden requirements faster than a domain expert watching an AI attempt their work.

Prove. Finally, the FDE turns the demo into evidence: running the eval set, measuring against the baseline agreed at scoping, instrumenting the system so quality is observable in production, and iterating until the numbers clear the bar. This is the phase most internal AI projects skip, and skipping it is why they die. A demo creates enthusiasm; an eval creates a deployment decision. When the workflow proves out, the FDE hardens it, hands it over, and feeds what was learned back into the platform and the next engagement. When it does not prove out, the FDE says so early and moves to the next candidate on the shortlist, which is a cheap failure instead of an expensive one.

14.3 The FDE Skill Stack

What makes the role rare, and expensive, is that it sits on two skill stacks at once, and this book has deliberately walked you up both.

The technical stack is the material of Part I and Part II: how the models work and where they fail (Chapter 1); the five engineering disciplines, prompt, context, harness, loop, and graph (Chapter 3); calling models over APIs, structured output, tool use, and cost engineering (Chapter 5); the tool landscape (Chapters 4 and 6); and the autonomy ladder from assistants to agents (Chapter 7). An FDE does not need to be a research scientist. They need to be a fluent builder: able to stand up a retrieval pipeline, define tools for an agent, write an eval, and read a trace to find out why the system did the wrong thing.

The consulting stack is the material of Part III, and it is the half that engineering hires most often lack: discovery and workflow analysis (Chapter 8), value framing and prioritization (Chapters 9 and 11), phased implementation and governance (Chapter 10), and the ethical and regulatory boundaries that decide what may be deployed at all (Chapter 13). FDE job descriptions at the major labs read like an EMBA syllabus wearing an engineering badge: stakeholder management, comfort with ambiguity, the ability to learn a domain in weeks, and the judgment to tell a customer that the impressive thing they asked for is not the valuable thing they need.

Notice the asymmetry, because it is encouraging for readers of this book. Teaching a strong engineer to do discovery interviews and manage a steering committee takes years; those are careers, not modules. Teaching a strong operator to build with GenAI has, by 2026, become a matter of weeks, because the tools themselves now do most of the engineering. Agentic coding tools like Claude Code and Codex will write the pipeline; the scarce input is knowing what to build, what "good" means for the business, and whether the result should be trusted. That judgment is your competitive advantage. The engineering half of the FDE stack has never been more learnable, and the managerial half has never been more valuable.

14.4 A Field Playbook: Your First Engagement

Here is the method compressed into a playbook you can run inside your own organization, this quarter, as a working template. Treat your own department as the customer.

Weeks 1–2, discovery. Shadow the work. Inventory five candidate workflows and score each on frequency, verifiability, error tolerance, and data availability. Interview the people who do the work, and ask for their last twenty examples of the task, inputs and finished outputs. Pick one workflow. Write a one-page scoping memo: baseline cost and cycle time, success metric, eval set, kill criteria, and the permission line, meaning which actions the system may take alone and which require a human (Chapter 3's harness principles, applied as management policy).

Weeks 3–4, prototype. Build the thinnest system that could work: a well-engineered prompt over a frontier model, retrieval over the relevant documents, connected to real data through approved connectors. Use an agentic coding tool as your build partner and expect to be surprised by how far you get. Put the prototype in front of the domain experts by the end of week 3 and revise from what they catch, their corrections are your next eval cases.

Weeks 5–6, prove and decide. Run the eval set. Compare against baseline. Instrument everything: every input, output, correction, and escalation logged. Then make the decision the numbers support: harden and hand over, iterate once more with a specific hypothesis, or kill it and write up why, which is itself valuable intelligence for the next attempt. Whatever the outcome, present it with the discipline of Chapter 9: which EDGE lever it pulled, what it cost, what it returned, and what the organization learned.

Run that playbook twice and you will have something rarer than a certificate: a portfolio of deployed (or honestly killed) GenAI systems, an eval discipline, and the beginnings of the judgment that the market is currently pricing at half a million dollars a year.

14.5 The Forward Deployed Organization

The final step is to scale the method from a person to an operating model. The organizations that escape the adoption paradox increasingly run internal FDE pods: small teams, typically a builder, a domain expert, and a sponsor with budget authority, that move from function to function running exactly the embed-scope-build-prove cycle, leaving behind deployed systems, eval suites, and trained local owners. This is the 10-20-70 rule of Chapter 2 made structural: the pod exists precisely because 70 percent of the work is organizational, and organizational work cannot be shipped from a vendor's office.

If you retain one idea from this book, let it be this one. GenAI value is not found in the model, the vendor deck, or the strategy document; it is found at the point of deployment, workflow by workflow, eval by eval. Someone has to go forward and get it. You now know how the models work, how to communicate with them, how to build with them, where the value hides, and how to govern the result. Go be that someone.