The title is new. Half the job isn't.
TL;DR
- The FDE job is mostly customer work. In Bloomberry's analysis of about 1,000 FDE postings, "working directly with customers" was the top responsibility (55%), ahead of building AI systems (37%).
- Five things really are different from the SE role: timing, output, pay structure, reporting line and account load.
- The work in the middle is the same job. Discovery, stakeholder management, scoping and executive communication decide whether an FDE engagement succeeds. A typical engineering career teaches none of them.
- The documented FDE failures are rarely engineering failures. They come from data access nobody secured, success criteria nobody agreed and requirements nobody questioned.
- No quota doesn't mean no commercial job. Under consumption pricing, adoption is revenue.
A company buys an 8-to-12-week pilot. The engineers show up. Then, as former Palantir FDE Nabeel Qureshi put it in his essay Reflections on Palantir, the team spends "all eight to 12 weeks just getting data access" and the last week scrambling to have something to demo.
If you've ever run a proof of concept, you know that story. You've probably lived it. It's also a good way into the question every SE leader keeps hearing this year. OpenAI is hiring forward deployed engineers by the dozen. Anthropic and Databricks have them too, and Palantir has used the title for about 15 years. So in every SE Slack and at every leader dinner, two questions come up: is this just our job with a new name and a bigger salary? And what do these people actually need to be good at?
Short answer: partly, and more than the job postings admit. This article lays out where FDEs and SEs really differ, where they do the same work, why FDE engagements fail, and what you should train for if you're building an FDE team (or an SE team, for that matter).
What does a forward deployed engineer actually do?
An FDE spends roughly half the week building and half in front of customers. The customer half matters more than the title suggests. One practitioner writing on FDE Hub summed up his own week as 50% meetings, 50% building. His conclusion was that the job is less about building AI systems and more about understanding businesses well enough to know what to build.
One person's week is an anecdote, but the posting data tells the same story. Bloomberry analyzed about 1,000 FDE job postings (summarized by Underdog.io). The number one responsibility was "working directly with customers," named in 55% of postings. Building AI systems came in at 37% and integrations at 32%. The most-requested soft skill was customer-facing ability, at 47%.
Those same postings list years of engineering experience and a long tech stack as the hard requirements. Tim's hypothesis is that what companies screen for, what the job consists of and what makes an FDE successful are three different things.
If you split the work, you get two halves. The engineering half covers production code in the customer's environment, integrations, data pipelines, architecture, and debugging infrastructure you've never seen before. If you can't do that, you're not an FDE. The customer half breaks down into tasks any SE will recognize:
- Discovery: getting from what the customer says they want to what's actually blocking them, and then to a number they care about. Anthropic's posting asks FDEs to "conduct discovery with customers." It never defines what that means.
- Stakeholder management: who decides, who blocks, who owns the data. Postings hide all of this behind the word "customer-facing."
- Expectation and scope management: presenting progress to a sponsor, or explaining a technical failure to a non-technical VP without losing the room. Postings call this "strong communication skills."
- Commercial awareness: knowing that adoption is what the customer pays for and where expansion comes from. Postings almost never state it, but companies very often measure it.
The Bloomberry author's bar for the customer half: if you can't explain to a non-technical VP why their AI agent keeps failing "without making them feel stupid, you won't succeed."
How is a forward deployed engineer different from a solutions engineer?
They differ in five ways: timing, output, pay, reporting line and account load. The differences are real, and SE leaders should be honest about them.
Timing. The SE works before the contract: qualification, discovery, demo, POC, technical win. The FDE mostly works after it, on deployment, integration and production rollout. Some FDE teams start earlier, OpenAI's and Anthropic's among them. Tim recently saw an Anthropic posting titled "Program Lead, Pre-Sales Forward Deployed Engineering." Still, the center of gravity is clear: SEs come in before the signature, FDEs after it.
Output. The SE produces proof: a demo, a POC on the customer's data, the technical part of the proposal, the business case. The FDE produces working software that runs in the customer's systems, and ideally patterns that flow back to the product team. That's why some companies put FDEs inside product management. Daniel Porras Reyes, an investor at Flybridge, draws the line precisely: the FDE ships production-grade code directly into the customer's live environment. SEs typically don't.
Pay. Most SEs earn a base plus variable pay, often around a 70/30 split, tied to a team or territory target. FDEs earn a base plus equity, sometimes with a bonus. In Bloomberry's sample, the share of FDE roles carrying a quota was 0%.
Reporting line. At most companies, SEs report into sales. FDEs report into a dedicated FDE team in 45% of cases, into engineering in 38%, and into sales or go-to-market in only 14%.
Account load. A typical SE supports 3–5 account executives, and 20–30 deals a quarter is normal at the enterprise end. An FDE at Palantir or OpenAI goes deep on one or two customers at a time. At a startup it might be up to 10. Palantir plans for about a quarter of an FDE's time on site, and some companies go up to half. The model is depth, not breadth.
The two roles differ on the edges. The middle column decides whether either one succeeds.
How do you tell a real FDE role from a rebranded SE role?
Ask three questions. Does the manager report to sales? That's Bloomberry's test. Tim adds two more: is pay tied to sales targets, and does the role start before the contract? If you get two or three yeses, you're most likely reading an SE posting with a fashionable title.
So is it a rebrand? Sometimes, yes. Andreessen Horowitz has called it title arbitrage for roles that used to be called solutions or integration engineers. Most SE leaders we work with see it as a well-paid rebrand of work that presales and professional services already do. The pattern itself, vendor engineers embedded in customer organizations, is decades old: IBM did it first and SAP perfected it. KDnuggets asks the same question from the engineering side. The FDE is a different job where production code becomes product. Where it doesn't, it's an SE with a different name and a higher base.
The overlap is more interesting than the differences. Both roles run discovery. OpenAI's posting has the FDE "own discovery, technical scoping, system design, build and production rollout," with discovery first in the list. Both manage stakeholders. Qureshi wrote that success at Palantir required "an unusual sensitivity to social context" and winning the trust of counterparts at the highest level. That's a trusted advisor's job, not an engineering skill.
Both roles also hire from the same pool. In Bloomberry's data, 22% of FDEs came from solutions engineer or solutions architect roles and another 10% from technical consulting. Anthropic asks for a technical, customer-facing background. Databricks describes its FDEs as engineers with strong leadership and consulting skills. Companies hiring FDEs want engineers who can do the SE's job, whether or not the posting says so.
Why do FDE engagements fail?
Mostly for reasons that have nothing to do with engineering. The documented failures follow two paths.
The stalled pilot. This is the Palantir story from the opening. The pilot is sold and the FDE arrives. The data owner won't grant access, and weeks disappear into internal politics. The final week is a demo scramble, and nothing reaches production. Look at what actually went wrong:
- The data owner who won't grant access is a stakeholder problem.
- The success criteria nobody agreed at the start are a scoping problem.
- The sponsor who lost interest by week six is an expectation problem.
Better engineering fixes none of these. The work a good SE does before and around a POC fixes all of them.
The perfect build nobody uses. This path is more subtle and more dangerous. The customer hands over requirements and the FDE builds exactly that: clean code, shipped on time. Then nobody adopts it, because the requirements described what the customer thought they needed rather than the actual problem. Flybridge warns that when field work doesn't compound into the core product, the economic argument for FDEs collapses fast. A Latent Space piece on FDE best practices is blunter: an FDE function that solves customer problems without sending the signal back to product is a services consulting team with a better title. The CEO of ElevenLabs has made the same point. FDE code has to feed back into the product so the broader customer base benefits.
That means pushing back on customizations that help one customer and nobody else. Tim, an engineer by training, is direct about it:
"Saying no to a customer who is paying for your time, well, guess what? That is a skill. And I can promise you one thing. This one was never taught to me." — Tim Brömme
Both failure paths are missing the same short list: agreed success criteria, a stakeholder map, discovery that reached the real problem, and the confidence to say no. All four can be trained. A typical engineering career teaches none of them.
If FDEs carry no quota, is their job really commercial?
Yes. The success metric is adoption, and under consumption-based pricing, adoption and revenue are the same number seen from two sides. OpenAI's posting names "production adoption, measurable workflow impact, and eval-driven feedback." Anthropic's FDE role exists to drive AI adoption. Time-to-first-value and usage ramp show up directly on the customer's bill.
The Alexander Group, a revenue consultancy, recommends measuring FDEs on time-to-first-value and early consumption. It notes that many organizations put the role on a sales compensation plan because of how much it speeds up the usage ramp. Tailscale goes all the way. Its FDEs have on-target earnings with variable pay tied to quarterly sales targets, and they run quarterly business reviews to fund expansions. That's an expansion role with an engineering title, and it raises a fair question about where customer success fits.
Flybridge's test for whether the role pays for itself is a path from a $50,000 pilot to a seven-figure contract. That's 10x or more, not 2x, and it has to be, given what Flybridge estimates an FDE costs: $222,000–$400,000 a year fully loaded, for someone who may be on site half the time. Whether that path gets walked depends on finding the right problem, keeping the sponsor engaged and turning a working deployment into a reason to expand. In SE language, that's a technical win followed by a commercial one.
For SEs, that's good news. The market is finally paying engineering salaries for people who can run discovery, manage stakeholders and keep a customer's trust through a difficult deployment. As Tim puts it, "The FDE trend is the market putting a nice price tag on the SE."
What should FDE training cover beyond code?
It should cover five skills, and the same list applies to an SE team. There's a training gap behind this. Companies hire FDEs for the engineering half because that's what they can screen for. Paraform's hiring guide makes a similar point: too many teams run standard software engineering interviews instead of testing customer communication. So engineers arrive with the engineering half trained and everything else untrained. Companies then discover the gap in the field, at up to $400,000 a year per engineer, on accounts with seven-figure expansions at stake.
If we were standing up the program, it would cover:
- Discovery as a method, not a personality trait. A repeatable way to get from the stated request to the real problem to a quantified impact, practiced on live accounts. We call this the pain chain.
- Success criteria before the build. Agree in writing what the customer will accept as proof, with an owner and a date. The 12-week pilot that produced nothing had none of this.
- Stakeholder mapping. Who owns the data, who signs, and who loses if the project works. Qureshi's "sensitivity to social context" is a skill with a method behind it, and anyone can learn it.
- Executive communication. Reporting progress and problems, in their terms, to people who will never read the code.
- Saying no. Turning down the customization that won't compound without losing the account.
A one-off workshop won't build any of these. Behavior on a customer call changes with practice and coaching, not with an engineering certificate. Engineering gets you through the door. The customer work decides how the engagement turns out, for FDEs and SEs alike.
If you want the sources and the full breakdown, see our guides What is a forward deployed engineer? and Forward deployed engineer skills.
Frequently asked questions
What is a forward deployed engineer (FDE)? An FDE is a vendor engineer embedded with customers who builds and deploys the product in the customer's own environment, mostly after the contract is signed. Ideally, what they learn in the field flows back into the product. Palantir created the title, and AI companies such as OpenAI, Anthropic and Databricks now hire for it heavily.
What is the difference between a forward deployed engineer and a solutions engineer? They differ in five ways. SEs work before the signature and FDEs mostly after it. SEs produce proof (demo, POC, business case), while FDEs ship production code. SEs usually earn variable pay and FDEs usually get equity. SEs report into sales, while FDEs mostly report into FDE or engineering teams. SEs cover many deals, while FDEs go deep on a few customers. Discovery, stakeholder management and executive communication are shared.
Do forward deployed engineers carry a quota? Almost never. In Bloomberry's analysis of about 1,000 postings, 0% of FDE roles were quota-carrying. Tailscale is an exception, with variable pay tied to quarterly sales targets. Even without a quota, FDEs are measured on adoption, which under consumption pricing translates directly into revenue.
How much does a forward deployed engineer earn? Flybridge estimates $222,000–$400,000 a year fully loaded. Bloomberry's posting data puts the median advertised salary at $173,816, and pay is typically base plus equity rather than commission.
Can a solutions engineer become a forward deployed engineer? Yes, and many already have. In Bloomberry's data, 22% of FDEs came from solutions engineer or solutions architect roles and 10% from technical consulting. The gap to close is usually production-grade engineering in the customer's environment. The customer-facing half is the part SEs already bring.
Building an FDE or SE team and want the customer half trained rather than left to chance? The Trusted Advisor Academy covers discovery, success criteria, stakeholder mapping and executive communication over 12 months. Book a discovery call to see if it fits your team.
Tim Brömme & Jan-Erik Jank, co-founders of SE Rockstars: 30+ years of enterprise PreSales, 350+ SEs coached.
Listen to the full episode
Tim walks through the FDE role task by task, with all the sources, in this English-language episode: