Industrial Forward Deployed Engineering: what it is and why factories need it

The model the AI labs made famous

The idea is old in consulting and new in software: instead of selling a licence and a manual, you send an engineer to sit inside the customer. Let them see the real problem. Let them iterate on it with their hands.

It works because it fixes the quiet lie of enterprise software: the generic product never quite fits, and the distance between "this should work" and "this works in your house" gets paid for by the customer, in the form of a failed project.

Through 2025 and 2026 the big AI labs have been hiring FDEs by the dozen. The reason is simple: they have extraordinary models, and they are discovering that a model on its own solves nobody's problem. Someone has to put it where it hurts.

In industry this is not new

Here I get slightly tiresome, and I apologize in advance.

I came into this in the late nineties. I was in my early twenties, and I spent four years building — almost single-handed — the industrial software systems for a ceramics group: six or seven factories, glaze milling with its chemistry, presses with their mould inventory, kilns with their thermocouples. I didn't do it from an office. I did it in there, with the shift running.

Nobody called it forward deployed engineering. It was called deploying, and it was the only way the thing was ever going to be useful.

Since then I've led more than 300 deployments personally. Automotive, aerospace, food. And across all 300 the pattern has been identical: the system that works is the one written with the operator standing next to you, not the one delivered by email.

So when I read that FDE is the new model, I'm pleased. It's an excellent model. It just isn't new on a factory floor: it's the only thing that has ever worked.

Software FDE vs industrial FDE

And yet they are not the same. Anyone coming from software into a plant is in for four surprises, and it's better to get them from this page than on a Tuesday at three in the morning.

The difference outsiders underestimate most is the user. In software, if your tool is bad, the analyst complains. On the floor, if your system is bad, the operator quietly stops looking at it — and you don't find out until you've spent six months making decisions on data nobody is feeding.

The second is the cost of stopping. In software you deploy and roll back. On a production line, stopping to try something has a per-minute price that somebody knows exactly, and that somebody is in the meeting.

Are you building — or should you be building — industrial FDE capability? Take the three-minute FDE assessment. I read every answer personally and reply with my take on your situation. Take the assessment →

What an industrial FDE actually does on a deployment

Let's get concrete, or this stays theory.

A bakery. The problem wasn't about models: it was that two pieces of bread could come out too close together and stick in the oven. An industrial FDE doesn't arrive with a classifier. They arrive, watch the line, work out that the defect is decided before the oven, and build a system that checks every piece five times a second. It warns you about a defect that doesn't exist yet. You don't design that from a desk. You design it watching the belt.

An aerospace plant. They had spent years trying to catch oil leaks on test benches with classical machine vision and with dyes. No luck, because an incipient drop refuses to be described with rules. The FDE's work wasn't choosing a network architecture: it was spending weeks in there, understanding what a leak is to the person who looks at it, and collecting the examples that were actually needed. Two months into training, the system was sharper than the human eye.

In both cases, the share of time the engineer spent writing model code was the smallest part of the project. That is forward deployed engineering.

So where did the rest of it go? Into things that appear on nobody's CV: working out what that sensor actually measures against what it measures on paper, discovering that the night shift does things differently from the morning shift and that both are right, negotiating five minutes of downtime with whoever answers for the day's output, and sitting with the operator to see what gets in their way about the thing you've just put in front of them.

That work is the project. The rest is the part that shows up in the demo.

Why everybody suddenly needs industrial FDEs

Three pressures have landed at once.

The labs have the model and no plant. They've built astonishing things and are now finding out that a factory is not an evaluation environment. They need boots on the floor, and they can't find them in the software market.

The integrators have the clients and not the profile. They've served those plants for years, and now those clients are asking them for AI. Saying no loses the client for good; saying yes without the right profile is worse.

The manufacturers have pressure from the board. "What are we doing about AI?" is the question in every steering committee of 2026. And the honest answer in most plants is "pilots".

The bottleneck is the same in all three cases and it isn't technological: the hybrid profile is missing. People who understand the factory and AI at the same time. And of the two halves, the one almost nobody has is the factory one — which is precisely the half you can't pick up on a course.

How an industrial FDE team gets built

Here's what I've learned from doing it, which doesn't always match the standard advice.

You don't solve it by hiring data scientists. It's everyone's first instinct and it's the easy half of the problem. A good data scientist with no shop-floor judgement produces models that work in the notebook and get in the way on the floor. The hard half — knowing why that machine fails on Mondays, knowing when the operator is telling you no while saying yes — doesn't get hired. You either have it or you grow it.

The raw material is usually already inside. In nearly every plant I've worked in there were already two or three trainable people: the maintenance man who smells the problem, the process engineer who has watched the same line for fifteen years. What they lack is the AI half. That one you can teach.

You learn by deploying, not in a classroom. An FDE team is built on a real deployment, with somebody beside them who has already done 300. Theory up front helps very little: the knowledge that matters shows up when something doesn't go the way the plan said.

And there is an organizational condition almost nobody sets. The FDE needs to be able to decide on the floor without going upstairs to ask. If every adjustment needs three signatures, you don't have a forward deployed engineer: you have a consultant who comes and goes, and the whole model loses its point. Set a threshold — of spend and of scope — inside which they decide, exactly as you would with a good kaizen.

The first deployment isn't chosen on return. It's chosen on visibility and on short timescale. You need the team to see something of theirs running in production before the organization's patience runs out, and that weighs more than the payback of the particular case. One small problem solved completely convinces people more than a big one solved halfway.

That is exactly what we do at American Lean, with a network of more than 150 industrial FDEs. And it runs in two directions, which aren't exclusive: we train the client's team so the capability stays in house, and meanwhile we cover the peaks and the first projects with our own network, so nobody has to turn work down while they learn.

If you want the background to all of this, the third industrial revolution explains what the PLC automated and where its ceiling is, and Ford's assembly line explains why every optimization assumes a context worth checking before you set it in concrete.

What decides whether this goes well for you

After 300 deployments I can tell you with some confidence what separates the ones that work from the ones that stall at pilot. It isn't the model. It isn't the budget.

It's whether somebody is able to stand in the plant long enough to understand the problem before solving it.

That's all forward deployed engineering means. The labs have given it a name, and good — a word was needed. But the word isn't the new part. The new part would be somebody daring to do it without going down there.

Are you building — or should you be building — industrial FDE capability? Take the three-minute FDE assessment. I read every answer personally and reply with my take on your situation. Take the assessment →