How Do I Become an FDE, Or Am I Already One?

Somebody asked me last month what I do now, and I got about four words in before I stopped, because the honest answer was a list and the list was embarrassing.

I scoped it. I wrote the business case. I built the proof of concept. I demoed it to the people who sign things. I wrote the integration. I stood it up in their cloud. I am on the call when it falls over. Somewhere in there I also wrote the project plan, chased the data owner for access, and explained to a compliance officer what a system prompt is.

There is a job title for that now, and the people holding it are getting paid a lot of money. So the question in the headline is not rhetorical. It is the actual question, and it has two halves: how do you become a forward deployed engineer, and how do you tell whether you have quietly been made into one already without the pay rise?

What an FDE actually does, according to the job adverts

Start with the source material rather than the discourse, because the discourse is froth and the job descriptions are surprisingly specific.

The role came out of Palantir, where the internal name was Deltas, and where — by most accounts — forward deployed engineers outnumbered software engineers until around 2016. The model was: do not sell the customer a platform and a training course. Put your engineer inside their building, next to the person with the problem, and have them build the thing that solves it in the customer's own environment.

OpenAI's advert puts it about as plainly as a corporate job description ever does. Forward deployed engineers, it says, lead complex deployments of frontier models in production, embedding with customers where delivery is urgent and ambiguity is the default. Anthropic's version reads similarly, with the emphasis on sitting down with the people who actually do the work — clinicians, operations staff — and building into the workflow they already have.

The line everyone uses to separate this from consulting is the clean one: a consultant delivers a report, an FDE delivers a running system and stays until it runs. That is a real distinction and it is worth taking seriously, because it is the thing your CV has to prove.

Underneath the positioning, the technical asks in current adverts cluster into six areas, and there is very little variance between companies:

• Evaluation frameworks — building the suites that catch a bad output before a customer does
• Retrieval pipelines — chunking strategy, vector store configuration, the unglamorous data plumbing
• Agent frameworks — hands-on with the orchestration layer, whichever one is fashionable this quarter
• Production observability — logging, tracing, knowing what the thing did at 3am
• Security and compliance — deploying inside somebody else's VPC, under somebody else's audit
• Prompt architecture — designing prompts that hold up at production scale rather than in a demo

And then the part that is not technical at all. Reported figures put 30–40% of the week on customer discovery — conversations, not code. OpenAI's postings advertise up to 50% travel. The interviews are described as testing communication and customer empathy on equal footing with coding ability, which is not how a normal engineering loop works.

So it is everything, then

Yes. Read that list again as an org chart and it is six people.

Discovery and requirements is a business analyst. The business case and the demo to the buying committee is a solutions engineer with a bit of sales. The plan, the RAID log and the chasing is a project manager. The integration into a hostile enterprise estate is an integration lead. The production code and the observability is a developer. And the judgement about whether any of it was the right thing to build is a consultant.

One seat. One headcount. One person on the phone at 3am.

Which brings us to the version of this that people say quietly: is an FDE just someone who is very good at getting answers out of Claude or ChatGPT?

Here is my honest read, and it is not entirely flattering to either side of that question. The reason one person can now hold six roles is not that they got six times better. It is that the tools collapsed the cost of the artefacts each of those roles used to produce. The BA's requirements document, the PM's plan, the SE's demo, the developer's scaffold, the integration lead's mapping spec — every one of those was, until recently, days of work and a reason for a separate salary. They are now a good afternoon. If your value was producing that artefact, your value moved.

What did not collapse is the judgement about which artefact is the right one, and the accountability when it turns out to be wrong. That is the actual job. The tools will happily generate a beautiful requirements document for the wrong system, at speed, for very little money, and they will not be in the room when it goes live.

How many people are actually hiring

This is where I have to be careful, because the numbers in circulation are enormous and most of them are percentages sitting on top of a baseline of almost nothing.

Both halves of that box matter. A 729% increase is real and it happened during a period of broad tech layoffs, which makes it more meaningful, not less. But the trackers that count actual live postings are finding a few hundred roles across a few dozen companies. That is a specialist market, not a mass one.

The shape is also worth knowing before you plan a career around it. On one recruiting marketplace, 59% of the companies hiring FDEs were seed to Series A, with 35% at Series B or later. So the pipeline is: frontier labs and infrastructure companies at the top, then a fast-widening tail of application-layer startups who have decided that the way to sell AI is to send someone. Salesforce committing to a thousand seats and OpenAI standing up a $10bn deployment vehicle backed by TPG, Goldman Sachs, SoftBank and BBVA tells you the top of that market believes in it with real money.

The supply side is the number I would actually plan around. Postings grew 800% over a nine-month stretch; the candidate pool grew about 50%. Whatever the exact ratio, demand is moving roughly an order of magnitude faster than the population of people who can credibly do it. That gap is your opportunity and it will not stay open indefinitely.

And yes, the money is silly

It is also the single most revealing dataset in this whole piece, because of how badly it disagrees with itself.

That last line is not a formatting error and I have not cherry-picked it. Glassdoor's London figure is almost certainly contaminated by employers using the title for junior support and implementation roles, which is exactly the point. A title whose reported pay spans from £36k to over a million dollars is not describing a job. It is describing a word that several different markets have decided to use.

There are, in practice, three markets wearing one badge:

1. The frontier labs and their orbit. Genuinely elite, genuinely hard, genuinely paying $350k+. Small number of seats, brutal hiring bar, real production engineering plus customer-facing range.
2. The application layer. Series A through C companies who need someone to make the product land inside a real customer. Pay around that $190–195k median, equity in 81% of postings, remote-friendly in about 62%. This is where most of the growth is and where most people will actually land.
3. The relabel. An existing solutions engineer, implementation consultant or delivery lead whose job description grew three new sections and whose title got upgraded. Pay unchanged.

One practitioner quoted on this — an ex-Palantir consultant — said the role is definitely real but the title has become frothy, and that is the fairest summary available. The failure mode is well documented: organisations start calling an FDE anybody who is customer-facing and slightly technical, which hollows the word out until recruiting on it is useless.

The test that tells you which one you are in

This is the part of your question I would actually act on, and it is mercifully simple.

Did the pay move?

If your title changed to something with "forward deployed" in it, or your remit quietly absorbed the BA work and the PM work and the pre-sales work, and your compensation did not move — you were not promoted. You were consolidated. Somebody worked out that the tooling now lets one person produce what five used to, and they captured the entire difference.

That is not a conspiracy and it is not even unusual; it is what happens to every role when its output cost collapses. But it is worth naming, because the industry narrative around this role is relentlessly heroic and the heroism is doing useful work for whoever is not paying you. You are permitted to notice that you are now doing six jobs and to price accordingly.

The second test, for whether you are doing the real version: does it run in production, and are you the one who gets called? If you hand over a deck and a recommendation, that is consulting, and consulting is an honourable trade with its own rate card. If you hand over a system that is live, and your phone rings when it is not, you are doing the FDE job whatever your badge says.

Am I already one? The short checklist

• You have scoped an engagement and also written the code that delivered it
• You have presented to a buying committee and debugged in the same week
• Your last deployment went into a customer's cloud, not yours
• You have written an eval suite because nobody else was going to
• You are the escalation path, not a name on an escalation path
• Somebody has asked you what your actual job title is and you paused

Four or more and you are already doing it. Whether you are being paid for it is a separate conversation, and one I would go and have.

So you want to become one. The plan.

Assume you are starting from consulting, delivery, solutions engineering or ordinary software work. Here is the order I would do it in, hardest-gate-first, because the sequence matters more than the list.

1. Fix the production gap first. Nothing else counts until you do.

This is the one genuine gate. Every other requirement is learnable in weeks; this one is a matter of record. If everything you have shipped in the last two years was advisory — decks, assessments, architectures somebody else built — you cannot interview for this role, because the entire selection process is designed to detect exactly that.

You need one thing that is live, that has a real user who is not you, and that you own. Not a demo, not a notebook, not a hackathon. Something with an incident history. If your current employer will not give you that, the fastest legitimate route is a small paid engagement where you build and host the thing yourself.

2. Learn evals before you learn anything else fashionable.

Of the six technical competencies in the adverts, evaluation frameworks are simultaneously the least glamorous, the most asked for, and the one almost nobody arriving from consulting has. Agent frameworks change every six months. The ability to prove a system's output quality does not, and it is the thing that converts a proof of concept into something a regulated customer will actually sign for.

Retrieval and observability next, in that order. Prompt architecture last, despite it being the thing people think this job is — it is table stakes, not a differentiator, and you probably already have it.

3. Pick a domain and stop apologising for it.

FDE pay is technical range multiplied by domain fluency, and the multiplier is the part people neglect. The reason the labs want engineer-diplomats is that half the job is understanding what a claims adjuster or a ward manager actually does all day. If you have spent years in insurance, logistics, healthcare or the public sector, that is not baggage to be minimised on your CV — it is the scarce half of the role, and the twenty-three-year-old with better LangGraph reps cannot fake it.

4. Build one artefact that proves the whole thing at once.

Not a portfolio. One system, deployed, in your chosen domain, with three things attached to it: an eval suite with results you will show, an observability dashboard, and a runbook written for somebody else. That package answers the production question, the evals question and the "can you hand over" question in a single link, and it is worth more than any certification in this market.

5. Work out which of the three markets you are pitching into, and price for it.

Applying to a frontier lab with an application-layer CV wastes months. Applying to a Series A with frontier-lab salary expectations wastes everyone's afternoon. Know the band: roughly $350k+ at the top, roughly $190–195k median in the broad market, £850ish a day on UK contract. UK contractors should also note that the outcome-driven shape of this work reportedly puts most non-permanent FDE roles outside IR35 — worth confirming per engagement rather than assuming, but it materially changes the arithmetic against a permanent offer.

6. Prepare for an interview that is half a conversation.

Coding rounds, yes. But the differentiator is the discovery round, where they hand you an ambiguous customer situation and watch whether you ask about the business or start designing. Practise being interrupted. Practise saying "I don't think that's the right thing to build" to someone senior, out loud, without hedging it into meaninglessness. That is the skill being tested, and it is the one consultants already have and undersell.

7. Ask the questions that reveal which version of the job it is.

• What percentage travel, honestly, over the last six months rather than in the advert?
• How many customer accounts will I hold at once? (More than two or three and it is coverage, not deployment.)
• Who owns the commercial number — me, or a separate account executive?
• What happens at handover, and to whom?
• What happened to the person who had this seat before me?

That last one is the whole interview. The burnout risk here is real and well documented — up to 50% travel, ambiguity as the default condition, and a job that by construction has no one to escalate to. The reported difference between people who last and people who leave in eighteen months is not resilience, it is whether the travel is surfacing interesting problems or just babysitting go-lives. You can find that out before you sign.

8. Put the same protections in that you would on any engagement.

Everything this site has said about scoped work still applies, and applies harder when you are the only person in the room. Define the stop condition. Get the handover named. Know what you are on call for and what you are not. See the deprecation clause for the contractual version, and the red flags list for the ones to spot before you agree to anything.

The honest summary

The forward deployed engineer is a real role with a real lineage, currently doing two jobs at once: describing a genuinely demanding position at the top of the market, and providing convenient cover for merging five job descriptions into one headcount everywhere else. The pay data gives the game away — a title whose reported compensation spans thirty-fold is a title in the middle of being contested.

The underlying shift is real regardless of what anyone calls it. The tools did collapse the cost of the artefacts that used to justify separate roles, and the person who can hold the whole arc — scope it, sell it, build it, ship it, answer for it — is genuinely more valuable than the five specialists whose outputs they now generate in an afternoon. That is not hype. That is just what happened.

What I would resist is the implication that follows it around, which is that because you can do all six you are obliged to do all six for the price of one. The correct response to "the tools can do everything, so why can't you?" is "I can, and here is what that costs." The people getting $350,000 a year have worked that out. The people whose job description grew three sections last quarter have not yet.

So: are you a consultant or a forward deployed engineer? If you scoped it, sold it, built it, deployed it, and your phone rings when it breaks — you are an FDE. You may simply be filed under the wrong heading, and paid under it too.