A demo can pass while the first customer handoff still fails. The integration is unclear, nobody owns the fallback, or the team cannot tell whether the workflow is good enough to release.
Start with the delivery problem
Forward deployed engineering is a working description, not a regulated job taxonomy. I use it for hands-on engineering inside a customer workflow, from discovery and integration through rollout and handoff.
The title means different things at different companies. The useful question is narrower: who will turn this particular workflow into something a customer can run, measure, and own?
Forward deployed engineer vs solutions engineer vs consultant
The comparison below is practical rather than universal. Titles overlap, and a person can cover more than one column on a small team.
| Role | Closest to | Typical contribution | Handoff question |
|---|---|---|---|
| Forward deployed engineer | The customer workflow and its production constraints | Scope, build, integrate, test, roll out, and feed reusable lessons back into the product | Can the customer team run the workflow and see what needs attention? |
| Solutions engineer | Evaluation and technical buying decisions | Understand requirements, demonstrate a solution, validate fit, and support the sales process | Does the buyer understand the technical fit and the next implementation step? |
| Consultant | A problem, decision, or change programme | Investigate context, recommend a path, and sometimes lead or support implementation | Does the client have a decision, plan, and owner for the next step? |
OpenAI describes one version of the FDE role as owning discovery, technical scoping, system design, build, rollout, adoption, and product feedback. That is evidence of how one employer uses the role, not a standard that every company follows. Read OpenAI’s Tokyo FDE role description.
What does a forward deployed engineer do?
The work starts before code. Someone has to name the user, the decision the workflow supports, and the evidence that would make the result useful.
- Discover the real workflow. Trace what the user does now, where data enters, who approves an action, and what happens when the system is wrong.
- Make the scope testable. Write a small outcome, acceptance criteria, constraints, and a list of unknowns. Do not hide an open decision inside an estimate.
- Build the path that matters. Connect the product to the customer’s systems, add the model or automation step, and keep the failure path visible.
- Run it with the people who own it. A rollout includes permissions, monitoring, a fallback, documentation, and a handoff. It is not finished when a local demo works.
- Return the lesson to the product. A repeated integration or failure pattern may belong in a product capability instead of another one-off adapter.
From discovery to production
Customer proximity does not mean sitting in the same office. Lucent Lab works remotely by default, with on-site work by agreement. The important part is access to the people, systems, and decisions that shape the workflow.
That is where the role differs from a purely advisory engagement. The engineer has to make trade-offs in the code and then stay close enough to observe what happens after release.
If the workflow still needs its original author to explain what happened, it is not ready to hand off.
What is a forward deployed engineer, and when do you need one?
A forward deployed engineer can be useful when the work crosses product, integration, evaluation, and rollout, and the next step cannot be specified from a distance. It is also useful when the customer has a real workflow but the product team lacks delivery capacity or deployment context.
A different role may be better when you need presales evaluation, a strategy recommendation, routine feature development, or a large programme with an established delivery team. Choosing an FDE should not be a way to avoid deciding who owns production.
What to ask before choosing a role
- Who can describe the user’s current workflow and the desired change?
- Who can grant named, least-privilege access to the systems involved?
- Who will decide whether the result is good enough to release?
- Who will operate the workflow after the engagement ends?
- Which part needs implementation, and which part only needs a decision?
If those answers are missing, changing the job title will not remove the blockage. The first useful step is usually to make the workflow and its boundaries explicit.
Sources and further reading
- OpenAI’s Forward Deployed Engineer role description, an example of one employer’s scope.
- Palantir’s account of a forward deployed software engineer, another company-specific example.