Forward deployed engineering: the complete guide / Compared with other roles
Forward deployed engineer vs solutions engineer
A solutions engineer is tied to a specific product: they configure it, extend it within the features it supports, and make it fit the customer. A forward deployed engineer is tied 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.
Published September 8, 2026. Editorial.
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 limited to what the product supports. A forward deployed engineer's scope is limited 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 release 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 add it to the product. Their job is the customer's outcome, and the product is one of the tools.
Tied to the product, or tied to the problem
A solutions engineer is tied to a product. They know it deeply, they know its limits, 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 tied 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 is. 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 get mixed up
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 moves toward solutions engineering without anyone changing the title. That change 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 has limits: when you need 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 release something your roadmap never planned, without first waiting for a product decision?
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 regular productization process so what they build at customer sites 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 moved from building to configuring
Avoid if
- The question is really about presales, which the sales engineer comparison covers
Check before you decide
- 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 release 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 tied to a product and gets the best available result from it as it exists. A forward deployed engineer is tied 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 what the product supports and release 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 moves 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 release something your roadmap never planned, without first waiting for a product decision? 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 complete AI rebuild. They need one strong feature, added in a way that cannot cause the rest of the product to fail.
How to say no to a feature request
Building is cheap now, so the reason to decline a feature is different: 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 is signed. 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 sales target, 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 connecting 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 decisions. If you do, buy extra engineers. If nobody is making those decisions, buying extra engineers means paying for people who wait 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.