What Is a Forward Deployed Engineer? And Why Growth Teams Are Borrowing the Model

Forward-deployed engineers are suddenly everywhere in AI. OpenAI is hiring them, Anthropic is building a dedicated FDE function, Google Cloud has been recruiting them across multiple markets, and Palantir, which pioneered the model, has been doing it for years.

A forward-deployed engineer is a software engineer who works directly with customers to turn real operational problems into working production systems. That may sound like a fairly small variation on a familiar engineering role, but forward-deployed engineering changes the distance between the people experiencing a problem and the people capable of solving it. Instead of separating discovery, strategy, engineering, deployment, and feedback across different teams, it puts much more of that responsibility in the hands of the same senior operators.

AI companies have embraced the model because powerful technology is relatively easy to demonstrate and much harder to make useful inside a real organization. The same structural problem appears outside engineering, too.

What is a forward-deployed engineer?

A forward-deployed engineer, or FDE, is a software engineer who works directly with customers to understand their problems, build and deploy solutions inside their real environment, and feed what they learn back into the wider product. You may also see the title “Forward Deployed Software Engineer,” or FDSE; companies use the term differently, so the responsibilities matter more than the exact wording.

In practice, a typical FDE might:

• Run technical discovery with a customer.
• Turn a vague business problem into something buildable.
• Design the system.
• Write production code.
• Connect APIs, internal data, and existing software.
• Build AI workflows or agents.
• Debug integrations.
• Deploy the resulting system.
• Measure whether people actually use it.
• Bring recurring problems back to Product and Engineering.

OpenAI describes its FDEs as owning the process from discovery and technical scoping through system design, development, and production rollout, with success measured in part by production adoption and workflow impact. The distinguishing feature, then, is not simply customer contact but a much greater degree of ownership.

Where did forward-deployed engineering come from?

The modern FDE role is most closely associated with Palantir, which sold software into difficult environments such as government, defense, finance, and industry, often to organizations dealing with large volumes of complex operational data. That creates a familiar enterprise software problem: the product may work perfectly well while the customer’s reality refuses to cooperate.

Useful data sits across several systems, permissions get in the way, processes have grown around old software, teams disagree about what they need, and requirements change once users finally see something working. There is only so much of that you can solve with documentation, onboarding calls, and another integration guide.

Palantir’s model put engineers much closer to the customer. They were not simply installers sent out to configure a finished product; they could start with an unclear business problem, investigate it with users, and build what was required. That changes who owns the gap between product capability and customer outcome.

Why are AI companies hiring forward-deployed engineers?

AI has made that gap much more visible. Foundation models are unusually general technologies, with the same underlying model potentially capable of analyzing legal documents, helping developers write software, supporting clinicians, automating customer service, or interpreting financial information. The more general the underlying technology becomes, the more work may be required to make it useful inside one specific organization.

An enterprise AI deployment therefore has to deal with a long list of practical constraints, including:

• Existing data and software.
• Authentication and permissions.
• Security requirements.
• Regulatory constraints.
• Legacy systems.
• Evaluation.
• Observability.
• Human approval.
• Organizational processes.
• People who may or may not want to change how they work.

A model can perform brilliantly in a demonstration and still fail completely as a production system, which is the deployment gap FDEs are increasingly being hired to close. Google’s GenAI FDE roles explicitly address issues such as integration complexity, data readiness, security boundaries, and the deployment of applications within customer environments.

OpenAI has gone further by hiring FDEs for specialist domains, including healthcare, legal work, and government. That hints at where the role may be heading, with engineering knowledge increasingly combined with deployment experience, domain expertise, and customer judgment. A brilliant engineer who does not understand the environment can still build the wrong thing.

What does a forward-deployed engineer actually do?

There is no universal FDE job description. Some roles resemble senior software engineering with much more customer contact, while others sit somewhere between engineering, consulting, product management, and solutions architecture. The title has spread faster than any standard definition, but the stronger roles tend to share five characteristics.

1. They discover the real problem

Customers rarely arrive with perfect specifications. ‘Build us an AI support agent’ sounds like a request, but it is not yet a specification: which conversations should it handle, what information can it access, what actions can it take, when must a person intervene, what happens when it is wrong, and what metric tells us whether any of this was worthwhile? The FDE helps turn the requested solution back into the underlying problem, then turns that problem into something buildable.

2. They work inside the real environment

Many good ideas fail once they meet the real environment. The engineer has to work with the customer’s actual infrastructure, data quality, internal systems, permissions, security policies, and undocumented processes rather than a clean description of them, and the solution has to work within those constraints.

3. They build

This separates strong FDE roles from many forms of traditional consulting. The engineer does not stop at a recommendation but writes code, configures systems, builds integrations, tests, debugs, and ships.

4. They own the outcome

Shipping something is not the same as solving the problem. A working deployment has to be adopted and create the intended result, which shifts the question from ‘Did we deliver what the customer asked for?’ to the more useful ‘Did this actually work?’

5. They bring what they learn back

This may be the most important part of forward deployment. A customer-specific problem should not remain customer-specific forever when other customers are likely to encounter the same thing, so strong FDE teams turn field experience into product features, reusable components, templates, documentation, playbooks, better defaults, and new product priorities.

The pattern is customer problem → custom solution → field learning → reusable capability → better product. Without that loop, forward deployment can become little more than expensive bespoke engineering.

Forward-deployed engineer vs. software engineer vs. solutions engineer vs. consultant

Job titles blur, and these distinctions vary considerably between companies, so the table below is best read as a comparison of typical operating models rather than a fixed definition of each role. A great solutions engineer might behave like an FDE, a good consultant may build alongside the client’s team, and some external teams operate more like internal departments than agencies. That leads to a more useful way of thinking about the trend.

Forward deployment is an operating model, not just a job title

Strip away the engineering terminology, and a clear operating pattern emerges. Senior people work close to the problem, have access to the real systems, and can diagnose and execute rather than passing one part of the work to another team.

They also see what happens after the work ships and remain accountable for the result, so lessons from one piece of work can change how the next problem is approached. Those principles are not restricted to engineering, and we see the same structural problem in growth.

What is forward-deployed growth?

We think of the equivalent model as forward-deployed growth: experienced growth operators working directly inside a company’s existing team, systems, and workflows, with enough access and ownership to identify problems, execute solutions, and learn from the results. That is different from simply calling an agency ’embedded,’ because joining a Slack workspace does not change much if the way work moves through the organization stays the same.

A conventional agency model can look something like this: Client → account manager → strategist → specialist → deliverable → client. Every handoff creates another opportunity to lose context, and the person doing the work may never speak directly with the person who best understands the problem.

That lost context shows up in practical ways. An SEO team may not know what Product plans to ship, a documentation team may keep explaining around a product problem that nobody has surfaced, and a writer may never see what customers actually ask. Paid acquisition can uncover a positioning issue that never reaches organic content, while Engineering can ship something that creates a search opportunity nobody notices until months later.

Modern growth does not divide itself neatly according to agency departments. SEO often touches engineering, content overlaps with product, documentation affects support and adoption, positioning affects sales, paid acquisition generates information that should influence messaging elsewhere, and analytics cuts across all of them. The more those functions depend on one another, the more expensive unnecessary handoffs become.

What forward-deployed growth looks like in practice

This is why the FDE model felt familiar to us. At ScaleMath, we already work as an embedded team in many client relationships, working inside content calendars, coordinating directly with engineering teams on technical changes, and handling technical work directly where access allows. The clearest evidence comes from what those relationships look like over time.

Rank Math

We worked with Rank Math as the WordPress SEO product grew from roughly 20,000 active sites to more than 3 million, before its acquisition by group.one. It would be misleading to point to one content tactic and claim that it caused that growth, and that is precisely the point.

A long-running growth relationship changes as the company changes. Search strategy, content, product education, positioning, documentation, and priorities move with it, so the work becomes something more useful than a queue of disconnected articles.

Patchstack

We worked with Patchstack from its pre-product-market-fit stage through the growth that preceded a $5 million Series A. The needs of a company still finding its market are very different from those of a funded cybersecurity business scaling acquisition, so the team working on growth needs enough context to recognize when the problem itself has changed.

LifterLMS

With LifterLMS, the work crosses SEO, product documentation, release content, technical changes, testing feedback, messaging, and direct conversations with the people working on the product. That proximity matters because a documentation problem can reveal a product problem, a release can create a search opportunity, and repeated customer confusion may expose a messaging issue.

A technical constraint can also change what an article should recommend. Those issues may belong to different departments on paper, but the customer experiences one product, so treating them as isolated problems rarely makes sense.

RunCloud

The same principle appears in documentation and content work for technical products such as RunCloud. You cannot produce accurate technical guidance from a keyword and a writing brief alone because you need to know what the product does now, what changed, where users will encounter it, and what they are actually trying to accomplish.

That is why our work increasingly spans growth, product, operations, and documentation rather than treating each as an isolated service. We combine technical SEO, content strategy, technical coordination, AI search, and product documentation instead of splitting them into separate silos.

The FDE model has a problem nobody should ignore

The current enthusiasm around forward-deployed engineering sometimes skips an uncomfortable question: what happens when every new customer requires another group of highly paid engineers? If the answer is simply to keep adding people, the company may not have solved the deployment problem at all. It may have built a consulting business disguised as a software company.

The pattern is easy to imagine. One customer needs a custom integration, the next needs another, and before long, critical knowledge lives inside individual engagements while revenue can only grow by adding more people. That is why the feedback loop is so important: good forward-deployed work should make repeated problems progressively less bespoke.

Today’s custom fix should be capable of becoming tomorrow’s feature, while an awkward process can become a playbook, and a discovery can become a better default. There is a useful paradox here: the best forward-deployed engineers should eventually reduce the need for forward-deployed engineering.

The same test applies to growth. An embedded team that keeps manually solving the same problem without improving the system around it is not creating an advantage. It is creating dependency.

How do you get the FDE outcome without building an FDE team?

The popularity of the model does not mean every company should start hiring people with ‘Forward Deployed’ in their title. The buyer-side question is more practical: how do you get senior people close enough to the problem to diagnose it, execute against it, and own the result? There are several ways to do that.

Hire internally

Hiring internally makes sense when the capability is permanent, strategically central, and large enough to justify a full-time team. The benefits are deep company knowledge, continuity, and direct control, but one hire rarely covers a cross-functional problem. A senior SEO hire, for example, does not automatically give you product marketing, documentation, paid acquisition, technical SEO, analytics, and content operations.

Hire a consultant

Consultants make sense when the main thing you lack is specialist judgment. They can diagnose the problem, challenge assumptions, and provide a plan, particularly when an internal team already exists to execute it. The weakness appears when strategy and execution become too disconnected.

Use a traditional agency

Agencies give companies access to a wider range of specialists without making several full-time hires. The model works well when the problem can be clearly scoped and the agency has enough context to do good work, but it becomes weaker when every decision must pass through several layers before reaching the person who can act.

Use an embedded external team

An embedded external team comes closest to the forward-deployed model when it includes senior personnel, operates within the company’s systems, speaks directly with those who understand the problem, and can execute rather than merely advise. That gives the company access to several areas of expertise without having to recruit each one separately, but the real test is not whether the provider calls itself embedded.

A few questions quickly reveal whether the model is genuinely embedded:

• Who will actually do the work?
• Will they have direct access to our team?
• Can they act on what they discover?
• Do they own results or deliverables?
• Will they see what happens after something ships?
• Does what they learn improve future work?

Those questions tell you more than the label.

Forward-deployed engineer jobs and salaries

The FDE boom has also created a large job-seeker market. These roles tend to skew senior because the work requires more than coding ability: engineers have to handle ambiguity, communicate with customers, make architectural decisions, and take responsibility for production deployments.

Current US listings show how highly some frontier AI companies value that combination. OpenAI has advertised general FDE positions with base compensation in the $162,000 to $280,000 range, plus equity. Anthropic has listed US FDE roles at $280,000 to $320,000, while senior Google GenAI FDE positions have advertised base salaries above $200,000 with bonus and equity on top. Those are examples from high-paying AI employers, not a reliable market-wide salary benchmark.

Job seekers will also encounter titles such as:

• Forward Deployed Engineer.
• Forward Deployed Software Engineer.
• Forward Deployed AI Engineer.
• Applied AI Engineer.
• Customer Engineer.
• Deployment Engineer.

Read the responsibilities rather than assuming the title has a standard meaning.

The more interesting part of the FDE boom

A forward-deployed engineer may eventually become another job title that expands until it means almost anything, but the operating model behind it is harder to dismiss. Companies are discovering that handoffs carry costs that rarely appear neatly in a reporting dashboard: context gets stripped away, feedback arrives late, individual teams optimize their part of the process, and nobody quite owns the final result. Forward deployment tries to reduce that distance.

It is not automatically better. Some problems need specialist advice rather than embedded execution, some businesses should build the capability internally, and a model that leaves customers permanently dependent on expensive human intervention has failed an important test. The useful principle is simpler: put experienced people close enough to the real problem to understand it, give them enough authority to act on what they learn, keep them accountable for the outcome, and make sure those lessons improve the system rather than disappearing when the project ends.

Palantir applied that principle to software, and AI companies are now applying it to model deployment. At ScaleMath, we apply the same thinking to growth, with senior operators working directly inside the systems and teams our clients already have across growth, product, operations, SEO, and documentation, rather than passing recommendations through a chain of disconnected specialists.

For companies that need the outcome of a senior embedded growth function without building every capability in-house, that is how we work at ScaleMath.

We work directly inside your existing systems and alongside your product, engineering, content, and growth teams, with senior operators handling strategy and execution across SEO, content, technical work, AI search, and documentation.

See how ScaleMath’s SEO consulting model works.

Frequently asked questions

What is a forward-deployed engineer?

A forward-deployed engineer is a software engineer who works directly with customers to understand operational problems, build and deploy technical solutions inside their real environment, and bring what they learn back to the company’s product and engineering teams.

What does forward deployed mean?

Forward deployed means placing technical people close to customers and real-world problems rather than keeping them entirely within a central product or engineering team.

What is a forward-deployed software engineer?

A forward-deployed software engineer, sometimes shortened to FDSE, is broadly the same type of role as an FDE. Companies use the titles differently, so the responsibilities matter more than the wording.

How is a forward-deployed engineer different from a software engineer?

Traditional software engineers usually focus on building a shared product or platform. Forward-deployed engineers spend more time working directly with individual customers and adapting or building systems around their environment and requirements.

How is a forward-deployed engineer different from a solutions engineer?

Solutions engineers often help customers evaluate, understand, architect, or adopt a product. Forward-deployed engineers tend to go further into hands-on production engineering and deployment. The boundary varies between companies.

Why are AI companies hiring forward-deployed engineers?

General-purpose AI models often require substantial work before they fit safely and reliably into an organization’s existing data, software, security rules, and workflows. Forward-deployed engineers help close the gap between model capability and a working production system.

Did Palantir invent the forward-deployed engineer role?

Palantir is widely associated with creating and popularizing the modern Forward Deployed Software Engineer model. Customer-facing engineering existed before the title, but Palantir made it a distinct part of how the company delivered its software.

What is a forward-deployed AI engineer?

A forward-deployed AI engineer applies the model specifically to AI systems. Their work can include model integrations, agents, retrieval systems, evaluations, data pipelines, security, observability, and production deployment.

How much does a forward-deployed engineer make?

Pay varies sharply by company, seniority, and location. Some current US roles at major AI companies offer base salaries above $200,000, often with equity or bonuses. Those figures represent the upper end of the market rather than a typical salary for every FDE.

Do companies need to hire forward-deployed engineers internally?

No. The broader goal is to put experienced people close to the problem, give them access to the systems and teams involved, and make them responsible for executing against what they discover. Depending on the problem, that can come from internal hires, consultants, or a senior embedded external team.