Forward-Deployed Engineering Model

Most software companies build a product at headquarters and then rely on other people to get it working in each customer's environment. The forward-deployed engineering model takes a different approach. Instead of handing the customer's problem to someone far away, the company places engineers directly inside the customer's team, where the work actually happens.

The word forward-deployed was meant quite literally in the early years of the model. Engineers spent extended periods physically alongside the people who used the software, including in demanding settings. The point of that proximity was not the setting itself. It was the feedback loop. An engineer who sits inside the room can see what breaks, fix it, and put the fix in front of the operator without waiting for a request to travel through headquarters.

The engineer's assignment is deliberately narrow. Staying with one customer keeps the engineer close to real use, so each problem is seen where it actually happens. The diagram shows the two sides of this arrangement: the engineer works inside one customer's team, and the lessons from that work travel outward to the product organization rather than the engineer staying in the vendor's headquarters.

The model depends on a short feedback loop. The engineer observes a real problem, builds a response, and checks it against real use, all within a short cycle. Vendors that route every issue through a distant queue operate at a much slower cadence, and the FDE model exists to remove that delay.

The central image of the model is the gravel road. An FDE builds a gravel road, which is a fast, customer-specific, sometimes rough path from where the product is today to where this customer needs it to be. The road is not elegant and it is not meant to serve everyone. It exists to get one customer moving.

The product team at headquarters has a different job. It looks at the gravel roads that several FDEs have built, identifies the patterns that recur across them, and converts those patterns into a paved highway. A paved highway is a generalized capability in the core product, one that future FDEs can use without rebuilding it from scratch. The gravel roads are the raw experience; the highways are what the experience becomes once it is generalized.

The metaphor captures the heart of the FDE model. The FDE is responsible for the road, and the product team is responsible for the highway. Neither half works well alone. Without gravel roads there is nothing to learn from, and without highways the same work would be repeated endlessly.

The two kinds of work are easy to confuse because both involve code that solves real problems. The distinction is about who the work is for, how general it is, and who owns it. An FDE is not there to win the contract, and an FDE does not hand over a report and leave. The FDE's output is working software inside the customer's environment.

The FDE role demands skills that ordinary software work does not always build, so the company eventually created a structured way to produce them. A rotation program called Project Frontline took ordinary software engineers and retrained them as FDEs. By the count given in the source, more than 250 engineers went through it, and its alumni now staff forward-deployed functions at other companies in the industry, including OpenAI and Anthropic.