When Does Your Company Need a Forward Deployed Engineer?

You may need a forward deployed engineer when customers want the outcome your product promises, but reaching it requires sustained engineering inside their systems and workflows. Look for repeated deployment obstacles and valuable work that needs someone to discover and solve them directly. Then check whether an FDE, a product improvement, or an implementation partner is the best way to remove the obstacle.

Identify what blocks production use

Review your last few customer deployments. Mark the time spent waiting for access, learning the workflow, writing integrations, agreeing acceptance criteria, testing, and training users. Record who did each task and what delayed it. A founder spending days interpreting customer data is a different problem from a release waiting for a procurement signature.

Separate demand from delivery. An interested prospect who will not fund the work or make an operator available may not have a sufficiently important problem. An FDE cannot establish a business owner's priorities on their behalf. If customers do want the outcome, trace the distance between a working demonstration and a repeated task completed in their production environment.

In a company deploying AI internally, do the same exercise with business units. A workflow might need an engineer close to finance or operations because its rules live with staff and its data sits across old systems. It also needs a sponsor who can decide what changes and an owner who accepts responsibility after launch.

Look for the signals that support an FDE

The strongest case combines several observations. Each customer has enough local variation to require discovery; deployment needs substantial code or system configuration; and what you learn can improve the next deployment. The engineer's time with users changes what they build, rather than merely adding meetings to a known implementation.

You may see founders repeatedly acting as the customer engineer, core developers interrupting platform work to handle integrations, or signed customers waiting months for first production use. Check the causes. If the delays depend on understanding a customer's workflow and making technical decisions in that context, an FDE may give that work a consistent owner.

Lemma's published hiring brief describes an example: founders embedded with early customers, then created an FDE role to repeat that work and turn lessons into product improvements. Infer's brief describes deployments where insurance workflows depend on legacy systems and business rules held by experienced staff. These explain why those companies created the role; they don't establish a hiring threshold for yours.

Compare the other ways to do the work

If every customer gets stuck at the same setup step, improve the product, documentation, or onboarding path. Assigning an engineer to repeat the same workaround can conceal a fix that would help every account. A product team may still need direct customer contact to find that fix, without creating a separate deployment function.

If the software is stable and the work follows a known integration pattern, an implementation engineer or specialist partner may fit. They need clear specifications, access, acceptance tests, and a support agreement. Use consulting help when diagnosis, operating-model decisions, or change management dominate the assignment; check whether the consultant also has the engineering capacity the engagement needs.

If the work needs a new shared capability, give core engineering ownership. An FDE can gather evidence and build a bounded prototype, but the platform team must decide how it becomes supported product. If the obstacle is a manager who cannot release staff or approve a business rule, assign a business decision owner. More engineering hours won't resolve an absent decision.

The boundaries can overlap. Start with the work and the outcome, then choose the staffing arrangement. Our guide to the FDE role explains the responsibilities you should specify.

Test the decision on an actual deployment

Consider a hypothetical AI vendor serving distributors. Three customers have signed for quote preparation, but each uses different product codes and discount rules. The founder attends customer calls, writes local adapters, and checks early quotes. The first customer reaches production, while the others wait for the founder's time.

That pattern supports a trial of dedicated deployment capacity. Give an engineer one customer, a limited product group, an agreed review process, and access to an operator who understands the rules. Define the first accepted production quote as a milestone. Record the engineering effort and what they learn that another customer can reuse.

During the trial, inspect whether local variation justifies custom work. If all three customers need the same product-matching improvement, make it a platform priority. If most time goes into waiting for data approval, fix the access process with the customer sponsor. If hands-on discovery and integration consistently unblock valuable work, use that evidence to define an FDE role.

Check capacity and deployment economics

For a vendor, include salary or contract cost, travel, management, shared engineering help, and post-launch support in the delivery estimate. Compare the effort with the revenue and retention the deployment can support. Keep revenue assumptions separate from results you have actually observed. A large contract can justify a demanding deployment, but a growing backlog of small custom accounts can overwhelm the same team.

For an SME or a portfolio company, compare the cost with the operational outcome: shorter queues, higher quality, avoided hiring, or a cash saving the business can realise. Estimated hours saved alone do not pay for an engagement. The process owner must say how the company will use the capacity and measure whether that happens.

Plan concurrency using observed effort. An engineer who owns a live rollout and its incidents may have little capacity for a second discovery project. Include review from security and core engineering, and protect time to document and generalise repeated work. Don't promise a fixed number of accounts per FDE before you know their deployment and support load.

Write the brief before opening the role

Write a short brief with the recurring deployment problem, the first workflow, customer or business owner, technical responsibilities, acceptance criteria, and receiving support team. Explain which decisions the engineer can make and who approves changes to the shared product. Include what you expect the second deployment to reuse from the first.

If the brief describes ongoing work across valuable deployments, a permanent hire may fit. If it describes a limited project, test a contract or partner engagement with a defined handover. If you cannot identify the blocked work or its owner, complete that discovery first. Once the need is clear, use our FDE hiring guide to assess candidates against the actual assignment.