What Does a Forward Deployed Engineer Actually Do?

A forward deployed engineer works close to a customer's business and builds the software needed to make a product work there. They turn an unclear operational problem into a scoped deployment, connect the systems, test the result, and help users put it into daily work. The role combines production engineering with customer discovery, and its value depends on how well those activities connect.

Define the role by its responsibilities

“Forward deployed” describes proximity to the work. The engineer spends time with the people who use the system, learns their constraints directly, and can change the implementation while those details are fresh. That can mean working on site, joining a customer's engineering team remotely, or embedding with an internal business unit. The title alone doesn't tell you their reporting line, autonomy, or support duties.

Current employer descriptions show the variation. OpenAI's Sydney FDE role covers discovery, scoping, system design, building, and production rollout, with feedback into product and model roadmaps. Roboflow's role starts after sales and solutions architecture validate the approach, builds the first production deployment, and hands over to implementation engineers for expansion. These are statements about each employer's role design, rather than evidence that every FDE works the same way.

For an AI product, the work often includes connecting approved data sources, defining how a model can use tools, testing failure cases, and setting up monitoring and a fallback. A model that produces a convincing demonstration still needs those parts before a company can rely on it. An FDE discovers which parts the specific customer needs and takes responsibility for delivering the agreed scope.

Follow a deployment through real work

Consider an illustrative deployment at a B2B distributor. The company wants an AI assistant to prepare quotes from customer emails. Its ERP stores product codes, sales staff keep discount rules in several documents, and customers describe the same item in different ways. The FDE's first task is to follow recent quotes with the sales team and identify where a wrong answer causes rework or a commercial loss.

The engineer turns that observation into a bounded first release: draft quotes for a defined product group, use the approved price list, flag uncertain item matches, and require a salesperson to approve discounts. They map the source records and permissions, build the email and ERP connections, and create test cases that include missing codes and contradictory requests. The commercial and process owners agree what counts as an acceptable draft.

During the pilot, the FDE watches where the system fails. A wrong product match may call for a better lookup, while an undocumented discount exception calls for a decision from the sales manager. The engineer changes the system and records the business rule that justified the change. They can explain to users why a case stops for review and to core engineers why several customers need the same matching capability.

The deliverables include working code and configuration, an evaluation set, a release record, and instructions for operating the workflow. They also include a clear account of unresolved limits. The customer needs to know which quotes still require the old process and who responds when the ERP connection fails.

Understand the overlap with other roles

A full stack engineer can build the same connectors and interface. An FDE role makes direct customer discovery and delivery accountability a regular part of that engineering work. A strong product engineer who already spends time with users may perform much of the function without the FDE title.

A solutions or sales engineer often helps a prospect understand technical fit, architecture, and proof of value. Some also write deployment code. Check where responsibility ends: after the demonstration, at contract signature, at production launch, or after an agreed support period. The overlap depends on the company, and a title change doesn't establish a new boundary.

A consultant can diagnose the process, redesign it, and build the implementation. A product manager can frame the problem and set priorities. FDEs combine parts of those activities with direct engineering, but they still need people who own commercial commitments and business decisions. Intuit's FDE description, for example, places the role in Engineering and describes partnerships with Sales, Account Management, Product, and core engineers.

Give the FDE a team and clear authority

For a small engagement, an FDE may work with a shared core developer, an account lead, and a customer process owner. The account lead owns the contract and commercial relationship. The process owner decides which business rules and outcomes are acceptable. The FDE owns the technical deployment, while the core developer or product team owns changes to the shared platform.

A larger consulting or transformation project may also need a product manager and a change lead. The product manager sets the outcome and backlog with the client; the change lead coordinates training and changes to daily work. Name who can approve scope changes, grant data access, accept a release, and pause the system. Several of these responsibilities can sit with one person in a small firm, provided they have the time and authority to do them.

There isn't a universal ratio of one FDE to one developer or salesperson. Estimate the work: customer discovery, integration depth, security review, testing, and support. A complex legacy integration may need more engineering capacity; a repeatable configuration may need less. Staff the engagement against that work rather than copying another company's org chart.

Decide who operates the result

Agree on support ownership before launch. If the FDE leaves after the pilot, a named team must receive the code, access, tests, monitoring, and runbook, and demonstrate that it can operate the system. If the FDE keeps responsibility, give them capacity for incidents and routine changes rather than filling every hour with new deployments.

Also decide how customer work enters the shared product. A local connector can stay within the engagement; a repeated need may justify a supported platform capability. Core engineering needs the requirement, evidence from deployments, maintenance cost, and a proposed owner. That review prevents an urgent account request from becoming an undocumented permanent dependency.

Measure deployment outcomes

Track time to a production workflow, the quality of completed cases, user adoption, and the effort needed to keep the deployment running. Count customer review time and FDE support hours. A fast prototype that requires daily manual repair may be a poor result even if the demonstration impressed the buyer.

For investors, ask whether deployment effort falls as the company learns and whether field work improves the product. For business leaders, ask whether the receiving team can own the workflow after launch. If you're considering the role, use our guide to when you need a forward deployed engineer to identify the work before choosing the title.