Forward deployed engineer skills split into two halves. The engineering half is production coding, integration and systems design in someone else's environment. The other half is customer-facing: running discovery, managing stakeholders and expectations, communicating with executives, and knowing when to say no. Hiring companies list the first half as the requirement and the second as a nice-to-have. The evidence from FDEs themselves runs the other way: engagements fail on the customer-facing half far more often than on the code.
TL;DR
- Most of the job is not building. "Working directly with customers" is the number one responsibility in FDE postings; a working FDE reports "roughly 50% meetings and 50% building."
- FDEs are measured on adoption, and adoption is revenue. In consumption-priced software, the FDE's success metric (time to first value, usage) is what the customer's bill is made of.
- The documented failures are not technical. Pilots consumed by data-access politics, building what was asked instead of what was needed, trust never earned at the top of the customer organisation.
- These are the same skills that decide a sales engineer's deals. Discovery, expectation management and executive communication are trainable, and most FDE hiring ignores them.
- The hiring companies half-know this. Anthropic asks for the ability to "conduct discovery with customers"; Tailscale requires "a consultative capacity"; Databricks wants "strong leadership and consulting skills."
What skills does a forward deployed engineer need?
Two sets, and the postings weight them unevenly. Bloomberry's analysis of about 1,000 FDE postings found "working directly with customers" to be the number one responsibility, named in 55% of postings, ahead of building AI systems (37%) and integrations (32%). Customer-facing ability was the most frequently required soft skill, at 47%. Yet the hard requirements in most postings are years of engineering experience and a technology stack.
| Skill set | What it covers | How postings treat it |
|---|---|---|
| Engineering | Production code in the customer's environment, integration, data pipelines, systems design, debugging in unfamiliar infrastructure | Hard requirement, listed first |
| Discovery | Getting from the stated request to the real blocker, and to a number the customer cares about | Sometimes named ("conduct discovery"), rarely defined |
| Stakeholder management | Mapping who decides, who blocks, who owns the data; earning trust at the top of the customer organisation | Implied by "customer-facing", rarely spelled out |
| Expectation and scope management | Agreeing success criteria, sequencing delivery, saying no to work that will not compound | Appears as "manage ambiguity" |
| Executive communication | Explaining a technical failure to a non-technical VP without losing the room; presenting progress to sponsors | "Strong communication skills" |
| Commercial awareness | Understanding that adoption is what the customer pays for, and where expansion comes from | Almost never stated, often measured anyway |
Bloomberry's author puts the customer-facing bar in one sentence: "If you can't sit in a conference room with a non-technical VP and explain why their AI agent keeps failing without making them feel stupid, you won't succeed."
If the role itself is new to you, start with What Is a Forward Deployed Engineer?
Why is discovery the FDE's most important skill?
Because the FDE builds whatever the discovery says to build, and the customer's stated request is rarely the real problem. Milos Mandic, an FDE at Lleverage, describes his week as "roughly 50% meetings and 50% building" and names the core skill as "seeing what's actually blocking a client, which is rarely what they say is blocking them." His conclusion about the job: "less about building AI systems and more about understanding businesses well enough to know what to build."
Flybridge's Daniel Porras Reyes describes the same skill from the investor's seat. A great FDE will "educate the customer, help them articulate latent problems, bridge the knowledge gap between 'what they think they need'" and what the technology can do. That is a definition of discovery, and it is the definition PreSales has used for years. An FDE who takes the requirements document at face value and builds it well has still failed, because the customer will not adopt a solution to the wrong problem.
The hiring companies that name this skill name it in PreSales language. Anthropic's FDE posting asks for "strong communication skills to conduct discovery with customers and to convey technical concepts to diverse stakeholders." OpenAI's has FDEs "own discovery, technical scoping, system design, build, and production rollout", with discovery first in the list. The method does not change with the title. Start with the symptom the customer describes, ask what it causes, keep going until you reach cost, revenue or risk, then attach a number. Our discovery call guide lays out that ladder.
Why do FDE engagements fail for non-technical reasons?
Because the hard part of an embedded deployment is the organisation around it, not the code inside it. The clearest account comes from Nabeel Qureshi, a former Palantir FDE, in Reflections on Palantir. On what the job required: "Being a successful FDE required an unusual sensitivity to social context – what you really had to do was partner with your corporate (or government) counterparts at the highest level and gain their trust." On how engagements went wrong: "You'd have a company buying an 8-12 week pilot, and we'd spend all 8-12 weeks just getting data access, and the final week scrambling to have something to demo."
Both paths end without adoption, and neither is an engineering failure.
Every sales engineer who has run a proof of concept recognises that pilot. The data owner who will not 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. None of them is solved by a better engineer; all of them are solved by the work an SE does before and around a POC.
There is a second failure path that is quieter: building exactly what was asked. Flybridge's warning is that when field work does not "compound into the core product, the economics argument collapses fast." A Latent Space piece on FDE best practices makes the same point from inside the profession: an FDE function that solves customer problems without sending the signal back "is a services/consulting team with a better title." Avoiding that requires the FDE to push back on requests, to say no to the customisation that helps one customer and nobody else. Saying no to a customer who is paying for your time is a skill, and engineers are not trained in it.
Are forward deployed engineers measured on adoption and revenue?
On adoption almost always, and adoption is what the customer pays for. This is the link that makes the FDE's customer-facing skills a commercial matter rather than a soft one.
OpenAI's posting states the metric directly: FDEs "measure success through production adoption, measurable workflow impact, and eval-driven feedback." Anthropic's FDE exists "to drive transformational AI adoption." Under consumption-based pricing, which is how AI products are increasingly sold, adoption and revenue are the same number seen from two sides. The revenue consultancy Alexander Group recommends measuring FDEs on time to first value and early consumption, and observes that "many organizations are placing this role on a sales compensation plan" because of its effect on how fast usage ramps.
Some companies go further. Tailscale's FDE role is paid on on-target earnings with "variable compensation tied to the attainment of quarterly sales targets", runs quarterly reviews to "identify opportunities for deeper engagement and horizontal expansion", and requires "experience working with enterprise customers in a consultative capacity." That is an expansion role with an engineering title.
So the FDE sits where the customer decides whether to spend more. Flybridge's test for whether the role pays for itself is commercial: "a path from a fifty thousand dollar pilot to a seven figure contract." Whether that path gets walked depends on whether the FDE found the right problem, kept the sponsor engaged and turned a working deployment into a reason to expand. We would call that the technical win followed by the commercial one. The vocabulary is in our guide to what PreSales is.
Which forward deployed engineer skills are shared with solutions engineers?
All of the customer-facing ones. The two roles differ in timing and output, as our FDE vs solutions engineer comparison sets out, but the work in the middle is the same: understand the customer's problem better than they have articulated it, manage the people who can block or fund the work, and hold their trust through setbacks.
The market has noticed. In Bloomberry's data, 22% of FDEs came from solutions engineer or solutions architect roles and 10% from technical consulting. Anthropic's required background is "a technical, customer facing role such as Forward Deployed Engineer, or as a Software Engineer with consulting experience." Databricks describes its FDEs as "highly experienced and technical resources with strong leadership and consulting skills." The people hiring FDEs are looking for engineers who can do the SE's job, whether or not the posting says so.
Most SE leaders we work with see the FDE title as a well-paid rebrand of work presales and professional services already do. We set out why in What Skills Will Solution Engineers Need in the Age of AI?, and it cuts both ways: if the FDE is doing presales work, the FDE needs presales skills.
How should companies train forward deployed engineers?
The way they should train solution engineers, and mostly do not: on the customer-facing half, continuously, on live engagements.
Engineering skills are covered. An FDE arrives able to code, or is not hired. What arrives untrained is everything else in the table above, because engineering careers do not teach discovery, stakeholder mapping or how to tell a sponsor that the pilot is off track. Companies then discover this in the field, at $220K to $400K per engineer per year by Flybridge's estimate, on accounts with seven-figure expansion at stake.
Five things an FDE program should cover, all of them familiar to anyone who has trained SEs:
- Discovery as a method, not a personality trait. A repeatable way from the stated request to the real problem to a quantified impact, practised on real accounts.
- Success criteria before the build. What the customer will accept as proof, agreed in writing, with an owner and a date. The 8-to-12-week pilot that produced nothing had none.
- Stakeholder mapping. Who owns the data, who signs, who loses if this works. Qureshi's "sensitivity to social context" is a skill with a method behind it, not a gift.
- Executive communication. Reporting progress and problems to people who will never read the code, in their terms.
- Saying no. Declining the customisation that will not compound, and doing it without losing the account.
A one-off workshop will not install any of these. Behaviour on a customer call changes with practice and coaching, not with a certificate, which is the argument of our guide to choosing PreSales training. The good news for the FDE trend is that the training exists. It has been aimed at solution engineers for years.
Frequently asked questions
What skills do you need to be a forward deployed engineer? Production-level software engineering in unfamiliar environments, plus the customer-facing skills the job actually turns on: discovery, stakeholder and expectation management, executive communication, and commercial awareness of how adoption becomes revenue. Postings list the engineering half as the requirement; FDEs themselves report spending about half their time in meetings.
Do forward deployed engineers need sales skills? They need the skills that sit underneath good selling: finding the real problem, managing the people who decide, and holding trust through a difficult delivery. Most FDEs carry no quota, but they are measured on adoption, which is what the customer pays for, and some companies attach expansion targets or sales-linked pay. Whether you call those skills "sales" or "consulting" changes nothing about needing them.
Why do forward deployed engineer projects fail? Rarely because the code did not work. Documented failures include pilots consumed by negotiating data access with internal gatekeepers, success criteria never agreed, sponsors who disengaged, and teams that built exactly what was requested without finding out whether it was what the customer needed. Each is a discovery, stakeholder or expectation failure.
Is a forward deployed engineer a technical or a customer-facing role? Both, and the balance surprises people who come from engineering. One FDE's own log puts it at half meetings, half building; job postings name working with customers as the top responsibility. The engineering is the entry ticket; the customer work decides the outcome.
How is an FDE measured? Typically on production adoption, time to first value and workflow impact, not on a sales quota. OpenAI's posting names adoption as the success metric; the Alexander Group recommends time-to-first-value and early consumption. Under consumption pricing those metrics are the customer's spend, which is why some companies put FDEs on sales compensation plans.
Can a solutions engineer move into a forward deployed engineer role? Yes. About a fifth of FDEs in one analysis came from solutions engineer or architect roles. The skill to add is usually production coding; the discovery, stakeholder and communication skills transfer directly, and they are the ones FDE teams most often lack.
The customer-facing half of the FDE's job is the whole of ours. The Trusted Advisor Academy trains discovery, stakeholder work and executive communication every week, on live deals, for solution engineers and for anyone else whose title puts them in front of a customer with a problem to solve. If you are standing up an FDE team and want to know what it will need beyond code, book a discovery call.
Tim Brömme & Jan-Erik Jank are the co-founders of SE Rockstars, with 30+ years in enterprise PreSales and 350+ SEs coached.