FredrinThe three roles look identical on a org chart and get confused constantly, but they answer to different definitions of done. A sales engineer is measured on whether the deal closes. A solutions engineer is measured on whether the customer can use what they bought. A forward deployed engineer is measured on whether the software works in production — code they wrote themselves, running inside the customer's environment, long after the contract was signed.
That last one is the real dividing line. Two of these roles support a product. One of them ships it.
What actually differs
| Sales engineer | Solutions engineer | Forward deployed engineer | |
|---|---|---|---|
| Stage | Pre-sale | Pre- and post-sale | Post-sale |
| Measured on | Deal closed | Customer adoption | Software working in production |
| Writes production code | Rarely | Sometimes, as glue | Yes, as the job |
| Whose codebase | Demo environment | Integration layer | The customer's |
| Reports to | Sales | Sales, CS, or Product | Engineering |
| Carries a quota | Usually | Sometimes | Almost never |
The quota row is the one to look at if you only read one. It tells you which organization the role really belongs to, and therefore what happens to you in a bad quarter.
What does a forward deployed engineer actually do?
An FDE embeds with a customer's team and builds production software on top of their employer's product, inside the customer's operational environment, owning the outcome end to end. Palantir coined the title around 2010; the AI deployment wave turned it into one of the fastest-growing roles in software. Monthly job listings for the role rose more than 800% between January and September 2025, according to Financial Times data, and companies from Palantir and OpenAI to Anthropic, Databricks, Cohere, Intercom and Rippling now hire for it by name.
Concretely, a week looks like: sit in the customer's standup, discover that the data model they described in the sales cycle does not match the data they actually have, write the ingestion layer that reconciles the two, deploy it into their VPC, and find out on Thursday that a compliance rule nobody mentioned means it has to run in a different region. None of that is presentation work. It is engineering, performed at an unusual distance from your own codebase, with a customer watching.
The distinguishing pressure is that you cannot escalate the outcome to someone else. A support engineer can route a hard problem back to the product team. An FDE is the product team, temporarily, for this customer.
Our breakdown of the role, with salary and hiring data goes deeper on where the title came from and what the market pays for it.
What does a solutions engineer do differently?
A solutions engineer makes the product fit the customer. That often involves real code — integrations, connectors, configuration that has outgrown a UI, sometimes a substantial internal tool. But the code is generally glue: it lives at the seam between the product and the customer, and its purpose is to make the standard product usable in a non-standard environment.
The difference from an FDE is ownership of the end state. A solutions engineer succeeds when the customer is up and running on the product. An FDE succeeds when the customer's actual business problem is solved, which may require building something the product does not do at all and may never do.
In smaller companies these two titles genuinely collapse into one job. In companies with both, the SE is closer to the customer's deployment and the FDE is closer to the customer's problem.
Where does the sales engineer fit?
Before the signature. A sales engineer is the technical half of a sales conversation: they run the demo, answer the architecture questions the account executive cannot, scope the proof of concept, and write the technical sections of the response to an RFP.
They are frequently excellent engineers. But the artifact they produce is confidence — the customer's belief that this will work — and the moment that belief converts into a contract, the SE's involvement usually tapers. Their compensation reflects it: a meaningful share of pay is variable and tied to bookings.
If you take a sales engineering job expecting to spend most of your time writing software that runs in production, you will be disappointed, and it will not be because the company misled you.
Do any of them carry a quota?
Sales engineers usually do, as a share of the team or territory number. Solutions engineers sometimes do, particularly when the role sits in a revenue org and is tied to expansion. Forward deployed engineers almost never do, and this is the cleanest test available when a job description is vague.
An analysis of over a thousand FDE postings by Bloomberry, using Revealera job-posting data, found a median salary of $173,816, roughly 70% mentioning equity, only 8% mentioning on-target earnings, and — the striking one — exactly 0% quota-carrying roles. That is an engineering compensation shape, not a sales one.
The same dataset is useful on the reporting-line question, and complicates the tidy table above: 45% of postings sit on a dedicated FDE team, 38% inside the engineering org, 14% in a GTM or sales org, and 7% in customer success. So "reports to engineering" is a strong plurality pattern rather than a rule. Worth noting these are postings, not verified org charts — what a company advertises and how the role actually sits are not always the same thing.
So: if a posting says "forward deployed engineer" and describes on-target earnings with a variable component tied to bookings, it is a sales engineering role wearing a more fashionable title. That is worth knowing before you negotiate, not after.
How does the pay compare?
Roughly, and with the usual caveat that ranges vary wildly by market and stage:
- Sales engineer — base plus variable, with the variable share often 20–40% of on-target earnings.
- Solutions engineer — mostly base, occasionally with a smaller variable component.
- Forward deployed engineer — engineering compensation, base plus equity. Glassdoor puts the average near $156K with a $125K–$198K interquartile range, while frontier AI labs pay $350K–$450K total compensation for the same title.
That last spread is the interesting part. "Forward deployed engineer" at a mid-market SaaS company and at a frontier lab are different jobs with the same name, and the compensation gap is a reasonable proxy for how much production engineering each one really involves.
Which role should you take?
A rough decision rule:
- You like the technical conversation, moving fast across many accounts, and the energy of a deal — sales engineering.
- You like making things work end to end for a named customer, and you want code to be a real but not total part of the job — solutions engineering.
- You want to write production software, you want to own whether it works, and you are willing to do that in someone else's environment with their constraints and their standup — forward deployed engineering.
The FDE path has one non-obvious cost worth naming: you accumulate deep knowledge of customers rather than depth in a single codebase. Some engineers find that the most interesting thing they have ever done. Others find, three years in, that they have shipped a great deal and can point to very little of it.
Does the AI wave change any of this?
It changes the FDE role most, because the FDE role is the one that ships code.
An engineer embedded with a customer used to be limited by how much they could personally write between meetings. With coding agents — Claude Code, Codex, Cursor, Gemini CLI — the writing is no longer the constraint. What is left is scoping, reviewing, and shipping, which happens to be exactly what an FDE was already doing between the writing.
The practical consequence is that FDEs are among the first engineers with a genuine reason to run several streams of work at once, across several clients. We wrote about how that actually works in practice, and about what it takes for AI-written code to survive a client's review.
It also changes which tools matter. An editor optimized for one person typing in one repository is a poor fit for someone supervising four agents across four client repositories — a difference we lay out in Fredrin vs Cursor. The tool stack post covers the rest of the layers.
FAQ
Is a forward deployed engineer just a consultant? No. A consultant is typically paid for time and leaves an artifact. An FDE is a full-time employee of a product company, building on top of that company's product, with the product's success as the goal. The customer relationship looks consulting-shaped; the incentives do not.
Can a sales engineer become an FDE? Frequently, and it is one of the more common paths. The customer-facing muscle transfers directly. The gap to close is production engineering: shipping, operating, and being on the hook when it breaks at 2am.
Do FDEs travel? Less than the reputation suggests. Most FDE work in 2026 is remote with periodic on-site visits, though the true on-site roles still exist in defense, healthcare, and finance where the data cannot leave the building.
Which title should I search for? All of them, plus "deployment engineer", "implementation engineer", "customer engineer", and "solutions architect". The titles are not standardized, so read the responsibilities and check for a quota rather than trusting the header.
Is there a career ladder for FDEs? Yes, and it usually forks: deeper into engineering (staff, architecture, or back into core product) or outward into leadership of the deployment org itself. Both are real; they reward different things, and it is worth knowing which one you are aiming at before your third year.
Fredrin is a desktop kanban for running many AI coding agents in parallel — every ticket gets its own branch, worktree, and agent session, so one engineer can keep several client engagements moving at once. It's free on macOS and Windows, on the AI subscription you already pay for: fredrin.com.
