Is an FDE a pre-sales role?

At the front of a deal, an FDE and a pre-sales engineer look nearly identical. Both sit with the customer, both know the product deeply, both are in the room when the technical questions get hard. The resemblance is real, and it is why the question keeps coming back. But the resemblance ends at the signature, and the signature is exactly where the FDE's own work begins.

The test is scope, not title

Pre-sales success is a signed contract. An FDE's success is a system still running when nobody is watching, measured on data the client produced. Four boundary rules separate the two, and each one has a question behind it that a job description cannot answer.

Does this person carry the production result? When the integration breaks at two in the morning in week six, whose phone rings? If the answer is the customer's IT team or the support desk, the role has handed off before the risky part started. Carrying the pager is the least glamorous and most reliable indicator in this list.

Do they write code or integrate systems? The third word in the title is engineer, and it means production code, not a report. A role that never commits anything is advising on a system rather than owning one — which is a legitimate job, and a different one.

Do they own adoption? Not the applause in the demo. The four-week rule: still in use four consecutive weeks after go-live, with a named role and a frequency, and anything above a 30% stop-use rate counted as not live. Somebody has to be measured on that number, and in a pre-sales role nobody is.

Does the learning go back into the product? This is the rule most often skipped, because it is the one that costs the deploying company money in the short run. Every deployment produces findings that should shorten the next one; if nobody owns that transfer, the same lesson is bought again at the next customer. It is the fourth of the five stages — the feedback loop — and it is what makes a deployment function more than a services business.

Where the line actually sits

Pre-sales work ends at signature; the FDE's work starts there and goes into the deeper water. The artefacts differ: slides versus a system running in production. The success criteria are not merely different but inverted. A sales team wins when the contract is signed. An FDE has won when the client no longer needs them — the client's independence is the deliverable, not the dependency.

It is worth separating the role from the product engineer too, because "not pre-sales" is often heard as "product team, with travel". A platform engineer owns one capability serving many customers; an FDE owns one customer and mobilises many capabilities. That is not a junior version of product work. It is the same engineering aimed in the opposite direction.

The honest edge cases

There are two, and both are common.

Many real FDE roles do open with a commercial motion. A training camp ends with an executive using their own data on a system built inside the camp week, and the deal moves into commercial the same afternoon. Being in the room before the signature is not a disqualifier — the best FDEs often are. What decides it is whether the work continues after the signature, on the same terms, with the same person still holding the pager. A role that does the week before signature and hands off at the contract is pre-sales with a laptop.

And some roles carrying the title are pre-sales engineers with a modern label. The title spread is wide, and the job description is the tell: demos, RFP responses, POC coordination and travel to pitch — with no on-call, no repository, no post-launch metric, no route into the roadmap — describes the other job. In that case the label is the least reliable evidence in the file.

Three questions to ask in the interview

1. "What happens in week five, after go-live?" A real answer names who gets paged, who writes the fix, and who decides the deployment is finished. A vague answer usually means week five belongs to someone else.
2. "Who defines success, on whose data source, and what happens if the number does not move?" This tests whether an acceptance criterion exists before the work starts, and whether this person owns it or merely reports against it.
3. "Where does what you learn on site end up?" The strongest answer names the last two or three things that went from a client site into the product, and who decided they should.

A good interviewer answers all three with specifics: a week number, a role, a metric, a feature. Vagueness across all three is itself the answer — you are looking at a role that has not yet decided what it is responsible for.

If the four boundary rules come back yes, the role is an FDE whatever the posting calls it. If two of them come back no, the title is decoration.