Customer Success as an Outcome Strategy

A Forward Deployed Engineer is a software engineer who works directly with customers, deploying a technical product into the customer's environment. The role is expensive and specialized, so a company should not add FDEs by default. The practical question is when the role actually pays for itself. This article works through that question in a deliberate order: first the test that decides whether the role is needed, then the economics that make the role affordable, then the platform condition that keeps the model from failing, and finally the way the same function appears under many different titles.

Keep one idea in mind as you read. The need for an FDE is not decided by how sophisticated a company's engineering is, and it is not decided by how large the company is. It is decided by the combination of two facts about the sale: what is being sold, and who is buying it. Hold that thought, because the screening test in the next sections is built entirely on those two facts.

The word deployed matters. An FDE does not stay inside the vendor's office writing features for a generic audience. The FDE goes into the customer's environment and puts the product to work there. The work is engineering work, which is why the source describes these people as software engineers rather than trainers or account managers.

Read the diagram from top to bottom. The vendor maintains a shared platform of reusable building blocks. The FDE draws on those building blocks to build a solution for one customer. The solution is deployed into the customer's environment, and it is that deployed work that delivers the outcome the customer paid for. The diagram shows the deployment path only. It does not claim that every deployment looks identical, and the source does not describe the internals of any particular customer environment.

The test starts with two questions. The first asks what you are selling: a technical product, or a configurable one. The second asks who is buying it: a technical buyer, or a non-technical buyer. Two answers on two axes give four combinations, and only one of them makes the FDE role worth its cost. The flowchart below traces a product and a buyer through the screen, one question at a time.

Trace a path through the flowchart. A technical product is the first answer. The screen then moves to the second question. If the buyer is technical, the path ends at a standard path, because the buyer has the skill to integrate the product alone. If the buyer is non-technical, the path ends at the FDE role, because the product is complex enough that someone with engineering skill must put it into the customer's environment, and the buyer lacks that skill. A configurable product ends the screen immediately on the standard path, whoever the buyer is.

The source names real products to illustrate the quadrants. Developer platforms such as GitHub and Datadog fit the pattern of a technical product sold to a technical buyer, so they do not need FDEs. Business software such as Rippling, Jira, and Slack falls in the configurable-product case. Configuring these products does not require engineering, because setting up options and settings is work the buyer can do.

FDE salaries are high, so the model only works when the revenue per customer is high enough to cover them. The economics of the deeply technical quadrant show why. Public software companies differ sharply in average contract value per customer, and the largest values belong to companies whose products fall into that quadrant. The source compares public SaaS companies using figures from their public filings.

The gap in contract size is explained by the sales motion. A customer paying contracts of that size is not mainly buying seats or hours of engineering time. The customer is buying an outcome. The vendor supplies engineers to deliver that outcome, in effect a design partnership carried out inside the enterprise. Smaller contracts cannot carry that kind of embedded engineering, which is why the FDE model is concentrated where contracts are large.

Passing the two-question test is not enough. The source is clear that FDEs must build on a platform of shared primitives, meaning reusable building blocks the team has already written. Without that platform, the economics of the model collapse. The source describes the failure case plainly: if every FDE builds each solution entirely from scratch, the function has stopped being an FDE function and has become what the source calls a dev shop, a team that writes custom software for each client.

This gives a second screening question for any company considering the motion. Does the company have a platform for FDEs to build on, or is it willing to invest in building one? The first question asks whether the product and buyer call for embedded engineers. The second asks whether those engineers will be able to work efficiently once they are embedded. A company can pass the first and still fail the second.

The role appears under many names. Companies do not agree on one title for the work, and the same underlying function can be labeled differently from one organization to the next. The source gives several examples. One company splits the work into two roles: embedded analysts who hold deep domain expertise and own the customer relationship, and deployed engineers who build the solution. Another uses the title Forward Deployed Engineer and distinguishes it from a Solutions Architect, a more advisory profile that does not write production code on customer infrastructure. Others use titles such as Applied AI Engineer, Agent Engineer, or Implementation Engineer.

The map shows the variety of labels the source reports. Notice that the Solutions Architect sits off to the side as a contrast. It is an advisory profile that does not write production code on customer infrastructure, so it is not the same deployment function even though it appears in the same customer conversations.