Before you hire forward deployed engineers, answer four questions

A retailer processes refunds through six software products from six vendors. One vendor’s engineer proves that its product works. The refund still fails somewhere in the other five. Another engineer from that vendor will not fix this. The retailer has to name a person who can decide changes across all six products. Each vendor has to agree what it is responsible for.

Here the first problem is coordination. In another deployment the first problem may be missing software that connects the systems or handles the retailer’s refund rules.

A forward deployed engineer (FDE) works directly with the people who will use a system, understands their problem and builds software that works in their daily operations. If your company is one of those vendors, or any company that sells software or builds systems for other businesses, here are four questions to answer before you hire. For an internal team, apply them to the department using the system. In that case your own company provides the access, the decision-maker and the budget, and the contract advice later in the article does not apply.

Four questions before you hire

Use these questions to decide what to do next.

1. Would a documentation or product change remove this problem for every customer?

If yes, prioritise that change. A customer-specific workaround may be needed while it is built. Decide who maintains the workaround and when it will be removed. A workaround with an end date is not a reason to hire.

If each customer’s data, systems or operating rules require different engineering work, describe those differences. That is the assignment. The next question is whether your existing team has the people and time for it.

2. Can the customer provide access to its people, data and systems?

Confirm the customer’s access approvers, required reviews and availability dates. Agree remote access, working hours and visits before assigning the engineer. Seniority cannot substitute for permission to inspect a system or speak to the people doing the work.

3. What will the customer authorise, and what can your engineer decide?

Ask the customer to nominate the person who can approve business rules and coordinate its teams and the other companies involved. Only the customer can appoint that person. Record what your FDE can change, what needs customer approval and what requires agreement from your product, security or commercial teams.

In the refund example, the vendor’s engineer can fix that vendor’s integration. Only the retailer can get decisions from its finance team and the other vendors.

4. What does the work cost today, and how will you judge improvement?

Agree a baseline with the customer: time spent, unresolved exceptions and support effort for that workflow. Decide when to compare results and who accepts them. If those measures are missing, collecting them is part of discovery.

A deployment date cannot tell you whether the problem improved.

Turn the answers into a decision

What you find	Next decision
A shared product or documentation change removes the problem	Fix the product or documentation first. Limit any temporary implementation work.
The customer cannot provide access or an authorised decision-maker	Wait until the customer names who approves access and decisions before assigning an engineer.
The problem, baseline or required implementation is still unclear	Propose paid discovery with an agreed scope, outputs and end date. Decide on delivery after reviewing the findings.
A team that already builds and connects software for customers can do the work	Assign the work there. If that team lacks people or permission, give it those before starting a new team.
Recurring customer-specific engineering remains, with access, authority and success measures agreed	Assign or hire an FDE, with a named colleague to review the code and cover absences. Expand the team when the workload justifies it.

You may go through these decisions in order. Discovery may identify a shared product fix rather than an FDE engagement. One customer’s request is rarely enough continuing work for a permanent team.

Which companies hire FDEs, and why?

Four kinds of employer hire them:

Companies that build AI models or cloud platforms. OpenAI hires FDEs to build and launch systems with its customers. AWS describes engineers working alongside customer teams to build and operate AI systems. Access to the technology is only part of the job. The system still has to work with the customer’s data, software and security requirements.
Companies that sell software for business operations. Palantir hires engineers to build applications around customers’ data and operating problems.
Companies paid to build and connect software for clients. Accenture’s FDE role includes putting technology from companies such as Anthropic, Microsoft and SAP into use inside client organisations. Accenture makes neither the model nor the product.
Companies building systems for their own staff. In a July 2026 account, a Palantir employee describes customers forming their own internal FDE teams. Here, the engineers work with departments in their own company to solve operational problems. The same account describes how customer work informs improvements to Palantir’s shared product.

In each case the engineers work closely with the people using the system, to discover what to build, make it work and improve it. That need is what justifies the hire, not being the same kind of company as Palantir or OpenAI.

Can your existing team do the work?

Compare what people actually do before adding another team:

Existing responsibility	What to check before adding FDEs
Help customers evaluate the product before buying (solutions or sales engineers)	Does the team stop at demonstrations and trials, or also build and support the working system? If it stops before launch, someone else must take responsibility.
Set up and connect software for customers (implementation or professional services team)	Does the team already write the code and handle the customer work this assignment needs? If so, give it enough people, time and permission to do the work. A new name is optional.
Build the product used by all customers (product engineers)	Can one shared change solve the problem across customers? Put that work in the product plan and test it with one customer.

Consider a separate FDE team when this work recurs and the existing teams cannot do it alongside their current work. Renaming a team does not give it more time, engineering support or authority.

Start with a small team and engineering oversight

If your FDEs write and maintain software that customers use, put the team under an engineering leader. That leader should own technical quality, staffing and escalation. Sales agrees the contract. The people managing the customer relationship help the customer use the system. Neither should promise engineering work before the engineering lead reviews it.

If the team that already builds systems for customers has technical leadership, code review and support for running systems, the FDEs can remain there. Write down that those responsibilities continue. The reporting line is a management choice, not evidence that the work will be supported.

Start with one experienced engineer leading one clearly scoped deployment, plus a named colleague who can review the work and cover an absence. Those people can come from your existing team. Hire a second person if nobody can review and cover, or if one deployment is more than one engineer’s work.

Choose the lead for demonstrated production delivery and customer communication. In the interview, discuss a realistic deployment, introduce a failure and ask the candidate to explain diagnosis, recovery and the decision to a non-specialist. They should know when to ask a specialist for help.

One engineer per customer is a starting estimate, not a rule. Count the deployments running at once, the travel, the specialist help and the support each customer was promised. Share an engineer across customers only when that schedule leaves time to support each deployment. Add people when the agreed work is more than the team can do.

Six Spider-Men point at each other, labelled CRM FDE, Payments FDE, Data FDE, AI FDE, Cloud FDE and Integration FDE. The headline asks: Six vendors. One customer. Who owns the bug? The punchline reads: Everyone is forward deployed. Ownership is still pending. — A fictional illustration of unclear responsibility across six software companies. View the full-size image.

Decide who pays before promising delivery

Separate three kinds of work in the budget:

Before the sale: agree a limit for technical validation and charge the effort to the budget for winning the contract. Define what it must establish and when it stops. If the customer wants a custom build before signing, price that separately.
Discovery: when you cannot yet write a credible delivery proposal, offer a paid investigation. Specify the questions, permitted access, findings and implementation options the customer will receive. Either party can stop after discovery.
Implementation: either price the work as a separate service or state the implementation allowance included in the product contract. In both cases, record scope, acceptance criteria, support responsibilities and how additional work is approved.

These are defaults. Your product and contract may need different ones. Implementation included in the contract still costs engineering time. Record that cost against the account. Assess discovery by the decisions it enables, implementation by agreed delivery and adoption measures, and ongoing support by reliability and effort. Billable hours alone do not establish that the customer’s problem improved.

Build a budget for the hiring location

The staffing advice applies to companies in India and elsewhere in Asia-Pacific as well as the US. Salary budgets must use the hiring location, level and employment terms. Compare current local vacancies and candidate expectations, with base pay, variable pay and equity recorded separately. Converting a US range into rupees does not produce an Indian salary benchmark.

Include review time, specialist support, travel, documentation and someone on call for incidents. If the team uses coding agents, compare the full cost of an accepted fix, including retries and review time, when choosing a model. Agree visits and time zones with the customer before you plan on one remote engineer.

US employer examples, checked 15 September 2026

OpenAI’s Seattle FDE posting lists $185,000 to $300,000 plus equity and up to 50% travel. Anthropic’s FDE posting for New York, San Francisco and Seattle lists an annual salary of $280,000 to $320,000. Both are US dollar figures for particular jobs. Treat them as two data points and nothing more.

In its August 2026 release, Pave moved FDE from its Hot Jobs watchlist to an officially benchmarked job family after adoption reached its stated threshold. So treat FDE as its own role when you benchmark, using data for your location.

Review the deployment and whether you still need the team

Give the engineer access to specialists and time for investigation, tests and customer communication. Before launch, agree who is on call and how handover works. The customer should know who responds when the assigned engineer is unavailable. I describe the broader delivery approach on building enterprise AI systems, and how I help engineering teams use coding agents on improving software delivery.

Review customer work regularly with the product team. Decide which changes belong in the shared product, which remain customer-specific and which commitments should stop. a16z’s implementation-team guidance recommends limited initial scope, reusable integrations and feedback from customers to product teams.

At the agreed review date, compare the customer’s process with the baseline. Check whether people can use the system, whether exceptions have decreased, and what it costs to support. Also check whether the next customer will need the same engineering effort or can use the improved product.

Approve the next hire when that review shows more work than the current team can do. If the work is better resolved through a product change, clearer customer authority or a paid investigation, fund that instead.