What a forward deployed engineer is, and how to spot a real one

Key takeaways

• What is a forward deployed engineer? A senior software engineer who works inside a customer's environment after the contract signs, writes production code there, and stays until the product is adopted. Pre-sale demos are someone else's job.
• Palantir built the role. The AI labs copied it in 2024 and 2025, and by June 2026 AWS had committed $1 billion to it. Insight Partners' July 2026 panel put growth in FDE roles at roughly 40x over 24 months.
• The title spread faster than the capability. Bloomberry's read of 1,000 FDE postings found 60% describing an embedded builder, 30% a rebranded sales engineer and 10% an internal-tools role.
• The skeptic's case, that FDE is a fancy name for sales engineering, is about 30% right. The quota data settles the rest: 0% of those 1,000 postings carried one.
• You can test any vendor's FDE in one paragraph. Ask about the last engagement: whose system, what broke, who adopted it, what finance measured, what went back into the product. Scoring what sits behind the label is the job of the FDE readiness rubric.

Why this question matters

You're asking what is a forward deployed engineer because the phrase turned up in a pitch, a hiring plan or a board deck, and you need to know whether it names a specific kind of engineer or whoever the vendor has on the bench this month. The answer decides what you pay, who you put in front of your customer, and whether the deployment backlog sitting behind your sales team gets shorter or gets a new label.

The frame: Four things an FDE owns after the contract signs

The role is defined by what happens after signature, and by four things the engineer owns rather than supports.

1. The integration into the customer's real systems, written as production code, in their repo or yours, against their data and their permissions.
2. The gap between what was sold and what the customer's estate will allow, closed by building rather than by escalating to someone else.
3. Adoption. The workflow changes, the operators use the thing, and somebody can say afterwards what moved.
4. The loop back into the core product, so the third customer with the same problem gets a feature instead of a bespoke build.

Every relabelled role fails at least one of the four. Solutions engineers stop at signature. Technical account managers own the relationship and not the code. Professional services consultants own a statement of work and hand back at go-live. Hold a vendor's definition against the four and the differences show up fast.

What is a forward deployed engineer?

A forward deployed engineer is a customer-facing software engineer who develops and deploys software within a client company, often working alongside the client's employees for a defined period. That's the Wikipedia definition, and it's accurate as far as it goes. What it leaves out is the commercial situation that created the role and the reason every AI vendor now hires for it.

Palantir popularised the role, splitting its engineers between the product team and the engineers who lived at the customer. The idea was that a powerful platform dropped into a government agency or a refinery wouldn't get used unless someone technical stayed to wire it into the way the place actually ran. Marty Cagan's framing is that this is product discovery done by your best engineers, in the customer's building, finding out what the product needs to become. His caveat is the one to remember: the model only scales if someone synthesises what the FDEs learn into the platform, which he calls much easier to say than to do.

The AI wave made the role general. In June 2025, a16z's Joe Schmidt called the FDE the hottest job in startups and counted 22 of OpenAI's 311 open roles as forward deployed or solutions engineering. PostHog's version of the definition is the most useful one for a buyer: an engineer embedded in a customer's team to fill the gap between what your product does and what the customer needs. By 30 June 2026, AWS had committed $1 billion to embedding thousands of engineers with customers and extended the motion to its consulting partners. Three weeks later an Insight Partners panel of ServiceNow, Databricks, Workato and Wonderful put growth in the role at roughly 40x over 24 months.

The reason is the same at every one of those companies. AI products work in the demo and stall in the customer's estate, where the data is messier, the permissions are stricter and the workflow has exceptions nobody wrote down. Somebody has to build through that, and the engineer who does is now called forward deployed.

What does a forward deployed engineer do day to day?

Most of the week is building, in the customer's environment, against the customer's constraints. The rest is the work that makes the building possible: sitting with the operators who run the workflow, getting through security review and procurement, and deciding what to generalise. The Insight Partners panel's line was that it's always a pod composition, never an individual FDE, and that ServiceNow and Workato keep the function in product and R&D rather than go-to-market so what's learned in the field reaches the roadmap.

Engagement length is set by the product, and it varies more than the job title suggests. Insight's day-in-the-life piece has windows of three to four weeks at Rocketlane, six to eight at nCino and 12 to 14 at ServiceNow. Ramp's FDEs work the whole customer lifecycle, from late-stage prospect through rollout to long-tail support; the team went from two in fall 2023 to about 16, seven of them former founders. PostHog's first FDE is fully remote and async, building migration automation for large analytics moves, which tells you the role is defined by what gets built and who it gets built for, and travel is a variable rather than the definition.

How did the title get diluted?

The title is free and the capability isn't, so the title moved first. When Bloomberry parsed 1,000 FDE postings, 60% described an embedded builder, 30% described a sales engineer with a better title and 10% described an internal-tools role that shouldn't carry the name at all. Fifty-eight percent of the postings were at companies of 11 to 200 people, which is where a deployment backlog hurts most and where hiring managers are most tempted to relabel.

The demand curve explains the pressure. TechCrunch's report on the Christian & Timbers study found that 5 to 10% of companies were planning FDE hires in January 2026 and 70% were by the end of Q2. The same study estimates about 2,000 engineers in the US who've repeatedly turned enterprise AI deployments into documented business value, inside a broader market Christian & Timbers puts at about 17,000 people. When planned demand moves sevenfold in six months and qualified supply doesn't, the gap gets filled by renaming the people already on payroll.

Christian & Timbers' own test for what counts is worth borrowing. An FDE works directly with the people running a workflow, builds a production system around it, drives adoption, and can sit with finance afterwards and explain what changed in dollars. Their list of adjacent roles that don't count maps onto the four ownerships above.

The reporting column is the quiet tell. Perspective AI's founder's playbook and the Insight panel both land on engineering or product and both warn against a go-to-market line, because an FDE who reports into sales gets measured like a sales engineer and starts behaving like one.

Is a forward deployed engineer just a sales engineer with a better title?

The top Google result for the term is an r/ExperiencedDevs thread that says yes: a fancy name for sales engineering, heavy travel, burnout, a role that exists so vendors can charge for services without calling them services. A buyer should take that seriously, because the people posting there have held the job.

They're right about a share of the market. Bloomberry's 30% is a real population of sales engineers with new business cards, and if the postings look like that, the vendors' benches do too. They're right about travel; Wikipedia's entry records that some engineers view the role unfavourably for exactly that reason. And they're right about a deeper problem F-Prime's Rocio Wu names in her essay on FDEs: if more than 30 to 40% of a vendor's deployments need significant FDE effort, the vendor has a product-design problem wearing a go-to-market costume. An FDE can make that look better externally and worse internally.

They're wrong about the role itself, and the compensation data is where it shows. Of Bloomberry's 1,000 postings, exactly 0% carried a quota, 8% mentioned OTE and 70% mentioned equity. Sales engineers are paid on the deal; these people are paid like engineers because their output is code running in production after the deal. The reporting lines at ServiceNow, Workato and Ramp sit in product and engineering. PostHog's FDE never gets on a plane. The work that separates the role from pre-sales, building the integration through the customer's security review and staying until the operators use it, is the part a sales engineer's job description ends before.

The buyer's risk is different from the skeptic's complaint. Whether the title is fashionable doesn't matter to you. What matters is whether the person a vendor puts in front of your customer has done the four things above, and the title alone can't tell you.

How do you tell whether a vendor's FDE is real?

Ask for the last engagement, in writing, before the call. Which customer system did the engineer write production code in, and whose repo did it land in? What broke during rollout, and what did they do about it? Who adopted the result, and how many of them are still using it? What did the customer's finance team measure afterwards? How much of the build went back into the core product? A forward deployed engineer answers all five from memory, with names of systems rather than names of frameworks. A relabelled sales engineer answers the first one from a demo environment. A technical account manager answers the third. A consultant answers the second and stops there. Christian & Timbers' red flags are the same: architecture without adoption clarity, or adoption without build detail, means the person didn't own the deployment end to end.

Two more questions go to the vendor rather than to the engineer. Who directs the work and who owns the outcome, and does the vendor ever appear in front of your customer under its own name? There's a right answer to the second one, which is never. On the first, A.Team's position is that the client directs the work and owns the outcome, and the engineer owns their delivery; whatever a vendor's answer is, get it in writing so you and they believe the same thing.

Those questions tell you whether a vendor has done the work before. They won't tell you whether the individual engineer in front of you is ready for your customer, which is a different assessment: eight criteria a network can compute before anyone meets your customer, and the limits of what a score can tell you. The FDE readiness rubric covers those, and carries the same questions to put to anyone selling you FDEs, including A.Team.

What to do next

If you're evaluating vendors, run the paragraph test on each of them in writing before you take a call, and read the answers side by side. If you're deciding whether to build an FDE team, rent senior engineers under your own badge or hand deployment to a partner, that decision is in when to hire forward deployed engineers. If you're writing the job description, the technical floor is the applied AI engineer skill set with production ownership and customer fluency on top, and the forward deployed engineer role page shows what that profile looks like in practice.

When the backlog is already there, A.Team puts 1 to 3 named and priced senior engineers in front of you to interview within 3 to 5 business days, each scored against the rubric before you meet them, working under your brand and your direction.