Understanding the Role of Forward Deployed Engineers
Adjacent roles split the work: solutions architects design, implementation consultants from Big Four firms build without shaping the vendor's product, sales engineers support the sale, and customer success managers own the relationship and renewal.
Why Several Roles Look Alike
Enterprise software projects often involve several people who all seem to be doing technical work with a customer. One person may be designing the system, another may be writing code inside the customer's environment, a third may be demonstrating the product before a deal closes, and a fourth may be keeping the account healthy after it closes. Their job titles overlap heavily, so a newcomer can easily assume they are interchangeable.
The source material for this article argues that these roles are not interchangeable. Each one has a characteristic place in the work. The forward deployed engineer, abbreviated FDE, is defined largely by how it gathers together tasks that the other roles split apart. Before looking at the FDE, it helps to see exactly what each neighboring role does.
What do you think happens?
Which adjacent role typically ends its work with a diagram and a recommendation, leaving the building to someone else?
Reveal answer
Solutions architect
At a cloud vendor, the solutions architect works with the customer to design an architecture. The output of that work is a diagram and a recommendation, and building what the diagram describes falls to the customer, to a Big Four firm, or to both.
Five Roles Compared Side by Side
The source compares the roles along a few concrete questions rather than as isolated profiles. The questions are: who writes the production code, who shapes the vendor's product, how long the person stays with the customer, and what the work leaves behind. Answering them for each role makes the position of the FDE much easier to see. The diagram below gives the short version, and the paragraphs that follow explain each entry.
Who Writes the Production Code
The first question asks whether the role writes production code that lives in the customer's own repositories. This is the simplest way to separate the roles, but it is not sufficient on its own. A consultant also writes code, yet the source still treats the consultant as a different kind of role from the FDE. Code authorship answers part of the question. Ownership of the product answers the rest.
Writing code inside a customer's environment is not enough to make someone an FDE. The source states that the label alone does not change the structure of the work.
Where Lessons Travel After a Deployment
The second question is what happens to what the person learns during a deployment. This is the question that the source treats as the clearest test. Every customer problem teaches something, and the roles differ in where that knowledge ends up. The diagram below traces the path in an FDE engagement and in an ordinary consulting engagement.
The source describes the customer success manager's path as slow. A customer success manager identifies a problem, and then the engineering team is prioritized to fix it. The source says this sequence can take quarters between identification and fix. A sales engineer's work exists to close a contract, and the source notes that this is not the same as delivering the outcome the contract promises.
The Property That Separates the FDE
The forward deployed engineer is the role that carries out all of the tasks of the adjacent roles, sequentially or simultaneously, within one person. Coding, design, customer-facing technical work, and relationship ownership are not split among separate people in this model. The source identifies this integration as the reason the role works.
Put in one sentence, the single property that separates the FDE from each adjacent role is that the FDE builds inside the customer's environment while also shaping the vendor's product. The FDE sits on the boundary between the customer's systems and the vendor's product. The solutions architect touches mostly the design side of that boundary, the implementation consultant touches only the customer side without shaping the product, and the sales engineer and customer success manager operate around the sale and the renewal rather than inside the build.
FDE Versus Ordinary Consulting
Because an FDE writes code and spends time with customers, it is tempting to file the role under consulting with a new name. The source rejects this directly. A consultant produces a deliverable, usually a document, and then leaves. An FDE produces working software and stays until that software is producing business outcomes. The two differ in three ways the source names: what is delivered, how long the person stays, and where the lessons go afterward.
| Question | FDE engagement | Ordinary consulting engagement |
|---|---|---|
| What is delivered | Working software | A deliverable, usually a document |
| How long the person stays | Until the software produces business outcomes | Until the deliverable is handed over, then leaves |
| Where lessons go | Back to the vendor's product team so the next deployment is cheaper | Stay with the engagement; do not feed a product other engagements rely on |
Comparing an FDE engagement with ordinary consulting along the source's three questions
The source adds that the difference goes beyond the daily work. It describes the work, the compensation, and the career path as all structurally different. This means the FDE role is not simply a consulting job with a different title.
Mistakes About the FDE Label
Common mistake Assuming any engineer who writes code for a customer is an FDE
What it looks likeA Big Four implementation consultant writes production code inside a client's environment every week.
Why it failsThe source states that writing code or working closely with a customer does not make someone an FDE, because the consultant's lessons do not feed back into the vendor's product.
Do this insteadCheck whether the work changes the vendor's product through the lessons it produces.
Common mistake Treating the FDE label as a fix for consulting work
Why it failsThe source warns about a cargo-cult version of the role, where the work looks like consulting on the surface. Calling consulting an FDE engagement changes nothing about the underlying structure of the work.
Do this insteadJudge the role by what is delivered, how long the person stays, and where lessons go, not by the label.
Common mistake Assuming the four adjacent roles are interchangeable because their titles overlap
Why it failsThe source argues that each role has a characteristic place in the work, even though the titles overlap heavily.
Classifying a Work Situation
To classify a described situation, ask a sequence of questions drawn from the source. First, is the work about design, building, pre-sale support, or the renewal relationship? Second, if it involves building, does the work reshape the vendor's product? The flowchart below turns these questions into a path to the role the situation most resembles.
A vendor engineer embedded at a customer site
An engineer spends several months at a customer's site. She writes integration code that runs in the customer's own repositories. Whenever she finds a gap in the vendor's product, she brings it to the product team, and the next deployment reuses the fix. She stays until the system is producing the customer's business results.
- 1Identify the work
The work includes building code in the customer's repositories, so it is not pure design, pre-sale, or renewal work.
- 2Check whether the work reshapes the product
Her lessons flow back to the product team, and the next deployment becomes cheaper, which the source identifies as the FDE pattern.
- 3Check how long she stays and what she delivers
She stays until the software produces business outcomes and delivers working software, not a document that she leaves behind.
- 4Choose the role
The work matches the forward deployed engineer role rather than an implementation consultant, because it both builds inside the customer environment and shapes the vendor product.
This situation most resembles a forward deployed engineer engagement.
Practice Classifying Situations
A vendor employee produces a design diagram and a written recommendation for a customer's cloud architecture, then hands the diagram to the customer's team and does not write production code. Which role does this most resemble, and which question in the flowchart decides it?
Hints
- Start with the first question in the flowchart: is the work about design?
- Consider what the deliverable is and who builds it afterward.
An engineer writes code inside a customer's environment for six months and produces a working system. Afterward, the engineer leaves, and the lessons are recorded only in a final project report. Which role does this resemble, and what single fact in the description makes it closer to ordinary consulting than to an FDE engagement?
Hints
- Compare where the lessons go with the source's test for an FDE.
- Notice whether the engineer stays until business outcomes are reached.
Procurement and the FDE Contract
The integration that defines the FDE also creates a practical problem when a customer tries to buy the role. The source notes that a customer's procurement team often has no category for it. Procurement is set up to buy software seats or consultant hours, and an FDE fits neither category. The source gives this as one reason that contract negotiations for FDE engagements are often a struggle.
Key Takeaways
- Adjacent roles split the work: solutions architects design and stop at the design boundary, implementation consultants build without shaping the vendor's product, sales engineers support the sale, and customer success managers own the relationship and renewal.
- The FDE integrates the tasks of these roles, sequentially or simultaneously, in one person, and is defined by building inside the customer's environment while shaping the vendor's product.
- The clearest test separating an FDE from ordinary consulting is whether lessons return to the vendor's product team so the next deployment is cheaper, along with producing working software and staying until business outcomes are achieved.
- Writing code or working closely with a customer does not make someone an FDE, and the label alone does not change the structure of the work.