What is a forward deployed engineer?

The short definition

A forward deployed engineer (FDE) is an engineer, employed by a product company, who works with a customer and often inside the customer's organization to get that product working on the customer's real problems. The FDE configures, extends and integrates the product, writes code where it falls short, and stays until it runs in production and the customer's own people can use it.

Three traits set the role apart from other software engineering:

• One customer at a time. The work is shaped by a single organization's goals, data and constraints.
• The customer's environment. The code runs on the customer's systems, against the customer's data, under the customer's security and approval rules.
• Use as the measure. Success is a deployment that people rely on, not a feature that shipped.

The label now covers a wider family of jobs, including deployment engineer and, at some employers, forward deployed strategist. The glossary separates the terms. This guide is about the core engineering role.

Where the term and the role came from

“Forward deployed” is military language for forces positioned near where they are needed instead of at a home base (see an encyclopedia entry on forward-basing). Software borrowed the phrase for staff who go to the customer rather than waiting for the customer to come to them.

The role is most closely tied to a data-analytics software company founded in the early 2000s. In the usual telling, its product was powerful, but customers such as government agencies, with fragmented data and little in-house capacity to integrate it, could not turn it into working systems alone. The company's answer was to put its own engineers next to the customer to do that work.

Inside that company the engineers were called Deltas. Its engineering blog says the name goes back to the early days, when each business development team was named after a letter of the NATO alphabet. The same post set out the contrast that still defines the role: product engineers build one capability for many customers, while a forward deployed engineer works on “one customer, many capabilities.”

Accounts differ on when the title itself was formalized. Published histories place it between the late 2000s and the early 2010s, and the practice is older than the label. One widely read engineering newsletter reports that for years the company employed more of these engineers than product engineers (The Pragmatic Engineer, August 2025).

Since then the title has spread. Enterprise software vendors built their own versions, and more recently AI model developers, AI application startups and startups in sectors such as healthcare and industry have recruited for it. A venture investor's essay gives the logic for AI products: complex workflows need deep integration with a customer's own systems, which self-serve onboarding rarely covers (Trading Margin for Moat, June 2025).

What the work actually is

The work follows the customer's problem, not a fixed job description. In most accounts it runs as a loop:

1. Understand the problem. Sit with the people who do the work, find the decision or process that matters and agree what “working” means.
2. Get access to the data and systems. Connect sources, handle permissions and security reviews, and deal with messy records. This is often the slowest step.
3. Build the smallest useful version. Configure the product, write the connecting code and put something in front of a real user.
4. Deploy to production. Move from trial to live use, with monitoring, support and a way back if something fails.
5. Hand over and train. Leave documentation, operating guides and trained people, so the customer can run and change the system without you.
6. Feed back. Tell the product team what was missing and which custom pieces should become product features.

A typical mix of activities

No two weeks look the same. Practitioners' published accounts describe weeks that swing between building and scoping what comes next. Across an engagement you would expect some mix of:

• writing and reviewing code and configuration;
• profiling, cleaning and mapping data from several sources;
• workshops, demos and working sessions with the people who will use the result;
• scoping the next piece of work and negotiating what is in and out;
• writing documentation and operating guides;
• responding when something breaks in production;
• reporting progress and risks to the customer's sponsor and to your own management.

Where the work happens

Usually in the customer's cloud accounts, data platforms and internal tools, which is why security and access come up so early. Arrangements range from frequent time on customer sites to mostly remote work. Ask which applies to the role in front of you.

What success looks like

Usage, not delivery. A pilot that never reaches daily use has not succeeded, however clean the code. Good teams agree the measure at the start: a decision made faster, a manual process retired, a report that people open every week.

How it differs from neighboring roles

Titles overlap and employers use them differently, so treat this table as a map of tendencies. An encyclopedia entry on the role notes the overlap with solutions architects, sales engineers, systems integrators and IT consultants (entry). When a posting says forward deployed engineer, check where the code runs, how long the work lasts and whether you would be expected to change the product.

Against a solutions engineer

A solutions engineer tends to show that something is possible. A forward deployed engineer tends to make it work in production and own it afterward. One industry newsletter describes solutions architects as building prototypes on anonymized data, while forward deployed engineers write code on the customer's own infrastructure.

Against a product software engineer

A product engineer optimizes for many customers at once and rarely sees one deployment end to end. An FDE optimizes for one customer and sees everything that goes wrong. The best arrangements close the loop: what the FDE learns changes the product.

Against a consultant

A consultant usually advises, produces a deliverable and leaves. An FDE builds and runs something inside the customer's systems using the employer's own product. How that model compares with consulting, software and managed services is the subject of a separate guide.

Who hires forward deployed engineers

This is not a complete list, but the pattern is consistent. The role appears where a product is complex, the customer's data and processes are messy, and each contract is large enough to justify a dedicated engineer.

• Data and analytics platform companies, where the role began.
• Enterprise software vendors selling to large organizations.
• AI model developers and AI application startups, whose products need to connect to a customer's systems and workflows.
• Startups in operationally complex sectors, such as healthcare, industry and financial services.
• Companies that sell to government and defense, where deployments run inside tightly controlled environments.

Seniority requirements vary widely. Some employers hire recent graduates and train them; others look for several years of experience shipping software. Pay varies by employer, level and location, and published figures are rarely comparable, so this guide gives none.

The skills the role takes

Technical

• Programming in a general-purpose language, and comfort reading other people's code.
• Data skills: SQL, schemas, pipelines and a feel for data quality.
• APIs, integration patterns and authentication.
• Cloud and deployment basics: environments, logging, monitoring and access control.
• Security and privacy habits: least privilege, careful handling of customer data, working inside the customer's controls.

Judgment and communication

• Decomposition: turning a vague business goal into a sequence of small, testable steps.
• Scoping: deciding what to build first and saying no to the rest, politely.
• Translation: explaining trade-offs to non-technical sponsors and technical constraints to executives.
• Stakeholder sense: knowing who the champion is, who can block the work and who simply needs to be kept informed.
• Ownership under ambiguity: moving forward without a full specification and being straight about what is still unknown.
• Fast domain learning: picking up a customer's vocabulary and constraints quickly enough to be useful in the first few sessions.

Employers can usually teach the product. Judgment is harder to teach, which is why interviews test it; see the interview guide.

Costs and criticisms

For engineers, the role suits people who like variety and visible results. It tires some: the same encyclopedia entry notes that some engineers view it negatively because of travel and the pressure to solve customer problems on tight timelines. Context switching between customers is real, and so is carrying a customer's urgency.

For employers, a services-heavy model usually means lower margins than selling software alone. The venture essay cited above argues the trade can be worth making, and also acknowledges the risks: services work limits scalability and can turn a product company into something closer to a consultancy. The practical test is whether each deployment makes the next one cheaper. The business-model questions are covered in the comparison guide.

A third way: your own people

Our view. The sections above describe the role as it is usually practiced. This section describes the approach we take and sell, so read it as one view, not settled fact.

Everything above assumes the forward deployed person comes from outside. A company with a hard deployment can seem to have two choices: bring outsiders in, or leave its own people to work it out with a tool. There is a third: treat the people already on your payroll as the forward deployed.

The role's own definition points the same way: sit with the people who do the work, understand the problem, get something useful running and hand it over. The people closest to a company's problems are its frontline employees and leaders. They already know the customers, the exceptions and the constraints, which an outside engineer must learn fast, and they are still there when a project ends.

What your people need to go forward

Insiders usually lack three things an outside team brings:

• Capacity. The analysis, drafting and modeling that would take days of their own time, done for them.
• Method. The structure an experienced team would apply: a scoped question, cited sources, recorded assumptions.
• Experts on call. A specialist for the decision or signature that needs one, for the time it takes rather than a whole engagement.

Why it matters for handover

The role's last step is handover, so the customer can run and change the result without you. With your own people as the forward deployed, that step is built in. Part of what a team learns by doing the work is tacit knowledge: know-how that is hard to write down or pass on. Keeping the work in-house is one way to keep that learning, which is the aim of organizational learning: creating, retaining and transferring knowledge within an organization.

Where it does not fit

• It suits knowledge work you can describe, review and act on in your own tools, such as research, analysis, models and documents. It does not replace the engineers a software integration needs, whether they are yours or a vendor's.
• It asks something of your people: time, and a willingness to lead the work instead of handing it over.
• Where the law requires a licensed professional to sign, a person must still sign.

The comparison guide sets this beside consulting, software and managed services, and the about page explains how we put it into practice.

Frequently asked questions

Sources and further reading

Sources are linked so you can check them. Statements that vary by employer, or that accounts disagree about, are hedged in the text. Found a mistake? Email support@forwardeployed.work and we will correct the page and update its date.

1. What are Forward Deployed Engineers, and why are they so in demand?. Gergely Orosz, The Pragmatic Engineer, 12 August 2025.
2. Dev versus Delta: Demystifying engineering roles. Engineering blog of the company that created the role.
3. A day in the life of a forward deployed software engineer. The same engineering blog.
4. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups. Joe Schmidt, a venture investor's essay, 4 June 2025.
5. Forward-deployed Job Titles. Tom Hollands, a venture investor's essay, 27 January 2026.
6. Forward Deployed Engineer. Encyclopedia entry.
7. Forward-basing. Encyclopedia entry, for the military sense of the phrase.
8. Solutions architect. Encyclopedia entry.
9. Tacit knowledge. Encyclopedia entry, for knowledge that is hard to put into words or hand over.
10. Organizational learning. Encyclopedia entry, for how knowledge is created, kept and passed on inside an organization.