# FDEs for hire: when a vendor job title becomes a service line

> The job title is the same, but the employer decides what success means. Different employers judge FDEs by almost opposite standards, and that decides which skills you need.

Original: https://fdetimes.net/en/analysis/fde-as-a-service-vendor-vs-outsourced/

The services page of &above, a UK company, sums up its business model in one sentence: it hires and manages engineers, and those engineers build alongside your team.

What is on sale here is the forward deployed engineer. A few years ago the title belonged almost entirely to staff at software companies such as Palantir.

At first sight this is outsourcing with a fashionable new name. But once FDE becomes a service line, with firms that specialise in hiring engineers out, the question "what does an FDE do?" turns on another one: who pays the FDE?

For an engineer with two to eight years of experience who is aiming for this career, the difference matters. Two job ads can carry the same title, yet different employers will judge you by almost opposite measures. A skill that makes you stand out at one employer may count for nothing at another.

## The FDE title no longer belongs to vendors

Tom Hollands of a16z argues that at Palantir, solutions and integration engineering had been seen as low-status work, and the FDE title raised its standing. A job title that carries prestige will sooner or later be sold.

Accenture, McKinsey, Deloitte and many others now run, fund or train FDE teams together with the AI labs.

According to one AI newsletter, OpenAI and Anthropic have each set up their own FDE joint ventures in recent months, and AWS is investing in an FDE unit.

Below the big names is a layer of smaller firms, such as &above and Entrans, that sell FDEs as a standalone service.

SD Times argues that FDEs complement traditional consultants rather than replace them, because they cover the ground consultants tend to handle poorly. It also notes that an FDE can be a direct employee of a technology vendor such as Salesforce. So the title no longer tells you who the engineer works for.

## Whoever pays decides what you optimise for

Webfuse, comparing FDEs with consultants, says the difference lies in the business model. An FDE works for a product vendor, so every deployment helps the vendor sell its software and keep the customer.

A vendor FDE who makes a system work so well that the client no longer needs the product has worked against their own employer.

The outsourced FDE has the opposite incentive. &above describes its offer as embedding senior engineers in the client's team, working on a scoped workflow, with a commitment to transfer capability to the client's staff. It also promises that by the end of the engagement the client's team owns the system and can extend it without &above.

Entrans draws a line between its offer and staff augmentation. In its view, FDE-as-a-Service has to go on to build and deploy the solution, not stop at supplying hours. These three definitions lead to three very different measures of success:

| Model | Who pays | Success is measured by | Main risk for the client |
|---|---|---|---|
| Vendor FDE | Software company | Software sold, customer retained | Dependence on the vendor |
| FDE-as-a-Service | Services firm | A working system the client owns and extends | Deep access held by outsiders |
| Staff augmentation | Staffing firm | Hours supplied | Nobody is accountable for deployment |

**Key point:** Before asking how good an FDE is, ask who pays them.

## Can the "you won't need us" promise hold?

A handover does not happen just because a firm promises one. According to The Register, Gartner's March guidance tells buyers to be wary of poorly designed FDE engagements, which can leave clients heavily dependent on the vendor.

Forrester's June report also warns that the pull of fast results easily creates blind spots and carries considerable risk.

These are two sides of the same problem. The faster the FDE moves, the more the knowledge of the system collects in the head of whoever writes the code, while the client's team looks on.

&above's promise that clients will extend the system without it speaks directly to the dependence Gartner describes. But the promise is only worth something if it becomes handover deliverables that can be checked.

Picture an insurer that hires an FDE team to automate the triage of claims.

Suppose that, on the last day, the in-house team has never deployed a change on its own, never handled an incident on its own and cannot read the logs to see where the model went wrong. Then the engagement has created dependence, however well the code runs.

A practical test is to ask the client's team to add a new claim type while the FDE is still on site, but with the FDE barred from touching the keyboard.

Someone on the client side should sign off each step; the FDE should not mark it done. The client's tech lead confirms deployment, the operations on-call engineer accepts incident handling, and the workflow owner signs off the final test.

## Access: selling point or risk?

Some providers market the fact that their engineers work inside the client's VPC as a security feature, because data never leaves the company's infrastructure. Gartner looks at the same detail from the opposite side: FDEs often have full-stack access, both to the client's environment and to the vendor's codebase.

Both views are correct, and the person who has to resolve the tension is usually the FDE. Working inside the VPC keeps data in one place, but it also means an engineer who is not on the client's payroll holds the keys to its most critical systems.

A conscientious outsourced FDE treats access as part of the handover plan.

From the first week, they record what access they have been granted, why they need it and the date they will give it back, and they have the client's security team approve that list.

For a client, that list is more persuasive than any copy on a services page.

## If you want to enter the field this way

If you are aiming for a firm that hires out FDEs, be clear about what you are being hired to do. In this model, the product is the capability you leave behind with the client after you go, not what you build yourself.

How each side describes itself is enough to tell them apart. &above writes of "senior engineers embedded in your team, working on a scoped workflow", with the goal of the client's team owning the system. Webfuse describes the vendor FDE with a very different goal: deployments that help sell and retain software.

When you read a job description, see which way it leans. Phrases such as "scoped workflow", "capability transfer" or "embedded with client team" suggest you will be judged on handover. If the ad talks only about hours, availability and tech stack, it is probably staff augmentation under a new title.

On a CV, a line such as "built a document classification pipeline" tells only half the story. Add the other half: how many people on the client's team took over the work, and what they went on to do by themselves after you left.

Runbooks, pair-programming sessions with the client's engineers and an occasion when you revoked your own access unprompted are the evidence to offer when applying to this model.

At a vendor, a good FDE makes clients not want to leave the product. At a firm that hires out FDEs, a good FDE makes clients no longer need them, and the market needs both kinds of engineer.

**Try this week:**

- Take a project you have deployed and rewrite one CV line using this formula: the specific workflow, who you handed it over to, and what the client's team went on to do by themselves.
- Read three open FDE job ads, note whether the employer is a vendor, a services firm or a consultancy, and write down the success criteria each ad implies.
- For the system you currently look after, list every access right you hold and write a plan for revoking them on handover day.

## Sources

- [Forward Deployed Engineers as a Service | &above](https://www.andabove.com/services/forward-deployed-engineers.md)

- [FDE as a Service Providers (Entrans)](https://www.entrans.ai/blog/fde-as-a-service-providers)

- [Forward Deployed Engineer vs Technical Consultant (Webfuse)](https://www.webfuse.com/blog/forward-deployed-engineer-vs-technical-consultant)

- [Forward-Deployed Engineers vs. Implementation Consultants: The Crucial Distinctions](https://sdtimes.com/software-engineering/forward-deployed-engineers-vs-implementation-consultants-the-crucial-distinctions/)

- [Palantir's fondness for French food cooked up tech's latest fad – forward-deployed engineers](https://www.theregister.com/a/5300360)

- [AWS Bets $1 Billion to Embed Engineers Inside Customers as Amazon Joins OpenAI and Anthropic in Forward Deployed AI Race](https://www.inbenta.com/ai-this-week/aws-bets-1-billion-to-embed-engineers-inside-customers-as-amazon-joins-openai-and-anthropic-in-forward-deployed-ai-race)