FDE vs solutions engineer: before and after the signature
A solutions engineer works before the contract is signed. Their job is to prove, in front of a prospect and usually against a competitor, that the product can do what this account needs. They are measured on whether the deal closes. A forward deployed engineer works after the signature, inside the customer, and is measured on whether anything in that organisation actually changed. The two roles share a great deal: both are technical, both spend most of the week with customers, both have to explain a system to people who do not want a lecture. What separates them is the incentive at the end of the quarter. A solutions engineer succeeds when a customer believes. A forward deployed engineer succeeds when a customer no longer needs to believe anything, because the thing is running and they are using it.
| Forward deployed engineer | Solutions engineer | |
|---|---|---|
| In one sentence | An engineer employed by the product company, working inside the customer’s organisation to make the product solve that customer’s actual problem. | A technical seller who proves, in front of a prospect, that the product can do what the account needs. |
| Judged on | Whether the customer’s workflow changed, and whether it stayed changed after the engineer left. | Whether the deal closes, and whether what was promised in the demo was true. |
| Works inside | The customer’s systems, data and meetings, often on their premises. | Demo environments, proofs of concept, security questionnaires and the sales cycle. |
| Usually leads to | Leading a deployment team, or product management with unusual field credibility. | Leading a pre-sales organisation, or moving into product or into an FDE role post-sale. |
| Time with the customer How much of the week is spent with the people who will use the thing. | High | High |
| Technical depth How deep the engineering expected of the role goes. | High | Medium |
| Business depth How well the role is expected to understand the customer’s own trade. | High | High |
| Hands on code How much of the job is actually writing and integrating software. | High | Medium |
| Owns the outcome Whether the role is judged on delivery, or on what the delivery changed. | High | Low |
These levels describe where each role sits on average, not a rule. Job titles are not standardised across companies, so a given posting can sit well away from its column. Read what a posting says the person will build rather than the heading.
The handover is where accounts go wrong
The interesting thing about these two roles is not how they differ in the abstract. It is what happens at the seam between them, because that seam is where a great many enterprise deployments fail, and the failure is structural rather than personal.
A proof of concept is built to answer one question: can this product, in principle, do the thing. To answer it quickly, the solutions engineer works on clean data, a narrow slice, and a friendly stakeholder. Every one of those choices is correct for the question being asked. Every one of them is also a debt that comes due after signature.
The forward deployed engineer inherits the demo and the expectation the demo created. The data is not clean, the slice was the easy tenth, and the friendly stakeholder was not the person whose workflow has to change. None of this is anyone’s fault. It is what happens when a system optimised to answer "can it" is handed to someone answering "will it, here, for these people, every day".
Organisations that handle this well do one thing consistently: the deployment engineer is in the room during the evaluation, silently, as an observer. They are not there to sell. They are there so that the promises made in front of them are promises they can keep.
Two different relationships with the truth
This is worth stating carefully, because it is easy to turn into an unfair caricature of pre-sales work. Good solutions engineers are scrupulous, and the best of them kill their own deals when the product is wrong for the account, because a bad-fit customer costs more than it earns.
But the pressures are genuinely asymmetric. A solutions engineer is rewarded for a customer’s confidence, and confidence can be produced ahead of capability. A forward deployed engineer is rewarded only by capability, because they are the one standing there when the confidence runs out. The result is a useful division of labour: one role generates belief, the other converts it or destroys it.
A company that staffs only the first ends up with a customer base that bought something it never used, which shows up eighteen months later as a renewal problem nobody can explain.
What the week looks like on each side
A solutions engineer’s calendar is cut into pieces by other people’s processes. Discovery calls, a demo, a security questionnaire, an architecture review with the prospect’s infrastructure team, a competitive bake-off with a deadline set by the customer’s procurement. Depth is a luxury: the job rewards range, because the next call is about a part of the product you have not touched in a month.
A forward deployed engineer’s calendar is longer-grained and much less predictable in a different way. Weeks of uninterrupted building, punctuated by a discovery that invalidates part of it. The job rewards depth on one account and patience with things that are not engineering problems at all.
Engineers who like variety and pace, and who get energy from performing under pressure, tend to prefer pre-sales and are often quietly relieved when they realise the preference is legitimate rather than a lack of ambition. Engineers who need to see something through to the point where it actually works tend to find the demo cycle hollow.
Compensation works differently, and it matters
We do not publish salary figures on this site, for reasons set out in our methodology. But the structure of pay differs between these two roles in a way that is not a number and is worth knowing before you choose.
Solutions engineering is usually paid on a sales-style split, with a meaningful variable component tied to quota attainment. That means income is partly determined by how the territory performs, which is largely outside the individual’s control. Some people find that motivating. Others discover they hate it.
Forward deployed roles are more often paid as engineering roles, on a salary and equity structure, sometimes with a component tied to account outcomes. The variance is lower and the connection between individual effort and pay is more direct. Neither structure is better. They suit different temperaments, and it is a more consequential difference than the titles.
If you are choosing between two offers
Ask each hiring manager one question: what does this person do in the six weeks after a contract is signed. The answer sorts the roles faster than any job description.
If the answer is that they move to the next opportunity, it is a pre-sales role, and that is a real career with its own depth and its own path to leadership. If the answer is that they stay and build, it is a deployment role. If the answer is that it depends, you are being hired into both jobs at once, which happens at smaller companies and is survivable, but you should know it before you sign rather than in month four.
