Forward deployed engineer vs software engineer: which one to hire next

Palantir created the forward deployed engineer role. On Levels.fyi, its forward deployed engineers report a median total pay of $205,000 a year, from 223 submissions. Its software engineers report $277,916. These are self-reported figures from one company, read on 29 September 2026, so treat them as one data point.

The useful way to separate the two jobs is by the problem each one is hired to solve.

If you are deciding who to hire next, three questions settle it: where the unknown sits, whether the work repeats across customers, and who runs the system after release. First, what the two roles share, because it is more than most comparisons admit.

What the two roles share

Both write production code, and both are held to the same engineering standard. First Round Review, in its February 2026 guide to hiring forward deployed engineers, reports that interviews for the role match the standard of those for ordinary software engineers. It quotes Ironclad describing its best forward deployed engineers as people who "could have also gone on to become a staff engineer at a top tech company."

The hiring data says the same. Bloomberry analysed 1,000 forward deployed engineer job postings and found that 45 percent of the career paths into the role started in backend or full-stack software engineering. 60 percent of the postings asked for three to five years of experience. Python appeared in 66 percent of them. None carried a sales quota.

So a forward deployed engineer is a software engineer. The title describes where the engineer works and what they answer for, and the coding skill underneath is the same.

Where the two roles differ

A software engineer on a product team usually receives a problem that someone has already defined. A product manager has talked to customers, written a specification, and ranked it against other work. The engineer's job is to build it well, for every customer at once, and keep it running.

A forward deployed engineer receives a problem that nobody has defined yet. Marty Cagan of SVPG describes the role as engineers who "embed with the target customer in order to deeply understand their environment, their problems, and what's truly required to solve those problems." The forward deployed engineer works in the customer's systems, on the customer's data, beside the customer's staff, and writes the code that makes the product work there.

Five differences follow from that:

• Who defines the problem. The software engineer usually gets it from a product manager. The forward deployed engineer defines it at the customer, often in the first two weeks.
• Where the work happens. The software engineer works in the company's own codebase. The forward deployed engineer works in the customer's environment: their data, their login system, their approval process. Bloomberry found that 68 percent of postings required travel, and where a figure was given, 50 to 75 percent travel was common.
• What success means. The software engineer is measured on the product: its quality, speed and reliability for all users. The forward deployed engineer is measured on one result: the system running in production at that customer.
• Breadth or depth. The software engineer goes deep in one part of the system. The forward deployed engineer needs enough of everything (data, integration, deployment, a meeting with the customer's executive) to finish the job without a team behind them.
• Who they talk to. A software engineer may go weeks without speaking to a customer. A forward deployed engineer speaks to one every day.

One caution before the questions. Distance from users costs a product team too. DORA's research finds that teams that focus on the user have 40 percent higher organizational performance. A software engineer who never meets a customer is a choice a company makes, and a poor one. The forward deployed role exists for the cases where meeting users is still too little, because the problem only becomes clear inside the customer's own systems.

Three questions that decide which to hire

1. Where does the unknown sit?

If the hard part is technical (performance, scale, a difficult algorithm) and the customer's need is already clear, hire a software engineer. If the hard part is working out what the customer actually needs, and that answer lives in their data and their processes, hire a forward deployed engineer.

Here is a test you can run in a meeting. Can someone write a specification for this work from outside the customer's company, today? If yes, a software engineer can build it. If the honest answer is "only after we see their data," you need someone inside.

Take an AI agent that answers support tickets for a large insurer. The model, the prompt and the interface can all be specified at your office. Which of the insurer's internal systems hold the policy data, which fields are wrong, and who has to approve the agent before it touches a customer: nobody at your office knows that, and nobody at the insurer has written it down. That second list is the forward deployed engineer's work.

2. Does the work repeat across customers?

A forward deployed engineer costs a full salary for each account they serve. If each new customer needs the same setup, that work belongs in the product, built once by software engineers, with a setup tool and documentation. Sending a forward deployed engineer to do identical work at every account turns engineering salaries into a cost that grows with every sale.

The rule we use: if the third customer needs the same thing as the first two, stop sending engineers to do it by hand and put it in the product. At that point the forward deployed engineer's most useful output is a written list of what repeated, so the product team can build it.

This is also how the two roles work together well. The forward deployed engineer finds what customers need in practice. The software engineers turn the repeated parts into product. A company that has only one of the two either builds the wrong thing well or builds the right thing again for every customer.

3. Who runs the system after release?

A software engineer's code joins a product the company already operates. A forward deployed engineer's code often runs inside the customer's environment, and someone has to operate it after the engineer leaves. Without a plan for that, the engagement never ends, and the customer depends on one person's knowledge.

Decide the handover before the work starts: a named date, a named person on the customer's side, and a test where that person releases a change without help. If you cannot name those three, you are hiring a permanent on-site engineer, and you should budget for the role on that basis.

The failure on each side

Hiring the wrong one produces a predictable failure.

Put a forward deployed engineer on repeatable product work and you get custom code for each account. Each customer's version moves away from the product over time, and every upgrade becomes a separate migration project for each of them. The fix is to keep that engineer's code to the parts that belong to one customer, such as its integrations, and keep shared logic in the product.

Put a software engineer on an undefined customer problem from headquarters and you get a well-built feature that solves the problem as a ticket described it. The real problem, in the customer's data, stays unsolved, and the gap appears at go-live. That is the most expensive moment to find it, because the customer's staff, their approval process and your contract date are all waiting on the same fix.

Hire, or buy the capacity

Hiring a forward deployed engineer takes a normal engineering hiring cycle. Bloomberry put the median base salary across the postings it analysed at $173,816, and 70 percent of those postings mention equity on top. Then the new hire needs a few engagements to learn how to run one well. If you need one customer deployment in production this quarter, hiring is the slower route.

That is the case for buying the capacity instead. Reveneau's forward deployed engineers work inside your environment or your customer's, on the real data and the real approval process, until the system runs in production. AI writes the code, and every change has to pass an eval suite written from the specification before it is released. We use AI instead of hiring more engineers, so the same build takes a small team, and that saving goes into your price rather than our margin. Two dates go into the contract before we start: a production date and a handover date.

If your work is already specified and your own senior leaders direct it, senior engineers under your direction will do the job for less. That is staff augmentation, and the two models are compared in full in forward deployed engineer vs staff augmentation.

For the whole subject, the forward deployed engineering guide covers the role in depth, including what it costs and when it is the wrong answer.

If you have a deployment that has to reach production this quarter, tell us what it is. We will tell you which of the two engineers it needs, including when the right answer is to hire your own.

Our thanks to the teams at First Round Review, SVPG and Bloomberry, whose reporting made this comparison possible to write with real numbers. The rule underneath all of it is short: hire for the unknown you actually have.

Sources

• Levels.fyi, Palantir Forward Deployed Engineer salaries, read 29 September 2026.
• Levels.fyi, Palantir Software Engineer salaries, read 29 September 2026.
• First Round Review, So You Want to Hire a Forward Deployed Engineer, 24 February 2026.
• Henley Wing Chiu, Bloomberry, I analyzed 1,000 forward deployed engineer jobs, 18 November 2025, updated 25 January 2026.
• Marty Cagan, SVPG, Forward Deployed Engineers, 17 September 2025.
• DORA, User-centric focus, read 29 September 2026.