When To Hire A Forward Deployed Engineer

Hire or engage a forward deployed engineer when a valuable customer workflow is still uncertain and resolving it requires both production engineering and close work with the people using the system. Before you start, name the workflow owner, the evidence that would justify deployment, and who will operate the result.

If the task is already well specified and supported by standard product configuration, ordinary implementation may be enough. If the company needs permanent ownership of a proprietary workflow across vendors, an internal engineering team may be the better home.

What are you buying with FDE services?

An engagement should make an uncertain workflow concrete enough to build, test, and operate. Ask for concrete artifacts and decision rights: who writes code, approves scope changes, owns incidents, and receives the system?

OpenAI’s FDE role description combines customer discovery and delivery with production adoption, workflow impact, and reusable field learning. It describes an employer’s intended scope as accessed September 8, 2026; it does not establish what every FDE provider delivers.

Start: three conditions to establish first

1. Valuable uncertainty that proximity can resolve

Write down the decision that cannot be answered from the existing specification. Perhaps operators disagree about exception handling, or the workflow depends on undocumented approvals. Identify whose work the engineer must observe and what evidence would change the design. A vague wish to use AI is insufficient scope.

2. A production engineering problem

Name the systems, data boundaries, permissions, and failure modes involved. If the remaining work is standard configuration, ask the vendor to demonstrate that path before funding custom code. If it demands new engineering, establish access and review ownership before the engagement begins.

3. An accountable customer owner

Assign a person who can resolve process disputes, approve acceptance criteria, and provide access to operators. Name the eventual technical owner too. An external engineer cannot supply missing authority inside your organization.

Choose the ownership model before the title

• Vendor FDE: Consider this when uncertainty centers on applying that vendor’s platform and field discoveries can improve its product. Ask what becomes reusable platform capability and what remains your maintenance obligation.
• Independent implementation team: Consider this when work spans several systems and has a bounded delivery outcome. Inspect code ownership, change control, operational support, and knowledge transfer.
• Internal engineering team: Consider this when the workflow is a continuing company capability and priorities, permissions, and vendor choices must remain under your control. External expertise can still fill a bounded gap.
• Standard product implementation: Prefer this when supported configuration already meets the acceptance criteria. Require a demonstrated gap before adding bespoke engineering.

These are comparison questions, not a universal taxonomy. One organization can use several models if the boundaries between them are explicit.

Scale: show what the next deployment reuses

Before adding capacity, inspect which work is new and which is repeated setup, integration, policy encoding, or support.

In its Agent Development retrospective, Decagon describes mapping repeated custom work into a self-service product roadmap and reports an 80% reduction in custom engineering per agent. That is one vendor’s reported result, not an independently verified benchmark or a target other teams should assume.

Compare similar deployments using a small evidence ledger:

• New learning: What workflow uncertainty did this engagement resolve?
• Reusable output: Which connector, evaluation case, configuration path, or product change will the next customer use?
• Repeated effort: How much engineering time went into the same class of work, and did scope or complexity change?
• Adoption: Are intended operators using the workflow, and what exceptions still require intervention?
• Ownership: Who can diagnose and change it without the original builder?

Keep quality and scope beside effort. Lower hours are not progress if the team silently drops difficult cases. Expand capacity when useful deployments and reusable learning justify it; investigate the delivery model when the same custom work keeps returning.

Stop, narrow, or hand off

A successful engagement can end because the workflow is understood, the product supports it, and trained operators can run it. Continued bespoke support can also be a legitimate purchase, but it should be budgeted and governed explicitly.

Revisit the engagement when nobody can name the next uncertainty to resolve, requests repeat without product improvement, or the customer cannot operate routine changes. Choose among a smaller discovery scope, a product investment, a defined support agreement, or transfer to an internal owner.

Use the FDE engagement exit test for detailed handoff artifacts. This guide addresses the earlier buyer decision: whether embedded engineering is justified and whether it should expand.

A decision memo you can write this week

• Name one workflow, its current pain, and its accountable owner.
• Describe the uncertainty that requires embedded work and the engineering gap standard implementation cannot close.
• Choose the delivery model and assign code, launch, incident, and long-term ownership.
• Agree on acceptance evidence and a review date before implementation. Use the evaluation contract to make that evidence explicit.
• At the review, record a decision: continue discovery, scale delivery, productize repeated work, or transfer ownership. Cite the evidence and remaining unknowns.

For FDEs and team leaders

Engineers can use the memo to expose impossible assignments before accepting them. Ask what authority accompanies delivery accountability and what reusable output the team values. Leaders can define a role around a customer problem instead of combining every unresolved implementation task into one job description.

Sources and limits

Sources accessed September 8, 2026: OpenAI’s San Francisco FDE role and Decagon’s June 22, 2026 retrospective, linked above. A job description is intended role scope; a vendor retrospective is self-reported experience. Neither proves market-wide demand, delivery economics, or guaranteed outcomes. The buyer framework and decision memo are editorial interpretation.