Where did the forward deployed engineer come from?

Why did data companies need a new kind of engineer?

Because their product was general and every customer's problem was specific. A platform for integrating and analysing data is useless until someone works out which of a customer's forty systems matter, how their records relate, and what question the business is actually trying to answer. Sales engineers could demonstrate the product. Support engineers could fix it. Neither could do the thing that made it valuable: live inside the customer's problem and build the last mile.

So the companies created a role that did. The engineer flew to the customer, sat with analysts and operations staff, wrote code against the customer's real data, and stayed until something worked. That person was not a consultant, because they built. They were not a contractor, because they decided what to build. The combination needed a name.

Why the military phrase?

"Forward deployed" describes units stationed at the front rather than at headquarters, close enough to the situation to act on their own judgement. The analogy fit: the engineer was away from the product team, inside the customer's world, making decisions without waiting for a specification to travel back and forth. The phrase stuck because it captured the one thing that mattered, which was where the engineer sat.

How did the role spread?

Slowly at first, because most software companies sold products that did not need it. A payroll system or an email tool works the same everywhere. Then enterprise AI arrived, and almost nothing worked the same everywhere. A language model is general; a useful AI system for a brokerage, a hospital or a bank is intensely specific. The gap between the two is exactly the gap the first forward deployed engineers had closed, and the role was adopted across AI companies, consultancies and engineering firms within a few years.

What does the role look like today?

Three versions exist. At AI product companies, forward deployed engineers adapt the company's models and tools to each enterprise customer. At consultancies, they are the engineers who build rather than only advise. At engineering services firms such as FetchSky, they are the engagement model itself: an engineer embedded in the client's business to find what is worth building, build it on real systems, and stay to run it. The details differ; the idea is the one the data companies arrived at first. Sit where the problem is.