FDE vs Sales Engineer: The Job Starts Where the Contract Is Signed

The most expensive confusion in enterprise AI right now is between two people who look identical in an org chart. Both are technical. Both spend their week with customers. Both can build a demo that makes a CIO lean forward. One of them is done when the CIO signs. The other one has just started.

If you hire the first when you needed the second, you get a company with a beautiful pipeline and a graveyard of pilots. If you hire the second and manage them like the first, they quit. This chapter is the line between them, and it is a single line.

The short version

A sales engineer's accountability ends at the signature. A forward deployed engineer's accountability begins there. Every other difference, on-site time, integration depth, ownership of code, follows from that one. Solutions architects design the fit and hand off the build. Consultants deliver recommendations and leave. Professional services implements a fixed spec for a fee. Developer relations scales across thousands of users through docs. The FDE goes deep into one customer's production system and is measured on whether the outcome the customer bought actually shows up. The test for any of these titles is not what they are called. It is who is on the hook after go-live.

The one question

Ask this about any customer-facing technical role: when the customer's outcome does not show up, whose number goes red?

A sales engineer's number is bookings. Once the deal closes, the outcome is somebody else's problem, and the incentive structure is honest about it. That is fine. Pre-sales is real work and the best SEs are extraordinary at it. It is just a different job.

A forward deployed engineer's number is the outcome. At Sierra that is literally the invoice: the customer pays per resolved case, so an engineer who wires the integration badly does not get a bad review, they get a smaller bill. At Palantir it was renewal and expansion, which in a company that for years ran almost no traditional sales force meant the FDE was the sales motion. Either way, when the outcome does not show up, the FDE is the one holding it.

That difference explains everything else people list. FDEs are on site more because you cannot own an outcome from a demo environment. They write production code because the outcome lives in production. They stay after go-live because the outcome is measured after go-live. None of those are the definition. They are consequences.

Five neighbors, one test

Plank's guide to the role has a useful map of the adjacent titles, and it is worth walking through with the test in hand.

The solutions engineer, or sales engineer, supports the sale. Demos, proofs of concept, security questionnaires, the architecture slide. Their job is to get to yes. At yes, they hand off. Test result: accountable up to the signature.

The solutions architect designs how the product fits the customer's stack. Good ones prevent a year of pain. They typically do not build what they design, and they are rarely measured on whether the design produced the business result. Test result: accountable for the design, not the outcome.

The management consultant delivers a deck. Sometimes a very good deck. The recommendation is the deliverable, and the client's execution of it is the client's problem. Test result: accountable for the analysis.

Professional services implements. The scope was fixed at contract, the hours are billed against it, and a change to the scope is a change order. Test result: accountable for delivering the spec, which is not the same as the outcome, and everyone who has run an implementation knows how far apart those two can be.

Developer relations scales one-to-many. Docs, samples, talks, community. Excellent at reaching a thousand developers. Structurally unable to go deep into one customer's messy production system. Test result: accountable for reach.

The forward deployed engineer sits after the signature, builds in production, and is measured on the result. Test result: accountable for the outcome. Everything else on the list is a real job. Only this one passes.

Why the confusion is so expensive

Two failure modes, both common.

The first is hiring SEs and calling them FDEs. It happens because the two look alike on a resume and because SEs are easier to find. The company ends up with excellent pilots and no production. Every pilot ends with a signed contract and a customer who cannot get the thing to work on their own data, and nobody whose job it is to fix that. The MIT NANDA figure that 95 percent of enterprise generative AI pilots show no measurable business impact is, in my read, mostly this failure mode at industrial scale. The models work. Nobody owned the outcome.

The second is hiring FDEs and managing them as pre-sales. Their calendar fills with demos. Their compensation tilts toward bookings. They are pulled off a deployment at the hard part to close the next one. The customer whose outcome they own gets an engineer for two weeks and a ticket queue after that. The best FDEs leave, because the thing they signed up for is the part after the signature, and the company keeps taking it away from them.

Both failures come from not asking the one question. Meurer's satirical FDE job posting, eight years as a staff engineer plus six years of direct sales plus four years of solutions architecture, is funny because it is what happens when a company wants the accountability of an FDE and the pipeline of an SE in one salary.

Titles are drifting, the test is not

Titles are already unreliable. OpenAI has used customer engineer and forward deployed engineer. AWS calls a pre-sales role solutions architect. Sierra calls its version agent engineer, and Meurer, who coined that, has since said the whole cluster of titles is converging on one function: engineering that is accountable to the customer. Decagon's framing is that FDE simply is product engineering with the same bar and reporting line.

That convergence is the point of this wave. Titles will keep moving. Who is on the hook after go-live is what you are actually hiring for, and it is what the customer is actually buying. I would put the question in the job description, in the comp plan, and in the first interview.

The next chapter covers making the transition from any of the five neighbors into the role, because the technical distance is short and the accountability distance is not. And if you are wondering what the product has to look like before an FDE can own anything, that is what has to change in the product and it comes before hiring, not after.

This wave sits in the running argument on AI Product Management, which is that the role is defined by what one person can own once building is cheap.

Start this week

Pull the last three deployments that stalled. For each one, write down the name of the person who was accountable for the outcome after the signature. Not the account owner. Not the implementation lead. The person whose scorecard moved when the outcome did not.

If the same name appears three times, you have an FDE and should call them one. If no name appears, you have found why the deployments stalled.

Sources: Plank, What Is a Forward-Deployed Engineer · Natalie Meurer, The Dirty Secret of Forward Deployed Engineering, AI Engineer 2026 · MIT NANDA, State of AI in Business 2025, via MarkTechPost