Why are forward deployed engineers suddenly everywhere?

Forward deployed engineers are showing up everywhere because software companies have rediscovered an uncomfortable fact: a powerful product does not create value until it works inside a customer's messy operation. AI made that gap wider. A model can impress a buyer in an hour, then spend months stuck behind data access, security review, unclear ownership, and a workflow nobody documented. The FDE owns the distance between the demo and dependable use.

That does not make the role a fashionable name for technical support. A good FDE writes production code, changes the product, challenges the customer's requested solution, and stays accountable for an operating result. A bad FDE becomes a highly paid source of permanent custom work. Founders who cannot tell those versions apart will add headcount, call it services revenue, and quietly damage their product margins.

An FDE owns the production outcome

A forward deployed engineer owns a customer deployment from discovery through stable operation. The exact work changes by account, but the accountability does not. The FDE finds the workflow worth changing, maps the systems and decision makers around it, builds the missing integration or application layer, gets it through review, ships it, measures adoption, and feeds reusable lessons back into the product.

OpenAI's current description of the role is unusually precise. It assigns the FDE discovery, technical scoping, system design, building, and production rollout. It measures success through production adoption, workflow impact, and evaluation feedback that changes product and model roadmaps. That last clause separates field engineering from project delivery. Shipping one customer's solution is only half the job; the deployment must also teach the company what to build once for everyone.

In practice, a week may include interviewing an operations lead, tracing an undocumented API, writing a data transform, negotiating an approval boundary with security, instrumenting an evaluation set, and telling a sales executive that the promised date is fiction. The role needs engineering depth because prototypes must survive real traffic and real failures. It needs product judgment because customers usually describe the interface they imagine, not the underlying constraint. It needs commercial judgment because every technical choice changes delivery cost and renewal odds.

The output is not code volume. It is a working change in customer behavior with evidence attached. For an AI support deployment, that evidence might be the share of eligible conversations handled, escalation quality, incorrect-action rate, latency, and the named person who can pause the rollout. For a payments integration, it might be successful transaction paths, reconciliation exceptions, operational ownership, and recovery time after a failed event. If nobody agrees on the operational measure, the FDE is still doing discovery, regardless of how much code exists.

AI widened the last-mile gap

The role exploded because modern AI products are general enough to look finished before the hard work begins. Traditional SaaS usually exposed a bounded set of screens and APIs. Buyers adapted their process to the software. AI systems can touch many workflows, interpret unstructured data, and produce variable results. That flexibility creates more possible value and more ways to fail.

A conventional integration asks whether the request reached the correct endpoint and returned the expected schema. An AI deployment also asks whether the answer was acceptable, whether the model used the right evidence, whether a tool action was permitted, whether an escalation carried enough context, and whether a changed model altered behavior. These are operational questions, not API questions. They sit across product, engineering, security, legal, and the customer's domain team. Someone must hold the whole thread.

OpenAI's managed deployment guidance for its agent products describes simulations and evaluations, permissions and approval steps, action histories, human escalation paths, controlled rollout, monitoring, and rollback. That list explains why a polished prototype does not remove deployment work. The prototype proves that a path exists. The controls prove that an organization can use it repeatedly without betting the business on every model response.

Buying behavior changed too. Large customers no longer want another broad AI workshop followed by a deck. They want a production workflow and an accountable technical owner. Meanwhile, product teams cannot learn the hardest requirements from analytics alone because the missing context lives in customer policies, old systems, and exception handling. Embedding an engineer shortens that learning loop.

The title spread because the economic need spread. Palantir used the model long before the current AI wave, and its career material draws a clean boundary: product software engineers work in product development, while forward deployed engineers sit closer to business development and own technical and operational customer outcomes. Now OpenAI, Anthropic, Stripe, and many younger companies advertise variants of the role. The common pressure is not fashion. It is the cost of getting adaptable software across the last mile into production.

The title is not a synonym for solutions engineering

An FDE differs from a solutions engineer, implementation consultant, customer success manager, and staff product engineer by what they build and what they own. Companies blur these jobs because one capable person may cover several of them early on. The blur becomes expensive when leadership applies the wrong goals and capacity assumptions.

A solutions engineer usually helps win the deal. They demonstrate the product, validate architecture, answer technical objections, and may build a proof of concept. Their main clock runs toward a commercial decision. An FDE's clock continues through deployment and adoption. If the proof works but the production workflow fails, the FDE still owns the problem.

An implementation consultant configures a known product and process. Good consultants handle change management and integrations, but the delivery normally follows an established scope. An FDE enters where the product, workflow, or technical path remains uncertain. They can modify production software and should turn repeated customer work into product primitives. Stripe describes its new FDE group as an evolution of professional services that directly builds and delivers software for users. That wording matters: the engineer does not stop at advice.

Customer success owns the relationship, adoption plan, and ongoing value, but normally does not design and ship the missing system. A staff product engineer can build that system, yet often lacks direct authority inside the customer account and may optimize for the general roadmap before understanding the local failure. The FDE crosses the boundary and then brings the lesson home.

Use a simple ownership test. Ask who can change production code, who can negotiate workflow scope with the customer, who remains responsible after launch, and who must extract a reusable product change. If the answers point to four different people with no single owner, the company does not have an FDE function. It has a handoff chain. Handoffs are sometimes necessary, but calling the chain forward deployed engineering does not remove the gaps.

Custom work must earn its way into the product

The dangerous advice is to give strategic customers whatever engineering they request. It feels customer obsessed, pulls revenue forward, and gives the team concrete tasks. It also turns a product company into an agency one exception at a time. An FDE should accept local work only when it advances a repeatable capability, enables a clearly priced account, or teaches the company something important enough to justify the cost.

I use three buckets for field work. Product work belongs in the core because many customers need it. Accelerator work is reusable deployment code, such as a connector template, evaluation harness, migration tool, or policy adapter. Bespoke work serves one customer's process and is unlikely to travel. All three can be legitimate, but they need different owners, pricing, and expiration rules. Hiding bespoke work in the product backlog corrupts roadmap decisions. Giving product work away as services hides demand.

Set a reuse review before accepting a build. The FDE and product owner should name the stable primitive underneath the request. A customer may ask for a special claims-review screen, while the reusable need is a configurable human approval queue with role-based routing and an audit record. Build the primitive when several plausible accounts share it. Keep the local presentation thin.

Then set a deletion date. Temporary adapters accumulate because they work well enough and nobody owns removal. Record the customer, repository, production owner, support expectation, replacement condition, and date for the next review. Code with no owner after the engagement is a liability, even if it helped close the quarter.

The field team also needs permission to say no. A request should fail the test when it creates a permanent fork, bypasses a safety boundary, depends on undocumented manual work, or consumes more engineering capacity than the account can repay. Strategic logo is not a technical category. If executives override the refusal, show the exception as an explicit investment with a budget. Do not bury it in the FDE team's utilization.

Hire only when the pattern is visible

A startup needs its first dedicated FDE when customer-specific production work is both blocking meaningful revenue and producing a repeatable pattern. Hiring before that point gives an engineer a vague mission and encourages random acts of helpfulness. Hiring after it leaves founders and core product engineers trapped in deployments, with roadmap work constantly interrupted.

Look for evidence across recent deals, not one loud prospect. The signal is strong when several customers share a common workflow but need different data sources, permissions, or operating rules; when pilots succeed technically but stall before production; when the founder or CTO spends a large, persistent share of the week inside customer systems; and when product managers cannot separate missing product capability from local implementation work.

Do not hire an FDE to repair a product nobody wants. If customers disagree on the basic problem, field engineers will produce unrelated projects rather than a learning loop. Do not hire one because enterprise buyers expect white-glove treatment. A strong implementation partner or solutions engineer may cover a known setup more cheaply. Do not create the role merely to rescue promises sales made without technical review. Fix deal governance first.

The first FDE should usually be a senior generalist who can ship across the stack and hold a difficult customer conversation. Raw coding speed is insufficient. They must reduce an ambiguous request to a smaller production outcome, identify which risk matters, write maintainable code under time pressure, and document the pattern for the next engineer. I would rather hire someone who has operated a system they built than someone whose portfolio contains many polished prototypes.

Give the role an executive sponsor and a product counterpart before opening the position. Decide whether it reports to engineering, product, or a customer organization based on where decisions can actually be made. Reporting lines matter less than operating rights: access to the roadmap, authority to reject unsafe scope, a path to deploy code, and a rule for allocating work. Without those, the FDE becomes a courier carrying unresolved demands between teams.

Interview the candidate with a live scoping exercise, not a coding puzzle. Give them a messy customer request, a partial architecture, and a deadline. Watch whether they identify the decision owner, ask for production evidence, narrow the first release, and expose assumptions before proposing technology. Then review code from a system they operated and ask about a failure after launch. Strong candidates can explain what they removed, how they measured adoption, and which local lesson became a product change. Include a customer-facing conversation in the loop. Charm alone is not enough, but an engineer who cannot disagree clearly with a buyer will either overpromise or retreat behind the account manager.

A deployment charter prevents accidental consulting

Every engagement should begin with a one-page deployment charter that names the business result, production boundary, reusable hypothesis, evidence, and exit. This is not project-management ceremony. It stops a paid prototype from drifting into an endless queue of customer requests.

The following YAML is a compact version I would require before committing engineering time. A startup can keep it in the account repository and review changes in the same way it reviews code.

account: northwind
workflow: invoice-exception-routing
owner_customer: finance-operations
owner_vendor: fde-name
outcome:
  metric: median-resolution-hours
  baseline: 31
  target: 12
production_boundary:
  may_read: [invoice, purchase-order, vendor-record]
  may_write: [exception-queue]
  requires_human_approval: [payment-change, vendor-change]
reusable_hypothesis: configurable-approval-routing
exit:
  customer_runbook_owner: operations-lead
  support_tier: standard
  review_date: 2026-10-15

The names and numbers must come from the engagement, not from a template. The failure this file prevents is easy to recognize. Sales calls the work an invoice agent. Engineering thinks it is a read-only recommendation tool. Finance expects it to change payments. Nobody defines success, so a demo that handles five clean invoices becomes a production promise. The charter forces the disagreement into the open while the scope is still cheap to change.

Run delivery through four gates. First, reproduce the current workflow with representative exceptions, not a happy-path sample. Second, agree on the smallest production boundary and the person who can approve it. Third, release to a constrained group with observable success and failure measures. Fourth, transfer routine operation to a named customer owner while the FDE extracts reusable code and product decisions.

A gate can fail without the engagement failing. Discovering that the customer lacks usable source data may save both sides months. Discovering that no executive owns the workflow means adoption work should stop before more software gets built. An FDE earns trust by exposing those facts early, not by keeping everybody busy.

Services revenue changes the product economics

FDE work can create high-quality services revenue, but founders should not confuse revenue quality with gross margin percentage alone. The work may accelerate subscription revenue, reduce churn, create product IP, and open a segment the existing product cannot reach. It may also absorb scarce engineers, add support obligations, and disguise a product gap. The accounting needs to show both sides.

Track each engagement as a small economic unit. Record contracted services revenue, loaded delivery cost, travel and outside costs, the subscription revenue enabled, expected ongoing support, and reusable assets produced. Do not assign imaginary value to learning. Name the resulting connector, product requirement, evaluation set, or playbook. If the asset cannot be identified and used again, count its value as zero until that changes.

Consider a twelve-week deployment sold for $180,000. Two FDEs each spend half their capacity, and their loaded quarterly cost is $75,000 each. Direct delivery labor is therefore $75,000. Add $15,000 for travel, security review support, and specialist time. The engagement contributes $90,000 before overhead, a 50 percent contribution margin. That sounds healthy.

Now include capacity. If the same two engineers could support two smaller deployments using a common connector, the bespoke engagement has an opportunity cost that the project margin misses. On the other hand, if the work enables a $300,000 annual subscription and produces that common connector, accepting a lower services margin may be rational. The decision depends on attach and reuse, not on whether finance labels the invoice professional services.

Keep services and subscription lines separate in reporting, then connect them with cohort measures. Watch time to production, services revenue per delivery week, contribution margin, subscription attach, renewal of deployed accounts, support hours after handoff, and reuse of field-built assets. A blended top-line number lets profitable software conceal unprofitable custom work. A services margin target by itself can push FDEs to avoid the difficult deployments that would improve the product.

This model changes revenue timing as well. Paid discovery and deployment bring cash earlier than a fully mature product contract, but milestones create delivery risk. Recognize revenue according to the actual contract and accounting policy, not internal optimism. Operationally, never spend recurring subscription revenue as if it were secured when production acceptance still depends on unfinished custom work.

Price the uncertainty instead of hiding it

The cleanest commercial model separates discovery, deployment, and ongoing software. Customers should know which result they are buying, what remains uncertain, who owns the delivered code, and what support continues after handoff. A single fixed fee for an undefined transformation invites both sides to behave badly. The customer keeps adding scope, while the vendor protects margin by declaring partial work complete.

Start uncertain accounts with paid discovery that ends in an executable deployment plan, a production boundary, a risk register, and a go or no-go decision. This is not a generic workshop. The customer receives artifacts that another qualified team could use. Credit some or all of the fee toward deployment only when that commercial choice improves commitment; do not make technical discovery free because sales wants momentum.

Price deployment against a bounded outcome and explicit assumptions. Use milestone payments for access, constrained release, production acceptance, and handoff. Add change control for new systems, regions, workflows, or compliance requirements. Time and materials is honest when the customer controls much of the uncertainty. A fixed price works when the vendor controls scope and has delivered the pattern before.

Subscription pricing should pay for the continuing product, not quietly fund unlimited engineering. If ongoing field capacity is part of the offer, state the capacity, response expectations, and eligible work. Retainers can work for a changing portfolio of deployments, but review them against outcomes and asset reuse. Otherwise the FDE becomes rented staff with a product logo on the invoice.

This is also where a smaller startup can compete. It cannot place five engineers at every account, but it can package a narrow outcome, use AI tools to compress implementation work, and keep a senior technical owner close to the buyer. On oleg.is, the Team & AI Audit uses a fixed five-business-day scope to identify engineering savings before a broader transformation. The same sequencing principle applies to FDE work: sell a bounded diagnosis before promising an open-ended deployment.

A bad deployment fails after the demo

The common failure starts with a successful prototype. An enterprise operations team gives the vendor a clean export and twenty representative records. One engineer builds an assistant that classifies the records and drafts actions. The sponsor sees the demo, sales announces a production date, and the startup assigns an FDE to finish the integration.

The real system then introduces three problems the prototype hid. Historical records use inconsistent identifiers. A write action can trigger a regulated customer communication. The operations team handles rare exceptions through an unwritten conversation with legal. The FDE patches identifiers, adds a confirmation screen, and creates a special rule for each exception. Progress looks fast because every weekly demo gains a feature.

After launch, adoption stops. Operators do not trust the classifications because the evaluation set excluded hard cases. They still copy every answer into the old process because nobody approved the new record as authoritative. Support messages reach the FDE directly, so product engineering never sees the pattern. The account technically runs in production, but it has doubled labor and created a private software branch.

The first mistake was not model quality. The team accepted a demo dataset without mapping the operating decision and its exceptions. The second mistake was treating human approval as an interface element rather than an ownership rule. The third was allowing the FDE to absorb product feedback inside account work. Better prompting cannot fix any of those.

Recovery requires reducing scope. Make the system read-only for one well-defined class of records. Build an evaluation set from disputed and rare cases, then publish pass and escalation criteria. Name the system of record and the person authorized to change it. Route recurring support through the product backlog. Delete local rules that do not protect a documented policy. The revised deployment may look less impressive, but it can replace work instead of adding another layer to it.

Founders often resist this reset because it feels like retreating in front of a strategic customer. Continuing the fiction costs more. A narrow workflow with measured adoption can expand. A broad workflow that operators bypass creates support debt and weakens the renewal conversation every week it remains live.

The field loop must change the roadmap

An FDE team compounds only when field evidence changes product priorities, packaging, and delivery methods. Without that loop, each deployment begins from zero and senior engineers become the limiting factor in revenue. The fix is an operating cadence with decisions, not a larger library of account notes.

Require a short field review with product and engineering after each meaningful release. Bring the failed evaluation cases, time spent by work category, requested capabilities, local code, adoption evidence, and unresolved support burden. Decide which change enters the product, which artifact becomes an accelerator, which local code remains funded by the account, and which request gets rejected. Give every accepted item an owner and date.

Measure reuse by observed use. A connector copied into a second deployment counts. A slide describing a possible framework does not. Track how delivery time changes for the second and third account in the same pattern. If it does not fall, inspect the supposed common layer. The team may have grouped customers by industry while their workflows, data, or decision rights remain different.

Protect product engineers from constant account interruption, but do not isolate them from customers. Pair them with FDEs at the moments where architecture or roadmap decisions occur. Rotate selectively, not as a permanent staffing patch. The field engineer supplies context and urgency; the product engineer protects coherence. Either side working alone tends to overfit its own incentives.

AI coding tools can reduce the cost of adapters, tests, migration scripts, and documentation. They do not decide whether a workflow deserves automation or who accepts the operational risk. I have run an AI-augmented engineering operation with two engineers where a much larger team once worked, and the gain came from changing ownership and delivery flow as much as from generating code. A fractional CTO can establish that system when a founder needs the capability before a full FDE organization makes sense.

Do not promote the role by counting deployments or billable utilization. Reward production outcomes, clean handoffs, reusable assets, and product changes supported by field evidence. The strongest signal is boring: each new customer in a known pattern reaches stable use with less custom code and less senior attention than the previous one. If that curve does not improve, the company has built a consulting bench, whatever title appears on the org chart.