Two job descriptions land on your desk and they read almost identically.
Both talk about customer-facing work, both mention writing code, both promise to shorten time to value.
One is titled Solutions Engineer. The other is titled Forward Deployed Engineer.
Hiring the wrong one is expensive, and most teams only work out which mistake they made about six months in, when the person they hired is quietly doing a job nobody asked for.
Where the confusion starts
Both roles sit in the same awkward space between engineering and the customer. Both need someone who can read a stack trace and hold a room. Both get described internally as “technical but commercial”, which is the least useful phrase in hiring.
The confusion is not really about skills. It is about timing. A Solutions Engineer and a Forward Deployed Engineer can have almost the same CV. What separates them is where in the customer relationship their work lands, and what they are measured on when it does.
What a Solutions Engineer is actually for
A Solutions Engineer works before the contract is signed. Their job is to make a buyer believe the product will work in their environment, and to be honest enough about the gaps that the deal does not fall apart in month three.
Day to day that looks like technical discovery calls, custom demo environments, security questionnaires, proof of concept builds, and translating what a prospect actually asked for into something the product team can hear. They write code, but the code is usually disposable. A demo integration that runs for two weeks and then gets deleted is a success, not technical debt.
The measure of a good Solutions Engineer is deal velocity and win rate on technical evaluations. If your enterprise deals keep stalling in the security review or dying in the proof of concept, that is a Solutions Engineer problem.
What a Forward Deployed Engineer is actually for
A Forward Deployed Engineer works after the contract is signed. Their job is to get the product genuinely working inside a customer’s environment, with the customer’s data, at the customer’s messy real scale.
That means writing production code that lives. Custom connectors, data pipelines, schema mapping, glue services that reconcile the way the customer’s world works with the way the product assumes it works. It also means sitting in the customer’s stand-ups, learning their domain properly, and being trusted enough that they tell you what is broken before they tell your account manager.
The measure of a good Forward Deployed Engineer is time to first value, and then renewal. If your customers sign happily and then take nine months to actually go live, that is an FDE problem.
The simplest test: Which side of the signature does the work sit on?
When founders ask us to help them decide, we start with one question. Is the pain you are feeling happening before the customer signs, or after?
Before the signature, and the pain is that technical buyers are not convinced, evaluations drag, or your founders are getting pulled into every demo. That is a Solutions Engineer.
After the signature, and the pain is that implementations take too long, the same integration work keeps landing on the core engineering team, or your best customers are live but not really using the thing. That is a Forward Deployed Engineer.
It sounds crude. It is right far more often than the twelve-point competency matrix people usually build instead.
When you need a Solutions Engineer first
Hire the Solutions Engineer first when your product is broadly self-serve once it is in, but the buying process is technical. Security-heavy sectors, anything touching regulated data, and anything where the buyer has an internal platform team who will ask hard questions.
The signal is usually a founder or a VP of Engineering spending more than a day a week on pre-sales calls. That is not a scaling problem you fix with a better deck. It is a headcount problem.
When you need a Forward Deployed Engineer first
Hire the Forward Deployed Engineer first when the product needs meaningful work to become useful. If every customer needs bespoke data ingestion, or the value only appears once you have wired into three of their internal systems, deployment is the bottleneck and no amount of pre-sales polish will move it.
The signal here is different. Look at where your senior engineers’ time is going. If two of your best backend engineers are permanently seconded to customer integrations and your roadmap has stopped moving, you have already got Forward Deployed Engineers. You are just paying for them out of the wrong budget and burning out the people you can least afford to lose.
What this means for your job description
Most of the briefs we see fail because they hedge. They describe a Solutions Engineer, add “will occasionally write production code”, and hope the market sorts it out. It does not. Strong candidates read the hedge and assume the role is undefined, which is usually a fair assumption.
Be specific about three things. What proportion of the work sits before the signature versus after. Whether the code they write ships to production and who maintains it. Who they report to, because a Forward Deployed Engineer reporting into Sales will eventually be measured on the wrong thing, and a Solutions Engineer buried in Engineering will never be close enough to the deal.
Compensation follows from the same decision. Solutions Engineers typically carry a variable component tied to the deals they support. Forward Deployed Engineers are usually paid closer to a senior engineering band, sometimes with a bonus linked to go-live milestones or retention. Mix those up and your offer will feel odd to everyone you send it to.
Getting the sequencing right
Plenty of companies eventually need both. The mistake is treating that as a reason to blur the first hire. Your first person in this space sets the shape of the function, writes the playbook, and interviews the next four. Whatever you hire them to do becomes the default.
So pick the pain that is actually costing you money this quarter, hire clearly against it, and give the second role its own definition when the time comes. Two well-defined hires beat one hybrid who is competent at both and accountable for neither.
If you are not sure which side of the signature your problem sits on, that is usually the more interesting conversation to have first.
Choosing the right recruitment agency is about fit, expertise, and trust.
By asking the right questions and digging into their processes, you can find a partner who not only fills roles – but helps you build a Product & Engineering team that fuels long-term SaaS growth.
Invest in a Product & Engineering Recruitment agency and accelerate your path to success.
Reach out to a member of the team here, or see more about how we can support your growth here.
