Forward Deployed Engineering needs a Forward Deployed Executive

Two structural moves change that. A Forward Deployed Executive who shares Business Unit KPIs. An engineer who takes the operator’s job and rebuilds the function from first principles. This piece argues both, and names two settings where the model belongs and rarely lives.

01 What the industry built

The Forward Deployed Engineer (FDE) role started at Palantir in the early 2010s under the internal name Delta. The pattern was simple. One software engineer embedded with one customer. Production code on the vendor’s platform inside the customer’s environment. Outcomes measured in working software, not delivered hours.

The model is back, at scale. OpenAI started its Applied AI team in 2024. Anthropic announced a 5x expansion of its Applied AI function in 2025. Job postings for FDEs rose more than 800% between January and September 2025.

Across Palantir, OpenAI, Anthropic, PostHog, and SaaStr commentary, the industry agrees on three things. The FDE writes production code in the customer’s environment. The work begins after the contract is signed. The point is a feedback loop from the field into the product roadmap.

Where the industry disagrees is whether the FDE model is engineering, consulting, or a services line in disguise. Critics call it sparkling sales engineering or a margin-eroding services shop. a16z calls it the moat. Both readings are partially right. They describe the same role at different operating altitudes.

02 What gets misread

Five distinctions hold against the most common misreads. None of them is decorative. Each maps to a procurement decision an enterprise leader makes in week one.

• Misread 01 — The consultant. The FDE is not a consultant. The consultant ships advice. The FDE ships a running system inside the customer’s infrastructure.
• Misread 02 — The sales engineer. The FDE is not a sales engineer. The sales engineer closes the deal. The FDE makes the deal real in production.
• Misread 03 — The CSM with code. The FDE is not a customer success manager with code. The customer success manager owns retention. The FDE owns delivery and the product feedback loop.
• Misread 04 — The downgrade. The FDE is not a downgrade from product engineering. Palantir alumni circa 2016 moved from FDE rotations into core product engineering. Field experience produced stronger product engineers, not weaker ones.
• Misread 05 — The services shop. The FDE is not a services-shop disguise on its own. The framing applies only when no platform absorbs the field work and no feedback loop reaches the roadmap. Without those two pieces, any model degrades into expensive implementation.

03 Four altitudes of customer engagement

Most conversations about the FDE collapse very different operating models into one label. We separate them into four altitudes. Each carries a different cost, a different risk, and a different return.

• Altitude 01 — Low touch. Pre-sales SA or consultant. The work is a recommendation. The artifact is a deck or a PoC. The engagement ends at handoff. Customer outcome is unverified.
• Altitude 02 — Medium touch. Hourly professional services. The work is billable hours against a scope. The artifact is a delivered project. Customer outcome is delivery against scope, not against a business KPI.
• Altitude 03 — High touch. Production build. The canonical FDE. The work is production code on the customer’s infrastructure. The artifact is a running system. Customer outcome is software in production. This is the Palantir, OpenAI, and Anthropic definition.
• Altitude 04 — Ultra-high touch. Outcome-bound build. The work is a business KPI inside the customer’s P&L. The artifact is a redesigned operating function. Margin is variable, tied to outcome. Customer outcome is measurable in CFO reporting.

The industry conversation stops at altitude 3. The argument that compounds starts at altitude 4.

Altitude 4 prices the outcome, not the engineering. For a mid-to-large enterprise, this is the register that aligns vendor incentives with operating change. Altitudes 1 through 3 deliver software. Altitude 4 delivers a different P&L line.

04 Two moves that lift altitude three to altitude four

Move 01 — Introduce the Forward Deployed Executive

A technical executive who also builds. Embedded with the target Business Unit. Learns the BU operating model. Carries the same KPIs as the BU Head. Hands on the keys. Building alongside the BU lead on north-star prototypes the BU lead would be proud to ship.

The lever. Outcomes at the Business Unit level need a counterpart at the Business Unit level. An FDE without an executive counterpart can ship features that change a workflow. They cannot ship features that change the P&L. The two are different goods.

For a Chief Information Officer or Chief Technology Officer, the question is not whether the FDE can code. It is whether anyone above the FDE shares the operating outcome the BU is being measured on. If the only person carrying the BU KPI is the BU Head, the engagement returns features. If there is a technical peer at the same KPI level, the engagement returns operating change.

Move 02 — The FDE takes the operator’s job

The FDE takes the operator’s seat. Analyst, underwriter, RCM specialist, claims clinician, or asset-flow operator. The seat they are building for. They do the work for two to four weeks. They learn the constraints from inside. They rebuild the function from first principles, with the operator and the executive both at the table.

The lever. This collapses the SDLC. Requirements gathering, user interviews, product discovery, and design fold into one team that re-imagines its own job. Three roles, one head. The role demands deep domain fluency and the ability to learn a domain in weeks. Pricing is bound to the outcome.

For a Chief Executive Officer, the move sounds expensive until the alternative is priced. Building the wrong workflow with a clear PRD costs more than building the right workflow with no PRD. The first ships and is unused. The second changes the operating model.

05 Beyond Platform Vendor and Enterprise

The FDE conversation has been framed almost entirely around platform vendors deploying their engineers to enterprise customers. Palantir → Hertz. OpenAI → Klarna. Anthropic → Lyft. Two other settings deserve the same model and rarely get it.

Setting 01 — Internal FDEs inside an enterprise platform team

Large enterprises are now building internal platforms for data, agents, and governance. The pattern is hub and spokes. A central platform team builds. The Business Units adopt. Adoption fails when the platform team ships capability and the Business Units ship workflows that ignore it.

Internal FDEs sit in the spoke. They report to BU outcomes and to platform standards. They are funded by the BU during the engagement. The role exists for this two-master problem. Adoption and change management is the job, and there is no other role designed for it.

For the CIO. Most platform-team budgets fund hub builders. Few fund spoke embedment. Without internal FDEs, the platform ships and the BUs route around it.

Setting 02 — AI Systems Integrator with an industry blueprint

A second setting is the AI Systems Integrator working with the enterprise. Provectus is one. Provectus does not own or sell products or platforms. The work for one customer accumulates into industry blueprints. Revenue Flow for Healthcare Providers. Asset Flow for Asset Management. Underwriting Flow for Specialty Insurance.

The blueprint is the platform substitute. FDE work for the next customer starts at altitude 3 with a working baseline. The FDE pair then moves to altitude 4 from week one. Without a blueprint, every engagement is a fresh start. With one, the engagement begins from a working system that has shipped before.

For the CIO selecting an SI. The diligence question is concrete. What does your blueprint look like for this industry? What has it shipped before? What does it pull forward into our engagement on day one? An SI without an industry blueprint is selling hours, not outcomes.

06 Bottom line for enterprise leaders

The FDE conversation has been framed as a hiring trend at frontier AI labs. That framing under-sells what the model is for. FDEs are the right unit of work for changing how a Business Unit operates. Shipping features is the floor, not the ceiling. To get the operating change, the FDE alone is not enough.

• For the CIO. Ask whether the platform team funds internal FDEs in the spokes. If the answer is no, adoption is a gamble.
• For the CEO. Ask whether the AI engagement has a Forward Deployed Executive at the Business Unit’s KPI level. If not, the engagement returns features.
• For the CTO. Ask the Systems Integrator partner what their industry blueprint pulls forward on day one. If they cannot show one, they are starting from zero.