The roles compared

What forward deployed, solutions and sales engineers each do, when in the customer journey they work, and how to tell which job a posting really describes.

Forward deployed engineer

Also called FDE, FDSE, forward deployed software engineer, Delta

What: A software engineer who works inside a customer's organisation to build and ship working software on the customer's own systems and data, then feeds what they learn back to the product team.
Why: Products rarely fit a large customer out of the box. An FDE closes the gap with real code, which is why AI companies hire the role to get models into production at customers.

Watch out

Treating it as consulting with a nicer title: the job is judged on software that runs in production, not on slides.

Solutions engineer

Also called SE, solutions architect, customer engineer, solutions consultant

What: An engineer who designs how a customer will adopt a product: which parts they use, how it connects to their systems and what a first rollout looks like. Works before and after the sale.
Why: Customers buy a working outcome, not a feature list. The solutions engineer turns one into the other and gives both sides a plan they trust.

Watch out

Designing the ideal architecture instead of the one this customer's team can actually run.

Sales engineer

Also called presales engineer, technical sales, SE

What: The technical partner of an account executive during a sale. Runs technical discovery, demos, proofs of concept and security reviews, and answers the questions a salesperson cannot.
Why: Technical buyers trust other engineers. A sales engineer earns the technical win: the customer's engineers agreeing the product will work for them.

Watch out

Promising a feature or a date to win the deal, which the delivery team then has to break.

Role comparison at a glance

Also called FDE vs solutions engineer, sales engineer vs software engineer

What: A side-by-side view of when each role works, what it produces and how it is measured. Titles vary by company, so read this as the typical shape, not a rule.
Why: Most confusion about these roles comes from mixing up the timing and the output. Placing a posting on this grid tells you which job it really is.

Code

              FDE             Solutions      Sales eng.
When          after the sale  both sides     before the sale
Main output   working code    solution plan  demos, proof
Coding        daily           regular        some
Measured on   adoption, use   fit, rollout   technical wins
Travel        often on site   some           client meetings

Watch out

Picking by title alone: one company's solutions engineer is another's sales engineer.

One customer, many capabilities

What: Palantir's framing of the difference: a product engineer builds one capability for many customers, while a forward deployed engineer builds many capabilities for one customer.
Why: It explains the daily trade-off. You optimise for this customer's outcome this month, then argue for the parts that should become product for everyone.

Watch out

Building so much one-off code for one customer that nobody else can maintain it after you leave.

Pre-sale and post-sale

Also called presales, post-sales, customer journey

What: Pre-sale is everything before the contract is signed: discovery, demos, proofs of concept. Post-sale is rollout, integration, adoption and renewal.
Why: Where a role sits decides its pressure. Pre-sale work is judged on winning deals; post-sale work on whether the customer gets value and renews.

Watch out

Assuming post-sale roles have no commercial pressure: renewals and expansions depend on your work.

Adjacent customer-facing roles

Also called implementation engineer, professional services, technical account manager, TAM, support engineer

What: Roles next to these three: implementation engineers set products up, professional services deliver paid projects, technical account managers look after big accounts, support engineers fix issues.
Why: They hire more juniors than FDE teams do and build the same skills, so they are common ways in.

Watch out

Dismissing them as lesser jobs when they are often the shortest path to the role you want.

A typical week

What: A rough picture of how the week splits for each role. Real weeks swing a lot with the customer, the deal or the incident of the moment.
Why: Picturing the week is the fastest honest test of fit: if most of it sounds draining, the title will not fix that.

Code

Mon  standup with customer team, plan the week
Tue  build: data pipeline into their warehouse
Wed  build: agent workflow, test on real cases
Thu  review with users, fix what broke
Fri  write-up for product team, demo progress

Watch out

Imagining only the exciting parts: every one of these roles has a lot of follow-up and writing.

Go deeper