Building a Platform for Forward Deployed Engineers

A Forward Deployed Engineer is a customer-facing software engineer who deploys a technical product for a customer, working directly inside 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 walks through that question in a fixed order: first the test that decides whether the role is needed, then the economics that make it 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 two facts about the sale: what is being sold and who is buying it.

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. Follow the path in the diagram below to see how each answer narrows the decision.

Read the path step by step. Step one: identify the product. If it is configurable, meaning the buyer adjusts options and settings, the path ends at FDE not needed. Business software such as Rippling, Jira, or Slack falls here, because configuring them does not require engineering. If the product is technical, you move to step two and identify the buyer. A technical buyer has the skill to integrate the product alone, so the path ends at FDE not needed. Developer platforms such as GitHub and Datadog are examples of this pattern. Only the path of a deeply technical product sold to a non-technical buyer ends at FDE needed.

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 material compares public SaaS companies using figures from their public filings. The rough picture is shown below.

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. FDE work only works at scale when it builds on a platform of shared primitives, meaning reusable building blocks the team has already written. Each customer deployment is assembled from those common parts, and only a thin layer is tailored to the specific customer. The diagram shows that split: the common platform sits underneath every deployment, while customer-specific configuration sits on top.

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. Economics collapse in that case, because each new customer costs as much engineering as the last one. The platform is what lets an engineer's effort on one deployment carry over to the next.

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.

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. Other titles in use include Applied AI Engineer, Agent Engineer, and Implementation Engineer.

The source offers a useful way to read these titles. Customer Success is a strategy, not a job title. Any role that owns the outcome the customer paid for is doing customer success in the strategic sense, whatever it is called. When you meet an unfamiliar title, ask two questions. Does the role own the result the customer bought? Can it ship the change needed to deliver that result? If both answers are yes, the role performs the FDE function regardless of its label.

Return to the diagram and retrace the path in order. Question one sorts the product into technical or configurable. Question two sorts the buyer into technical or non-technical. Only a deeply technical product sold to a non-technical buyer reaches FDE needed. Then the economics and the platform condition must also hold, because a passing screen does not guarantee a working model.