Rise of the Forward Deployed Engineer

Why the role has exploded and is critical for today's GTM.

If you were forwarded this post, welcome to the GTM Engineering newsletter. Join 7,000+ GTM operators, founders, and investors. Hi, I’m Alex, one of the first GTM Engineers at Clay and here to share what I’m building for customers, how to build AI-native GTM, and resources for GTM Engineering.

---

AI Agents broke the SaaS delivery model.

a16z put it perfectly:

Enterprises buying AI are like your grandma getting an iPhone. They want to use it. They just need someone to set it up.

We see this at Clay, too. Customers need help to figure out how to take existing business context, workflows that aren’t well documented, and then integrate AI into it all.

That’s why Clay is building a Forward Deployed GTM Engineering team and we’re not alone.

Hundreds of companies from Salesforce to seed stage AI startups are hiring Forward Deployed Engineers. Job openings have ballooned this year (see chart below).

OpenAI even launched The OpenAI Deployment Company (aka DeployCo) to scale their implementations.

Google, too:

Why?

SaaS products are fairly straightforward.

AI products? Another story… there’s more complexity, customization (infinite?), and building solutions into companies existing workflows.

Current AI capabilities require significant customization to deliver reliable business outcomes. This is particularly evident in enterprise deployments where data variability is extreme, workflow complexity is high, and performance standards are unforgiving. Consider the difference between a consumer chatbot that provides “helpful” responses and an enterprise legal assistant that must flag compliance risks with 99%+ accuracy. - Foundation Capital

There’s a trend here in how AI is changing how companies develop an bring products to market.

• First - AI gives software engineers superpowers to 100x their output for software development.

• Next - The GTM Engineer role is born to rethink GTM with AI to bring products to market more effectively and to grow faster.

• Now - The final leg is getting AI into production.

That’s where the Forward Deployed Engineer (FDE) comes in.

Is the role just a glorified consultant with shiny name to attract talent & excitement?

This all led me down a research rabbit hole:

• What is the origin story of the FDE?

• How did it develop?

• Who’s hiring this new role?

• What are the ‘jobs to be done’?

• How much are they getting paid

• What are employees looking for in candidates?

• What does all of this mean for our new era of GTM?

These are all great questions to answer by sourcing and analyzing job data within Clay.

In this post, I aim to answer the above questions.

If you’re building in AI, you’ll want to read this deep dive.

Rise of the Forward Deployed Engineer

Software is no longer aiding the worker — software is the worker. Software doesn’t need the same graphical user interface on top of a database to operate; it can autonomously complete tasks end-to-end. But as those tasks get more complex, fulfilling them becomes more challenging. For AI agents to truly be on par with human workers, companies will need expert services to redesign job functions and processes around this new approach. Without hands-on implementation support, AI risks falling short of the standards set by a dedicated employee. With the right support, however, agents can take on a more holistic role, unlocking far greater business value than basic task automation ever could. - a16z

Origin story at Palantir

It started with a problem no one had solved before.

In September 2001, the US intelligence community had more data than it had ever collected in its history. It had analysts who were extraordinarily skilled at interpreting fragments of information. What it did not have was the ability to make those two things talk to each other. The CIA had its systems. The NSA had its systems. The FBI had its systems. None of them could see what the others were seeing.

Palantir was founded to solve that specific problem. But they ran into a wall immediately.

The founders faced a significant hurdle: they didn’t know any spies, and even if they did, those individuals couldn’t disclose the details of their work. There were no clear requirements, no proper feedback loops, no user interviews possible. Traditional product development was useless.

So Palantir did something unusual. Instead of asking customers what they wanted, it put engineers directly inside customer environments. These engineers learned by observing, experimenting and building in real time. That decision resulted in the forward-deployed engineer model. What began as a necessity later became a great strategy.

The name came from the military.

The phrase “forward deployed engineering” has its roots in military operations — forward-deployed forces — and Palantir popularized it in the late 2000s, largely because they were working with defense contractors and government agencies. They were already speaking the language of their customers. The title followed the culture.

The internal team structure was unusual.

Palantir didn’t send lone engineers into the field. They built a two-team model with distinct roles:

Echo teams were domain experts, often from the same industries as the customers — military, healthcare, or finance. Their role was to understand real problems, see where technology could create value, and serve as a bridge between the customer and engineering teams. Delta teams were execution-focused engineers who built solutions fast, prioritizing speed and impact over perfect design. Together they functioned as a mini startup within each client environment. Palantir’s own framing was precise: “A Dev’s focus is one capability for many customers, while a Delta’s focus is many capabilities for one customer.”

The feedback loop is how Foundry was born.

The FDE model had a mechanism that made it fundamentally different from consulting — what insiders called the “gravel road to paved highway” loop.

FDEs on-site lay down a “gravel road” with code and custom solutions to address immediate needs. Meanwhile, the product and engineering teams at headquarters observe this road and figure out how to upgrade it into a “paved highway” that can serve the next ten or twenty customers.

The core elements of what became Foundry were first developed in places as far-flung as Zurich and Houston, São Paulo and Toulouse, Westport and Baku. They were born of necessity, because small teams wanted to fix a problem, with cost, compatibility, or cohesion as only secondary concerns. Customer deployments were proving grounds for new technologies — those that worked were migrated toward the core, while FDEs fanned out in search of the next frontier problems. In 2014, at Palantir’s annual “Hobbitcon” conference, the stated product strategy was literally “strong opinions, weakly held” — basically throwing things at a wall and seeing what stuck. And this happened entirely bottoms-up.

The 4 waves of Forward Deployed Engineers

The FDE model didn’t go from Palantir to everywhere overnight. It moved in waves — each one triggered by the same underlying problem hitting a new sector.

Wave 1 (2003–2018): Just Palantir. Intelligence agencies with classified workflows, no clear requirements, and no way to do user interviews. You couldn’t ask the CIA what it needed. So Palantir put engineers inside and had them figure it out. The rest of the industry called it unscalable and moved on.

Wave 2 (2018–2022): Data infrastructure. Scale AI, C3.ai, Databricks, Snowflake. Complex deployments, large contracts, environments where a generic implementation was useless. You can’t produce useful training data without understanding the customer’s specific data architecture. You can’t deploy a data lakehouse without touching every legacy system in the org. The FDE model spread to anyone selling infrastructure that required judgment, not just configuration.

Wave 3 (2021–2024): Enterprise SaaS. Intercom, Rippling, Stripe, Datadog. These weren’t AI companies. They had well-documented products and large CS teams. Didn’t matter. Enterprise customers stopped buying point solutions and started demanding platform integrations. The implementation surface exploded faster than anyone could document it.

Wave 4 (2024–present): Everything. MIT found 95% of enterprise AI pilots return nothing. RAND puts AI project failure rates above 80%. The bottleneck isn’t the model. It’s the last mile — the legacy ETL, the undocumented workflow, the compliance constraint no one wrote down because the person who handled it never thought of it as a process.

Every wave happened for the same reason: a product hit a deployment problem so complex that no support ticket could solve it. The only fix was putting an engineer in the room.

AI just made that problem universal.

How is this panning out in 2026?

Chart: ‘26 Growth of US FDE Job Openings

I pulled job data in Clay for 2026 (this was a pull mid-May, so May numbers are likely even higher) and deduped by companies to find how many unique companies are hiring.

The actual number of open roles is much larger. For example, Salesforce alone has committed to hiring 1,000. Clay has multiple offerings.

Forward Deployed Engineering at Clay

Clay’s Forward Deployed GTMEs will be focused on:

• Translating business requirements to Clay builds

• Building Clay GTM systems

• Integrating Clay with internal tooling

• Bringing feedback from customers back to our product team

• Building agents & writing/tuning prompts

In Q1, I spent a large portion of my time forward deployed with a couple of customers. One even invited me to give a prompt engineering crash course to their entire marketing team. 100+ marketers showed up.

I went deeper with this customer, even spending an hour a day for several weeks supporting them. This was over top compared to what we normally do (especially since pre-sales usually disappears after the contract is closed and the Growth Strategist takes over as CSM.) The time investment accelerated everything:

• Strength of the customer relationship

• Deployment of Clay and their skills

• Introduction to more teams and stakeholders

• Understanding of their business & nuances

• Roadmap of new use cases to be deployed

Foundation Capital put it plainly: forward-deployed engineers have become “one of the most strategic assets in enterprise AI companies.”

What are Forward Deployed Engineers’ responsibilities?

In the same Clay table, I set up a Claygent column that takes the job posting URL as an input and then deploys the research agent to read & analyze each post. The output is a summary of responsibilities and requirements of the role. Then back to Sculptor to analyze all data in the table for a statistical analysis.

The most common responsibilities clustered around 3 motions.

Building customer-specific integrations

40% of postings. This is the nuts-and-bolts work — connecting the product to the customer’s data warehouse, CRM, identity provider, or the legacy system that hasn’t had an API since 2009.

Translating business requirements into technical architecture

30% of postings. The customer knows what outcome they want. They don’t know how to spec it. The FDE sits in the discovery call, hears “we want AI to handle our tier-1 support tickets,” and leaves with a technical architecture document.

Owning end-to-end delivery

25% of postings. Not handing off to a services team. Not filing a ticket. Shipping it, watching it break, fixing it, and making it stable enough to hand back.

Here’s why this is hard. Emergence Capital identified the core problem: most companies think they’ve documented their business logic in SOPs and process guides. But those documents are “corporate fiction: static, incomplete, and often wildly outdated.” AI systems need to internalize how work actually gets done — not the idealized version written in the wiki three years ago. FDEs extract that real-world knowledge directly, on-site, by watching and building.

FDEs contribute throughout the lifecycle of numerous organizations, including the initial evaluation and proof-of-concept phases up to the actual deployment and optimization. - FDE Academy

What are the job requirements for Forward Deployed Engineers?

40% of Forward Deployed Engineer job postings now require AI/LLM experience.

Eighteen months ago that number was near zero.

Traditional FDE job descriptions asked for Python, REST APIs, and cloud deployment experience. That’s still the baseline — 55% of postings require Python or TypeScript, 50% require REST API experience.

But 40% now require retrieval-augmented generation, prompt engineering in production, and debugging agentic workflows at customer sites. That’s a different job than integrating an API.

Joe Schmidt at a16z framed the shift precisely: in the current era:

Software is no longer aiding the worker — software IS the worker.

When that’s true, deploying software means deploying a worker. And you wouldn’t onboard a new employee with a Loom video and a support ticket.

Sarah Khalid, an FDE Director at Salesforce, described what’s changed technically: the agentic platform, she said, “is not quite as black-and-white as coding. It’s a little bit more art and not as deterministic.” That non-determinism is exactly why you need an engineer on-site. When the agent does something unexpected in a customer’s production environment, someone has to diagnose it in real time — not file a bug report.

This is why the FDE role is expanding so fast. Every company selling AI agents is discovering the same thing: the product can do what it says it can do. Getting it to do that inside the customer’s environment is a completely different problem.

How much do Forward Deployed Engineers get paid?

Minimum salaries range from $80K-$100K at the typical floor. Maximum salaries run $250K-$325K at the top of the market, with outliers reaching $400K at principal/staff level.

That’s a $170K gap between where the role starts and where it maxes out.

The reason: 60% of postings require 3-5 years of engineering experience. 45% require demonstrated customer-facing skills. That combination is genuinely scarce. You’re not hiring one discipline — you’re hiring two.

Salesforce’s hiring approach captures it well. Ben Kracker, FDE Director there, described what they actually look for: “problem-solving is the number one skill an FDE needs to have.” Not coding fluency. Not account management experience. Problem-solving — specifically in situations where the customer “does not know what they do not know.” That’s the judgment premium the salary gap is paying for.

Salesforce tripled its FDE team in six months and built a six-week onboarding program to support it.

What’s the difference between CSM, TAM, and FDE?

What this means for AI product GTM?

When every company can ship the same primitives using the same models, what you build is no longer your moat. How you integrate, embed, and operate becomes the moat. - Foundation Capital

Ramp’s engineering team, which built one of the most documented FDE functions in the market, found that enterprise-focused B2B companies grow at a CAGR of 29.6% vs 15.2% for non-enterprise peers. The FDE function is part of how you earn the right to be in that cohort — by deploying reliably enough that customers expand rather than churn.

If you’re a founder

The FDE function is not optional at enterprise. Budget for it before you feel the pain — by the time you feel it, you’ve already lost the renewal.

If you’re a GTM leader

Start mapping which accounts have deployment complexity that exceeds what your CSM can handle. Those are your FDE candidates. The metric is simple — if solving the customer’s problem requires writing code, your CSM isn’t the right person in the room.

If you’re an engineer

The FDE path is one of the highest-leverage roles in the current market. The $170K salary ceiling isn’t a ceiling for long — it’s a floor for the engineers who figure out how to do this at scale.

The companies that get to production fastest will win the renewal. Whoever deploys best, builds the moat.