What a forward deployed engineer actually does - and whether you need one

"Forward deployed engineer" is having a moment. It's all over LinkedIn and X, AI companies are hiring for it everywhere, and every second post defines it differently. Somewhere in the noise you may have had a reasonable thought: whatever this is, it sounds like something my company needs.

You're probably right. Just not in the way the job title suggests.

Strip the hype, and a forward deployed engineer is someone who gets embedded in a business, figures out how the work really happens there, decides where AI and automation genuinely help, builds the software, and stays accountable for it running. The term comes from the enterprise software world, where the big platform vendors learned that shipping software isn't enough - someone has to sit inside the customer's operation and make it fit. AI has made that same job urgent for everyone, because a language model out of the box knows nothing about how your company works.

The job breaks down into three stages. It's worth understanding all three, because most of the value sits in the two that don't involve writing code.

The three stages of the work

1. Find out how the work actually happens

The documented process is rarely the real process.

On paper, step one of your invoicing workflow is "an invoice arrives by email." In reality it arrives from forty different senders, no two formatted alike. Some invoices are PDFs, some are screenshots, some are Excel attachments, some are buried three levels deep in a forwarded thread. Half of them are exceptions: it's the same as last month, ignore the second attachment, Sarah already approved this one. And the knowledge of how to handle each case lives in one person's head - not in any SOP, not in any Google Doc.

Ask that person "what's the first step?" in a one-hour meeting and you'll get the clean version. Sit next to them for a day and you'll see the real one, including everything that goes wrong. That's why the first stage of this job is unglamorous: interviews, observation, access to the CRM and the ERP, and writing down the exceptions. It's also where most of the time goes, because a system built from the clean version automates a workflow nobody actually runs.

2. Decide where AI belongs - and where it doesn't

The first wave of business AI was "put the model on everything and let it figure things out." The results are well documented: budgets burned on API calls, hallucinated output, and a long list of pilots that never made it to production.

The second stage of the job is judgment. Take a ten-step workflow: maybe seven steps are pure rules - if this, then that - and belong in ordinary deterministic code that behaves the same way every time. Maybe three steps genuinely require judgment, like reading an ambiguous inquiry and deciding what it's about. Those are the steps where a model earns its place. And maybe the workflow next to it shouldn't be touched at all, because it's too risky, or the return is too small to justify the cost.

Saying "not here" is a core deliverable of this role, not a failure of ambition. It requires knowing what a mistake costs your business and knowing what the technology can reliably do - and it's exactly the judgment that was missing from most of those failed pilots.

3. Build it, ship it, own it

The third stage is the actual software - and the standard is production, not demo. Structured output instead of free-form text. Handling for the thousand ways input goes wrong. Monitoring on what the system produces, not just whether the API call succeeded. A human approval step wherever a decision is hard to reverse.

And then ownership. When something misbehaves on a Monday morning, it's the forward deployed engineer's problem - they know what to check, who to call, and how to fix it. That accountability is what separates the role from someone who builds a prototype and hands it over. I've written before about why most AI automation projects break in production; the short version is that they're built by people who stopped at stage three's demo, without stages one and two ever happening.

Why you can't just hire one

Look at what those three stages demand from a single person.

One half is consulting work: mapping workflows, understanding cost and risk, reading the incentives of the people involved, getting a sceptical team to adopt a new system. The other half is engineering: APIs, data, integration work, testing model output, keeping software reliable in production.

Plenty of people are strong on one side. Consultants can map your process beautifully and hand you a slide deck; developers can build exactly what the ticket says. A forward deployed engineer has to be the best combination of both - not the average, where someone is mediocre at each. Someone who can sit in your operations meeting and extract how invoicing really works, then go build and ship the system that handles it, and stand behind it afterwards.

That intersection is genuinely rare. It's why the title commands the attention it does right now, and why actually recruiting one is slow, expensive and competitive - you'd be bidding against AI companies for a small pool of people.

Do you actually need the hire?

If you're a large enterprise rolling AI out across dozens of departments, a full-time forward deployed engineer - or a team of them - can be worth it. There's enough continuous work to fill the role for years.

For most companies, the honest answer is: you don't need the title on your payroll. You need the work. A workflow mapped the way it actually runs. Systems that talk to each other. A clear-eyed call on what's worth automating and what isn't. Software that survives contact with production, and someone who keeps it running as the business changes.

That work arrives in projects, not in headcount. Which means the practical question isn't "how do we hire an FDE" - it's "who does this kind of work for companies our size."

Buying the work instead of the title

Here's the part you've probably seen coming: the three stages above are a description of what I do.

Not because I rebranded when the term got popular - because this is what building custom software for businesses has always required when it's done properly. Sitting with the team to learn how the work actually happens before proposing anything. Wiring into the CRM, the ERP, the mail flow and the portals you already run instead of asking you to replace them. Deterministic code for the steps with known behaviour, AI only where judgment is involved, a human in the loop where it matters. And staying around after launch, so the system keeps working when the business shifts underneath it.

If you've been reading about forward deployed engineers and thinking "we need this": I do this work, I've done it for years, and I can help. Tell me where it hurts.