Recommended resources
The freely available resources this lesson will direct you to.
Hello! This course is about taking a customer’s data or AI problem from an uncertain request to a working, supportable deployment. Before studying discovery, architecture, and implementation, it helps to know what a Forward Deployed Engineer (FDE) is accountable for—and where that accountability meets the work of product, platform, and solutions-engineering teams.
In this lesson, you’ll follow one customer problem through those boundaries. The distinction matters when evaluating FDE job descriptions and when explaining, in an interview, what you would personally build, what you would decide with others, and how you would know the work succeeded.
The FDE’s unit of work: a customer outcome
Consider a support team that wants an AI assistant to find relevant policy documents and draft replies to incoming tickets. A demonstration using sample documents might establish that the idea is plausible. It does not establish that the assistant can respect the customer’s document permissions, cite the correct policy version, fit the agents’ workflow, or remain useful when retrieval fails.
The FDE’s central delivery responsibility is to close that gap. An FDE works directly with the customer to understand the workflow, identify a tractable use case, build or integrate the necessary software, validate it with real users and constraints, and help bring it into dependable use. The output is not merely code or a design; it is a working capability tied to an agreed customer result.
Watch how a practicing FDE distinguishes that work from sales engineering and core software development. The speaker also describes the listening, prioritization, and engineering skills involved.
What is a Forward Deployed Engineer? (with Founding Rippling FDE)
Watch “What is a Forward Deployed Engineer?” from Aced (formerly Exponent) for a practitioner’s account of the role’s scope, from understanding a customer problem to securing acceptance of a delivered solution.
Watch role boundaries for the contrast with sales engineering and core software development. Continue with three capabilities, focusing on why listening and local prioritization must lead to shipped software. Then watch delivery ownership for what remains after code is written: demonstration, feedback, and customer sign-off.
The video’s “one-to-one” description captures an important emphasis: the FDE is solving this customer’s problem, not independently designing the next general-purpose product feature. It is not a rule that every line of FDE code must be customer-specific. A good solution may use shared components, and a useful extension may later become part of the product.
An account of forward-deployed work makes the wider scope particularly clear. Read its comparison between a conventional handoff-based workflow and an engineer who remains involved through deployment.
Read this Palantir-authored account, hosted on Medium, to see how customer discovery, application delivery, go-live support, and business outcomes can sit within one engineering role.
In the passage about the “relay race,” read from “At a typical software company” through the feedback returning to Product Managers: the usual handoffs. Then read from “As a Forward Deployed Software Engineer” to the end of that paragraph: the broader scope. In “Focusing on Customer Outcomes,” read from “Deltas are first and foremost” through the shift toward business outcomes: the outcome focus. Notice that broad scope does not mean working without product or customer IT teams.
“Own the outcome” needs a practical interpretation. The FDE cannot unilaterally promise a business result, approve access to sensitive data, or operate every underlying service forever. They can take responsibility for making assumptions visible, driving technical work to an agreed acceptance point, resolving delivery blockers with the right owners, and preparing a clear operational handoff.
Where neighboring roles differ
The diagram below is useful as an overlap sketch, not as a formal job description. It shows why FDE work calls for software-building skill, awareness of shared infrastructure, and solution-level judgment.
For hiring purposes, distinguish the roles by their primary accountability, rather than by whether they attend customer meetings or write code. Those activities overlap.
| Role | Primary accountability | Typical evidence of success |
|---|---|---|
| Product manager and product team | Decide which capabilities should become part of the broader product, for whom, and in what order. | A coherent roadmap and product improvements that serve the intended market. |
| Platform engineer | Provide reliable, secure, reusable infrastructure and developer capabilities used across workloads. | Teams can deploy and operate services through supported, observable systems. |
| Solutions engineer or solutions architect | Help customers evaluate feasibility, understand integration options, and form a credible solution design; often especially active during evaluation. | Technical questions are resolved and the proposed approach is understood and validated. |
| Forward Deployed Engineer | Turn a particular customer’s problem into a delivered data/AI workflow, integrating product capabilities with the customer’s environment and users. | The agreed workflow works under real constraints, is adopted or accepted, and has a viable support path. |
The product boundary can be subtle. An FDE may do product-like work within an engagement: decide with the customer which workflow to address first, narrow scope, and translate feedback into requirements. That is different from owning the cross-customer roadmap. If several deployments need the same missing capability, the FDE should bring evidence to the product team rather than quietly maintain a growing set of incompatible customer-specific fixes.
The platform boundary is similarly practical. An FDE may configure cloud resources, troubleshoot an API, or implement a pipeline. A platform team usually owns the supported shared patterns—such as identity integration, deployment tooling, or observability—that make many such workloads operable. The FDE should use those patterns where appropriate, surface gaps, and agree on ownership before creating something the platform team would have to maintain.
Solutions engineering and solution architecture often come closest to FDE work. Solutions engineers may conduct discovery and build substantial proofs of concept; solutions architects may prototype and guide implementation. The distinction is not “they make slides; FDEs write code.” It is the delivery commitment attached to the work. Who is accountable for making the specific workflow function with actual data, users, permissions, and failure conditions? Who stays involved when a promising evaluation must become a dependable deployment?
A second interview offers a useful description of the architect/FDE overlap—and a reminder that the FDE title is not assigned to the same phase at every company.
Forward Deployed Engineer | Role & Interview Overview
Watch “Forward Deployed Engineer | Role & Interview Overview” from Aced (formerly Exponent) to compare architecture guidance with hands-on workload delivery, and to see an example of an FDE working during pre-sales.
In architect versus FDE, listen for the distinction between advising on the overall design and taking ownership of an initial workload. Then watch pre-sales deployment: this speaker places FDE work in pre-sales and recommends beginning in a customer non-production environment. Compare that account with the earlier video’s broader discovery-through-delivery description.
These accounts do not draw the boundary at exactly the same point. Some FDE teams begin during evaluation and prove a workload in a customer’s non-production environment; others are primarily responsible for post-sale implementation. Do not use “pre-sales versus post-sales” as your only test of a role. Ask instead what must be delivered, who owns the code and deployment, how production readiness is established, and what happens after acceptance.
Following one data/AI delivery
Return to the support assistant. Imagine the customer’s initial request is, “Use AI to answer tickets faster.” That phrase leaves open almost everything that matters: which agents will use it, which documents are authoritative, whether it drafts or sends replies, and what “faster” means without an unacceptable rise in incorrect answers.
During discovery and scoping, a solutions engineer might establish that the product can connect to the ticketing system and demonstrate retrieval on an approved sample. The FDE may participate in those same conversations, but needs enough operational detail to build: where agents currently search, which documents they are permitted to see, who approves a draft, and how errors will be reported. A product manager may recognize that citation controls are a general product need. The FDE and customer must still agree on a feasible first deployment for this workflow.
During design, a solutions architect might propose the overall integration and advise on security and scalability. The platform team might identify approved identity, logging, and deployment mechanisms. The FDE turns those inputs into an implementable slice: retrieve only documents the agent may access, present a draft with citations, and keep the human agent in control of sending the reply. Design decisions belong with the relevant owners; working closely with a customer does not grant an FDE permission to bypass security review.
During build and validation, the FDE’s accountability becomes especially visible. Someone must connect the data source, handle missing or stale documents, integrate retrieval and generation with the ticket workflow, test access controls, and observe failures. The FDE may write that code directly or coordinate parts of it with customer and internal engineers. The important distinction is that they drive the customer-specific workflow toward the agreed result rather than stopping once its feasibility has been shown.
During rollout and handoff, a polished demo is insufficient. The team needs evidence from representative tickets and permitted users: Are citations correct? Do permissions hold? Does the workflow save agent time without making unsafe replies easier to send? The customer must know who can pause the assistant, report an error, update its document source, and maintain the integration. The FDE helps establish that path, even where another team will be its long-term operator.
This example also shows why the roles are complementary, not competing. If the platform’s authentication service fails, its owners should fix the shared service; the FDE should identify the dependency, communicate the customer impact, and adjust rollout accordingly. If the deployment reveals a broadly useful citation feature, the product team should evaluate it for the roadmap; the FDE can provide concrete failure cases and requirements. Outcome ownership means driving the right work across boundaries, not claiming every decision or system as your own.
Reading an FDE job description accurately
Because the title varies, look for the shape of delivery behind it. A data/AI FDE posting is more likely to describe building integrations, pipelines, APIs, or AI workflows in customer environments; working with users on ambiguous requirements; validating behavior with real data; and remaining accountable through rollout. A solutions-engineering posting may involve similar discovery and coding but emphasize evaluations, demonstrations, and technical validation. A platform posting may emphasize shared services and internal developer experience across many teams. A product role may emphasize market-wide prioritization and capability strategy.
In an interview, the most revealing clarifications are concrete:
- What marks a project as complete: a successful evaluation, a production launch, user acceptance, or an operational handoff?
- What the engineer builds and maintains: prototypes, customer-specific integrations, reusable product features, or shared infrastructure?
- Who has decision authority: over customer scope, product changes, security approval, and production operations?
- What happens when the workflow fails: who diagnoses the customer-facing problem, who fixes each dependency, and who communicates with users?
These questions are not an attempt to force every organization into one definition. They establish the responsibilities you would actually be hired to carry.
Key takeaways
A data/AI FDE combines customer-facing problem discovery with hands-on technical delivery. Compared with product roles, the immediate focus is a particular customer workflow rather than the general roadmap. Compared with platform roles, the focus is applying and integrating shared capabilities for that workflow rather than owning every reusable foundation. Compared with solutions-engineering roles, the distinguishing accountability is usually carrying a proposed solution further into working use—though the point at which FDEs join an engagement varies.
The next lesson begins where this work begins: a structured discovery conversation that establishes the users, workflow, pain points, constraints, and success criteria before anyone commits to a technical plan.