What is a forward-deployed engineer?

A forward-deployed engineer, often shortened to FDE, is a software engineer who works inside a client’s organization. Instead of receiving a set of requirements and building somewhere else, they go to where the problem is. They sit with the team that has it, learn the systems and data involved, and build the software there.

The term comes from software companies that placed engineers with their biggest customers to adapt complicated products to each customer’s needs. It has since become a popular way to deliver AI projects, for reasons that are easy to see once you’ve watched a few projects go wrong.

Why the model exists

Most failed software projects didn’t fail because the engineering was too hard. They failed because the team built the wrong thing. The requirements were written by someone who doesn’t do the job, or they described the process as it’s supposed to work and not as it actually works on a Tuesday afternoon.

AI makes this worse. Whether a model or agent turns out to be useful depends on details that rarely reach a brief. The exceptions people handle by instinct. The form that always arrives with one field blank. The system that updates a day late, so everyone checks a different one first. Someone sitting next to the work notices these things within days. Someone reading a document never does.

So the forward-deployed model puts the person writing the software next to the person with the problem.

What the job looks like

An FDE’s work tends to go round in a loop. They watch the process and talk to the people running it. They work out, with the client, which problem to tackle first. They build something quickly, often a rough prototype on the client’s own data, and get it into people’s hands. They see what works, change what doesn’t, and bring it up to production standard so it can run every day. Then they move on to the next problem.

It’s an unusual mix of skills. An FDE needs to be a solid engineer, comfortable talking to a warehouse supervisor in the morning and a finance director in the afternoon, and willing to make calls about what not to build.

Forward-deployed architects

Bigger projects need someone looking at the whole picture: how the software connects to existing systems, how it’s secured and operated, how it should grow. That’s the forward-deployed architect. Architects and engineers usually work as a pair. The architect keeps the design coherent while the engineers do most of the building.

How it compares with other ways of working

With traditional consulting, the deliverable is often a recommendation or a slide deck. A forward-deployed team builds and ships the software, and sticks around long enough to improve it.

With staff augmentation, you get extra people to work through a backlog you’ve already written. A forward-deployed team is responsible for finding the problems and proposing what to build, with your leadership deciding the order.

Buying a product gets you something designed for many customers at once. Sometimes that’s exactly right. When it isn’t, see build or buy AI.

When it fits

Forward deployment works best when the problem is specific to how the organization runs, when nobody’s sure yet what the requirements are, when there’s a series of related problems and not a single fixed project, and when the client wants its own staff to learn alongside the builders.

It’s how we run all of our work, whether that’s an AI strategy engagement, a single custom build or a forward-deployed team that stays for longer.