What Is a Forward Deployed Engineer?

After this lesson, you should be able to describe what a forward deployed engineer (FDE) does, compare the role with nearby technical jobs, and decide whether its mix of building and customer work fits you. The title appears at several companies, but there is no single job description that applies everywhere. We will use public role descriptions to identify the shared pattern and point out where employers differ.

The role in plain language

A forward deployed engineer builds software close to the people and systems that need it. The engineer works with a customer to understand a problem, turns that problem into a technical solution, and helps test and operate the solution in the customer's environment. "Forward deployed" describes where the engineering work happens: near the point of use, with frequent contact between the builder and the people affected by the system.

The work usually starts before anyone has a complete specification. A customer may know that dispatchers lose time resolving exceptions, but not know which data is available, which system owns it, or which intervention would help. The FDE learns how the work is done, checks the technical constraints, and shapes a first version that can be evaluated. That can involve writing application code, connecting APIs (interfaces that let software systems request information or actions from one another), making a data flow, configuring an existing product, or testing an artificial intelligence (AI) system. The tools depend on the problem.

The role does not have one universal boundary. OpenAI describes its FDE team as working with customer teams to understand workflows, build and evaluate solutions, connect systems, and bring useful systems into production. A current OpenAI job description includes discovery, scoping, implementation, evaluation, production deployment, adoption, and handoff. Palantir describes Forward Deployed Engineering as a product development method in which engineers work close to customer problems and bring feedback to core engineering teams. In a 2025 post, a Palantir author says the company's approach was first called "Echos" and "Deltas," labels for engineers with different strengths in customer communication and coding. That is Palantir's account of its own model. It does not establish that every current FDE role follows the same history. These descriptions overlap in customer contact and engineering outcomes, while their emphasis differs.

What the engineer owns

An FDE is responsible for making progress from an uncertain customer problem toward a working result. That responsibility can span several kinds of work:

• Learn the users' workflow and the systems around it.
• Clarify which problem is worth solving first and what a useful result would look like.
• Build or adapt software, data connections, or AI features.
• Check that the solution works on representative tasks and in the target environment.
• Help the customer adopt, operate, and improve the result.
• Carry lessons from the engagement back to the product or engineering team.

The list is not a promise that one person does every task alone. The customer may own a source system; a product team may own a shared service; security staff may approve access; and another engineer may build a platform feature. The FDE makes the work across those boundaries understandable and helps the people involved agree on who owns each part.

For example, NorthPort Freight is a fictional regional logistics company in this course. Suppose its dispatchers spend time resolving orders that fail to match between an older ordering system and a newer dispatch tool. Before proposing an AI assistant, an FDE would ask dispatchers to walk through a real exception, find out which records can be accessed, and learn what a safe correction looks like. The first result might be a reliable feed that shows the mismatched fields. It might not need an AI model at all.

That distinction between the customer's requested tool and the underlying task matters in practice. A request such as "add an agent to dispatch" is a starting point. It does not yet say what data the agent may read, what action it can take, what a dispatcher must approve, or how the team will know it helped. The FDE works with the people who know the operation to turn those unknowns into decisions and checks. Later lessons cover discovery, scoping, data audits, and evaluation in detail.

How the role differs from nearby jobs

Job titles overlap, and small companies may combine responsibilities. These comparisons describe common centers of work. A specific employer's job description may draw the lines differently.

Software engineer

A software engineer typically builds and maintains a product or service for a defined set of users. The users may be internal or external, and the work may include product discovery, support, or customer visits. In many organizations, however, a product engineering team owns shared code and plans work across several customers or product areas.

An FDE spends a larger share of the work close to a particular customer's workflow and constraints. They may write production software, but they also need to learn how a local process works and connect the result to systems the team does not control. The distinction is about the center of the role, not the quality or importance of the engineering.

Solutions engineer

A solutions engineer helps a prospective or existing customer understand how a product can meet a technical need. That often includes architecture discussions, demonstrations, proofs of concept, and answering technical questions during an evaluation or sale. Some solutions engineers write substantial code; others focus more on product fit and technical guidance.

An FDE is usually expected to carry more of the implementation into the customer's working environment. The FDE may build integrations, adapt a system, and stay involved through validation and handoff. Some employers use the titles differently, so look for the verbs in the role description: demonstrate and advise suggest one emphasis; implement, deploy, and operate suggest another.

Consultant

A consultant studies a client's problem and recommends or delivers a change. The work can include analysis, process redesign, implementation, or technical delivery. Consultants may also be deeply hands-on engineers.

The FDE role puts software engineering at the center of the engagement. The expected work product often includes code, an integration, a deployed system, or reusable engineering patterns. A consultant may deliver code too, and an FDE may do planning and analysis. The practical question is what the team expects the person to build and who will operate it afterward.

Sales engineer

A sales engineer supports the sales process by explaining technical capabilities, checking requirements, and helping a prospective customer assess a product. The role often works alongside account executives and product teams. Some organizations use "solutions engineer" for similar work, while others distinguish the two titles.

An FDE may join conversations before a sale, especially when technical uncertainty is high. The FDE's work continues into implementation and production delivery. That does not make commercial context irrelevant: the engineer should understand why the customer is considering a project. It does mean that a demo or proposal is usually not the final engineering outcome.

What "embedded" means

In this context, embedded engineering means working closely with a customer team while keeping a clear engineering role. "Embedded" does not necessarily mean sitting in the customer's office. Some engagements are on site, some are remote, and some combine both. The important part is access to the people, context, and systems needed to do the work.

Close contact has practical value. A dispatcher can explain why an order is marked as an exception, while a data engineer can explain what a field means in the source database. A diagram or ticket may omit a local rule that everyone on the operations team knows. Working with the people who use and maintain a system helps uncover those rules before they turn into defects.

The customer still owns its business decisions and operating responsibilities. The FDE should make assumptions visible, ask for the right approvals, and document decisions that affect the customer's system. If the customer's team will own the service after handoff, they need a chance to review how it works and what to do when it fails. A technically successful deployment that nobody can operate is not a complete delivery.

Terms used in FDE work

Some terms appear across companies and project teams. The definitions here are practical descriptions; an employer may use a term more narrowly.

Last-mile integration is the work of connecting a general product or service to a customer's specific systems, data, permissions, and workflow. A product may already support an API, for example, but the customer still needs an approved identity, a mapping from its order fields, and a plan for handling failed requests.

Delta means the gap between what a product can do today and what a customer needs for a particular workflow. Palantir has also used "Deltas" as a label for an engineer archetype. In this course, Delta means the product gap revealed by an engagement. A useful delta might be a missing connector that several customers need. A one-off field mapping may belong in customer configuration instead of the shared product.

Productized consulting is consulting work that becomes a repeatable product capability. The first customer may need a custom way to connect two systems. If other customers have the same need, the team might turn that work into a supported connector or a reusable setup process. The decision requires evidence about who else needs it and who will maintain it.

Embedded engineering is close collaboration between engineers and the customer team during problem discovery and delivery. It describes a working relationship, not a guarantee of a particular office location or reporting structure.

These terms describe different parts of the work. Last-mile integration is a type of implementation. Delta describes a product gap. Productized consulting is one way an organization might decide to address a repeated gap. Embedded engineering describes how the FDE works with the customer while making those decisions.

From a customer problem to a deployed result

An engagement can be understood as a path from a problem to an outcome. The path is rarely a straight line. New information may change the scope, a test may reveal a data issue, or a customer approval may take longer than expected. The engineer should keep the next decision visible and record why the plan changes.

Consider NorthPort's dispatch exception. First, the FDE observes how dispatchers identify and resolve one mismatch. Next, the customer and engineering team agree on a small outcome: show the relevant order fields together and flag records that need a person to review them. The team checks whether the old ordering system can provide the required fields and who may access them.

Then the FDE builds or configures a first version. The team tests it with representative records, including cases where data is missing or inconsistent. Dispatchers review whether the result helps them make the next decision. If it passes the agreed checks, the team plans deployment, documents how to monitor failures, and agrees who will respond when something breaks.

During that work, the FDE may find a reusable product need, such as a configurable mapping for common order fields. The product team can decide whether that belongs in the shared product. The customer-specific rule may remain in NorthPort's configuration. The FDE records the distinction so the next engagement does not have to rediscover it.

The example is fictional. It does not claim that a particular integration, model, or business result has been tested. Its purpose is to show the kinds of questions and artifacts an engagement may involve. Later lessons will build the discovery questions, data audit, acceptance checks, and handoff materials that make this path concrete.

Who tends to fit the role

The role can suit an engineer who likes building software and is willing to spend time understanding how other people work. It calls for curiosity about unfamiliar systems, patience with incomplete requirements, and clear communication with people who may not use engineering vocabulary. The work also asks for judgment about when a small change is safe to test and when a customer team needs to resolve an open question first.

The role may feel frustrating if you want long stretches of uninterrupted work on one codebase, prefer requirements to arrive fully specified, or do not want regular customer interaction. FDE work can include travel or on-site time, depending on the employer and customer. Check the actual job description and ask what a typical engagement looks like before drawing conclusions from the title.

You do not have to be an expert in every customer system. You do need a method for learning one: inspect what is available, ask the people who know its history, make a small reversible change when possible, and record what you have not verified. A strong FDE knows when to investigate, when to ask for help, and when a proposed solution is still an assumption.

If you are deciding whether to pursue the role, look for evidence in your own work. Have you built something for people whose process you needed to understand? Have you handled an integration where another team owned the system? Have you explained a technical trade-off to someone making a business decision? These examples are useful signals. They do not guarantee a fit, but they help you identify which parts of the job you have already tried.

Mistakes beginners make

1. Treating the title as a standard job description. Employers arrange customer work and engineering work differently. Read the responsibilities and expected outcomes, not only the title.
2. Assuming every customer request needs AI. Start by understanding the task. A data feed, a search page, or a manual review step may solve the immediate problem more safely.
3. Calling a demo a delivery. A demo can test an idea. Production delivery also needs checks, access decisions, operational ownership, and a handoff the customer can use.
4. Working around the customer team. The people doing the task often know rules that are missing from diagrams and tickets. Include them while defining and checking the solution.
5. Confusing custom work with a product feature. A change for one customer does not automatically belong in the shared product. Record the gap and gather evidence about reuse before generalizing it.

Recap and try it yourself

A forward deployed engineer works close to a customer's problem and carries engineering work toward a result in that customer's environment. The role often combines discovery, implementation, validation, deployment, and feedback to product teams. Employers define the role differently, so compare responsibilities and expected outcomes with nearby jobs such as software engineer, solutions engineer, consultant, and sales engineer. Last-mile integration, Delta, productized consulting, and embedded engineering describe separate parts of this work.

Try it: choose a workflow from a team or organization you know. Write down who does the work, what system or information they use, and where they lose time or encounter an exception. Then write one question you would ask before proposing software, one result you could check with the user, and one team that would need to operate the change. Keep assumptions separate from things you have observed. In the next lesson, you will follow an FDE through a working day and the stages of a customer engagement.

Sources

Checked on 5 November 2026. Job descriptions and company materials can change.

• Forward Deployed Engineering at OpenAI, for OpenAI's account of customer workflows, production deployment, evaluation, and reusable capabilities.
• Forward Deployed Engineer, Healthcare at OpenAI, for a current job description covering discovery, scoping, implementation, evaluation, deployment, adoption, and handoff. The healthcare-specific duties are not general requirements for all FDE roles.
• Beyond Founder Mode: Mission Mode, a 2025 Palantir Blog post, for the company's account of its early "Echos" and "Deltas" labels and the FDE approach.
• Palantir Architecture Center, for Palantir's description of Forward Deployed Engineering as a product development method that connects work close to customer problems with core engineering feedback.