Forward deployed engineering: the complete guide / Compared with other roles
Forward deployed engineer vs solutions engineer
A solutions engineer is anchored to a specific product: they configure it, extend it within its supported surface, and make it fit the customer. A forward deployed engineer is anchored to the customer's problem and builds whatever is missing, including parts the product does not cover. The test is what happens when the product cannot do what the customer needs. A solutions engineer files a feature request. A forward deployed engineer writes the code. This is a closer comparison than sales engineering, and the two titles are used interchangeably by companies who mean different things.
Key takeaways
- The test is what happens when the product cannot do the thing: a solutions engineer files a feature request, a forward deployed engineer builds it.
- A solutions engineer's scope is bounded by the product's supported surface. A forward deployed engineer's scope is bounded by the customer's problem.
- Both work after the sale, which is why this comparison is harder than the sales engineering one. Timing does not separate them, authority does.
- Companies use the two titles interchangeably. Ask whether the role writes code outside the product's own codebase, and whether it can ship something the roadmap never planned.
This is the closest of the comparisons, and the one where job titles are least reliable. Both roles are post-sale, both are technical, both are customer-facing, and both are senior. The difference is authority over what gets built.
The test
Ask what happens when the customer needs something the product cannot do.
A solutions engineer files a feature request, finds a supported workaround, or sets expectations about the roadmap. Their job is to get the best result available from the product as it exists.
A forward deployed engineer builds it. They may build it in the customer's environment, they may build it as an extension, and if it turns out to be broadly useful they may push it back into the product. Their job is the customer's outcome, and the product is one of the tools.
Anchored to the product, or anchored to the problem
A solutions engineer is anchored to a product. They know it deeply, they know its edges, and their value is that depth. Across a portfolio of customers they apply the same product to many situations, and they get better at it every time. Building something ad hoc would be unusual in the role.
A forward deployed engineer is anchored to a problem inside one organization. They may use your product for 70 percent of the answer and write the other 30 percent, and that 30 percent is where their value sits. Building something ad hoc is the job.
This is why the roles feel similar in a good week and diverge sharply in a bad one. When the product fits, both roles look like configuration. When it does not, one role escalates and the other builds.
Why the titles blur
Two reasons, and both are worth knowing when you read a job advert or a proposal.
The first is that forward deployed engineering became the more attractive title. Demand for it grew 1,165 percent year over year comparing January to October 2025 with the same period in 2024, according to the analysis of 1,000 postings published that November. When a title becomes the one candidates want, adjacent roles get relabelled.
The second is that the boundary genuinely moves as a company matures. Early on, almost everything is custom, so every post-sale engineer is effectively forward deployed. As the platform grows, more of the answer is configuration, and the same person's work drifts toward solutions engineering without anyone changing the title. That drift is healthy, and it should be noticed and named, because it changes what you should hire for next.
What this means for a buyer
If a vendor offers you a solutions engineer, you are getting product expertise. That is valuable and it is bounded: when you hit something the product does not do, you will be told about the roadmap.
If a vendor offers you a forward deployed engineer, ask two questions. Will they write code outside your instance of the product, in our repository? And can they ship something your roadmap never planned, without a product decision unblocking it?
Two yeses means the offer is genuine. A hesitation on the second usually means the role has the authority of a solutions engineer with the title of a forward deployed one. Our questions to ask a vendor page covers the rest.
What this means if you are hiring
Decide which authority you are granting before you write the advert, because the two roles attract different people and reward different skills.
If the answer is "configure our product expertly across many accounts", hire solutions engineers, invest in product depth, and build a strong path for feature requests to reach the roadmap.
If the answer is "solve the customer's problem even where our product falls short", hire forward deployed engineers, give them repository access and the authority to build, and then run a productization cadence so what they build in the field has a route into the platform. Without that route you will accumulate customer-specific code with no owner, which is the failure mode Marty Cagan warns about when embedded engineers are separated from product.
The honest overlap
At many companies one team does both, and the ratio shifts by account. A large customer with an unusual environment gets forward deployed treatment. A mid-market customer with a standard setup gets solutions engineering. Same team, same titles, different mode.
That is a reasonable way to run it, provided somebody decides which mode each account is in, deliberately, rather than discovering it three months into an engagement that was scoped as configuration and turned into a build.
Next: FDE vs consultant, or FDE vs systems integrator for the procurement version of the same question.
Best for
- Deciding how much authority a post-sale technical role should have over what gets built
- Reading two job adverts that use different titles for the same work, or the same title for different work
- Recognising when your own post-sale team has drifted from building to configuring
Avoid if
- The question is really about presales, which the sales engineer comparison covers
Verify before you commit
- Ask what happens when the product cannot do what the customer needs
- Ask whether the role writes code outside the product's own instance, in the customer's repository
- Ask whether the role can ship something the roadmap never planned without a product decision first
Common questions
What is the difference between a forward deployed engineer and a solutions engineer?
A solutions engineer is anchored to a product and gets the best available result from it as it exists. A forward deployed engineer is anchored to the customer's problem and builds whatever is missing, including parts the product does not cover. The test is what happens when the product cannot do the thing: one files a feature request, the other writes the code.
Are solutions engineer and forward deployed engineer the same job?
They are used interchangeably and they are not the same. Both are post-sale, technical and customer-facing, so timing does not separate them. Authority does: whether the role can build outside the product's supported surface and ship something the roadmap never planned.
Why do companies use these two titles inconsistently?
Because forward deployed engineer became the title candidates want, with postings up 1,165 percent year over year in 2025, so adjacent roles got relabelled. The boundary also genuinely moves as a company matures: early on everything is custom, and as the platform grows the same person's work drifts toward configuration.
How do I check whether a vendor's forward deployed engineer is really one?
Ask two questions. Will they write code outside our instance of your product, in our repository? Can they ship something your roadmap never planned, without a product decision unblocking it? Hesitation on the second usually means the role has solutions engineering authority with a forward deployed title.
Can one team cover both modes?
Yes, and many do, shifting mode by account: forward deployed treatment for large customers with unusual environments, solutions engineering for standard mid-market setups. The requirement is that somebody decides the mode deliberately at the start, rather than discovering it three months into an engagement scoped as configuration.
Related reading
How to add LLM integration to an existing product without breaking it
Most teams do not need a ground-up AI rebuild. They need one strong feature, added in a way that cannot take the rest of the product down with it.
How to say no to a feature request
When building got cheap, the reason to decline stopped being cost. It is now that every feature you keep makes every future change slower, and nobody sends an invoice for that.
More in Compared with other roles
Forward deployed engineer vs solutions architect
A solutions architect designs how a system should be implemented and hands that design to someone else to build. A forward deployed engineer writes the implementation themselves, inside the customer's environment, and stays accountable until it runs in production. The single test that separates them is who merges the pull request. Both roles are senior, both are customer-facing, and both can hold the same technical opinions. Only one of them is answerable when the deployment does not work.
Forward deployed engineer vs sales engineer
A sales engineer works before the contract is signed and is measured on whether the deal closes. A forward deployed engineer works after it is signed and is measured on whether the system reaches production. The test is the compensation plan: across 1,000 job postings carrying the forward deployed title, 70 percent mentioned equity, 8 percent mentioned commission or on-target earnings, and none were quota-carrying. Where a role does carry a number, the incentive ends at signature, and knowing that before you hire or buy is worth more than any duty list.
Forward deployed engineer vs consultant
A consultant delivers an agreed scope: the statement of work defines done, and the engagement ends when the scope is delivered. A forward deployed engineer is accountable for an outcome, so when the plan turns out to be wrong they change the plan rather than raising a change request. The test is what happens on the day somebody discovers the original approach will not work. That day arrives in most engagements, and the two models respond to it in opposite ways.
Forward deployed engineer vs systems integrator
A systems integrator connects systems that already exist, using each product as the vendor intended, and its skill is knowing how the pieces fit. A forward deployed engineer writes the part that does not exist yet. The test is whether your problem is solved by wiring together things that are already built. If it is, an integrator will do it faster and cheaper. If the answer requires code nobody has written, an integrator will scope it as custom development and subcontract it, which is the moment to ask who is actually accountable.
Forward deployed engineer vs staff augmentation
Staff augmentation adds senior engineers to your team, working under your direction, on the roadmap you already own. Forward deployed engineering hands an outcome to an outside team who decide how to reach it and are accountable for it running. The test is whether you have someone senior on your side making the technical calls. If you do, buy hands. If nobody is making those calls, buying hands means buying capacity that waits to be told what to do. This is the fork most buyers are actually standing at, and the two are often sold under the same words.