How to Spot a Relabeled Forward Deployed Engineer: 5 Questions to Ask Any AI Partner

Key Takeaways

• The title is spreading faster than the job. Forward deployed engineer postings grew more than tenfold in a year, and a big share of them describe a sales engineer with a new name.
• Two things define the role: authority and accountability. Can the person change the software, and do they own the result? Everything else is detail.
• A relabel is a pricing problem as much as a skills problem. You pay builder rates and get demo-and-handoff work.
• Five plain questions expose it. Who builds after the demo, what happens when the product falls short, how the person is paid, what outcome they own, and where the lessons go.
• The contract tells you the truth. If you carry all the delivery risk, the engineer is not really forward deployed, whatever the proposal says.

Forward deployed engineering, as overused as the term is now, used to mean something specific. Today it's on every AI proposal I see. That should make you a little suspicious.

The numbers explain why. Bloomberry analyzed roughly 1,000 forward deployed engineer job postings and found the title grew 1,165% year over year from January through October 2025. The same analysis found that companies use the one title for three different jobs. About 60% of postings describe an engineer who embeds with customers and builds production systems. About 30% describe what the author calls a solutions or sales engineer role "that got rebranded" as FDE: demos, proofs of concept, product configuration, then a handoff to an implementation team. Another 10% describe internal tooling work that has little to do with customers at all.

So close to a third of the market is selling the label without the job. And if you're the buyer, you usually can't tell from the proposal. Both versions promise "embedded engineers." Both show up to the kickoff. The difference shows up a few weeks in, when the demo works and something in your real data doesn't.

My test is short. A forward deployed engineer is defined by two things: authority and accountability. Authority means they can change the software to fit your problem, without filing a ticket and waiting. Accountability means they own the outcome you were promised. A list of finished milestones doesn't count. Take either one away and you have a solutions engineer with a better title. Which is fine. Just don't pay for the other thing.

The Title Changed Faster Than the Job

The role comes from Palantir, where these engineers were called Deltas. According to The Pragmatic Engineer, until 2016 Palantir employed more of them than regular software engineers. The idea was simple: put a strong engineer inside one customer, give them real access to the product and the code, and let them build whatever the customer needs to get the outcome.

Then AI made the model fashionable. Andreessen Horowitz called it the hottest job in startups in mid-2025, on the logic that enterprise AI needs deep integration work before it delivers anything. The logic is right. Enterprise AI products break when they meet real systems of record, real permissions, and real edge cases. Somebody has to sit in the mess and fix it.

But the hot title arrived before the supply of people who can do the work. Real builder FDEs are expensive. Bloomberry put the median base salary at $173,816 for postings that disclosed pay, with 70% offering equity. Renaming an existing solutions engineer costs nothing.

Check the daily work behind the title

When a proposal says "forward deployed," treat it as a claim to check. The title tells you what the vendor wants you to believe. The person's daily work tells you what you're buying.

Authority and Accountability Are the Whole Definition

I keep coming back to these two words because everything else (travel, seniority, the tech stack) varies a lot between good FDEs. These two don't.

Authority is about what happens when the product can't do what you need. A solutions engineer configures what already exists and writes a feature request for the rest. A forward deployed engineer writes the code. At a software vendor, that means shipping changes into the vendor's own platform. At a services firm, it means building the missing piece in your environment, in your repos. Either way, the gap gets closed by the person in the room.

Accountability is about what they're measured on. Marco's write-up on the forward deployed engineer model puts the warning bluntly: if a vendor renames a solutions engineer without changing authority and accountability, you're buying a relabel. A real FDE stays responsible for the outcome promised at the start, which is a very different thing from "delivered the sprint plan."

Bloomberry's data lines up with this. The builder postings described 70% to 90% of time spent coding and no quota. The rebranded postings described 30% to 40% coding, commission, and a quota. Same title. Different incentives. Different results.

Test both, every time

Any one of the five questions below can be answered well by a good salesperson. Authority and accountability are harder to fake when you ask about them from several angles.

Five Questions That Separate a Builder From a Relabel

These are the questions I'd ask any AI partner before signing, including us. You're listening less for the answer itself and more for whether it's specific.

1. Who builds it after the demo works?

This is the fastest tell. The rebranded role, in Bloomberry's words, hands off to implementation teams instead of building everything themselves. So ask directly: once the proof of concept works, who writes the production code? Is it the same person? If the answer involves a new team, a different statement of work, or an offshore delivery center, the person you met is a sales engineer.

A good answer sounds like: "The same two engineers. They'll be in your repos by the end of the first sprint."

2. What happens when your product can't do what we need?

Every AI deployment hits this wall. The model is the easy part. Your data is messy, your workflow has exceptions nobody wrote down, and the product doesn't quite fit.

A relabeled FDE files a feature request and gives you a workaround. A real one has the authority to change the code. Ask for an example: "Tell me about a time an engineer changed your platform for one customer. How long did it take?" If nobody can name one, they don't have that authority.

(For a services firm like PressW, this question lands a little differently. We don't own a product to change. The fair version is: when the off-the-shelf tool falls short, will your engineer build the missing piece, or tell us to wait for the vendor?)

3. How is this person paid, and who do they report to?

This feels rude to ask. Ask anyway. Compensation tells you what someone is optimizing for. If the engineer carries a quota or earns commission, their job ends when the contract is signed or renewed. Bloomberry found 0% of builder postings were quota-carrying. The rebranded postings were.

Reporting lines matter too. An engineer who reports into sales gets pulled toward the next deal. One who reports into engineering, or into a dedicated delivery team, stays on your problem.

4. What outcome are you accountable for, and what happens if we miss it?

Milestones are easy to hit. "Discovery complete." "Prototype delivered." "Training session held." None of those mean the system works.

Ask the partner to name the business outcome they're signing up for (hours saved, cycle time, error rate, whatever fits the workflow) and what changes in the relationship if it isn't reached. A real FDE engagement has an answer. A relabel points you to the project plan.

5. What did your last deployment teach you, and where did that lesson go?

Forward deployed work is supposed to compound. What an engineer learns inside one company should go somewhere: into the product, into a playbook, or into your own team's documentation. Ask for one concrete lesson from a recent engagement and where it ended up. If the honest answer is "nowhere," you're paying for a consultant whose knowledge leaves with them.

A Relabel Isn't Always a Bad Deal

I want to complicate my own point. Solutions engineers are useful. If you've already bought a well-built product and need it configured, demoed to your team, and rolled out, a good solutions engineer is exactly the right person. You don't need someone writing custom code.

The problem is the mismatch. You're told you're getting a builder, you budget for a builder, and you plan your timeline around a builder. Then the hard part of the project arrives and the person in the room can't do it. The real cost of a relabel shows up as lost months, the time it takes before anyone admits the job needs a different person.

Buy the role you actually need

If your problem is configuration and adoption, buy configuration and adoption, and pay for that. If your problem is that nothing off the shelf fits your workflow, you need someone with authority to build. Decide which problem you have before you read proposals.

The Contract Tells You More Than the Pitch

Pitches are written to sound the same. Contracts aren't.

Look at who carries the delivery risk. A license-plus-hours structure puts the risk on you: the vendor gets paid whether the system works or not. An engagement where the partner commits to a working system, in your environment, with a measurable result, moves some of that risk back to them. Marco's piece makes the same point about contract structure, and I think it's the most underused test buyers have.

Then check where the work lives. Code, prompts, and evaluation harnesses in your repositories mean the engineer was building for you. Work that lives in the vendor's environment, or in a services team you never meet, means somebody else is doing the building.

Read the statement of work for verbs

Count the verbs. "Advise," "support," "configure" and "facilitate" describe a solutions engagement. "Build," "deploy," "ship" and "hand over" describe a forward deployed one. It's a crude test. It works more often than it should.

Mid-Market Companies Pay the Most for a Relabel

A large enterprise can absorb a slow quarter. It has internal engineers who can pick up the slack when a vendor's "forward deployed" team turns out to be a demo team.

A mid-market company or a PE-backed portfolio company usually can't. There's often no internal AI team to fill the gap, and the hold period doesn't wait. When the person you hired can't build, the project stalls, and the people who were supposed to use the system lose faith in it. That loss of trust is the harder thing to fix. And nothing burns goodwill with an operations team faster than a pilot that never becomes a tool.

That's why we built PressW's Forward Deployed AI Engineering around senior engineers who work in the client's environment. They're in the repos and attending the team's rituals within the first sprint. Code, documentation and evaluation harnesses stay in the client's repos, and knowledge transfer happens every sprint instead of in the last week.

Make the first sprint the real test

Whatever a partner says in the pitch, the first sprint shows you the truth. Did the engineers get access, sit with the people who do the work, and merge code? Or did you get a discovery deck? Write down what you expect from sprint one before you sign, then check.

Ask the Questions, Then Watch What Ships

I don't think the FDE label is going away. It's too useful, and the underlying idea is right: enterprise AI needs builders who sit with the business. I also don't know where the title settles. My guess is it splits, the way "data scientist" did, into a few distinct jobs with clearer names. Until then, buyers carry the burden of checking.

So ask the five questions. Listen for specifics. Then watch the first sprint, because that's where authority and accountability either show up or don't. And if you'd like a second opinion on a proposal you're looking at, or want to see how we'd run your first sprint, Book a Discovery Call.

FAQ