The Forward Deployed Engineer Now Works for the Vendor

Software sold to many companies has to arrive in a fairly general form, while any company buying it works in its own particular way. Something has to close that distance, and it usually turns out to be a person.

Right now that person is called a forward deployed engineer, and much of the current writing treats the role as something new. The work itself looks a good deal like what earlier versions of the job involved. What has changed is who employs them — and that, I think, shapes what happens to the work they bring back.

The gap is permanent, and it has had several names

In the mid-nineties the person closing the gap was a functional consultant. They sat with the finance department for six weeks, learned that the company recognized revenue in a way the software had not anticipated, and wrote the configuration that made the difference disappear. Fifteen years later, much the same person was doing digital transformation: taking a business that ran on paper and phone calls and web-enabling it, which meant, again, sitting with the operators long enough to learn what they actually did rather than what the process document said they did. More recently the title was solutions architect: fitting a cloud platform to whatever collection of systems a customer had already accumulated, which again meant learning the collection before fitting anything to it.

Which makes the current title the fourth name for a function that tends to appear wherever general-purpose software meets a particular organization.

What is genuinely new is the employment arrangement.

Two ways to pay a surgeon

Consider two hospitals performing the same operation with equal skill.

In the first, the surgeon bills per procedure. A complication requiring a second operation generates a second bill. Nobody causes complications on purpose — the surgeons are conscientious and the outcomes are audited — but the money flows toward intervention, and over years practice patterns tend to drift in the direction the money flows.

In the second, the surgeon draws a salary and the institution is paid a fixed sum to keep a population healthy. Now a complication is a cost. The same conscientious surgeon finds the institution around them has acquired a strong interest in the operation not being necessary at all. Prevention gets a budget.

The difference isn't virtue. It's which outcomes the arrangement makes expensive.

The old arrangement made the gap into revenue

The consultant implementing ERP in 1996 usually worked for the systems integrator, not the software vendor. The gap between the generic product and the particular customer wasn't their problem. It was their product.

Every requirements workshop, every custom report, every interface to the legacy system — margin. An awkward fit meant a longer engagement. That's much of why implementations from that era have a reputation for expanding, though the consultants themselves were rarely cynical about it. They were doing careful work inside an arrangement that priced awkwardness as billable hours.

The vendor, meanwhile, learned relatively little. Field knowledge accumulated in the integrator's methodology decks and in the heads of consultants who carried it to the next client. The product team sat several organizations away from the customer, receiving what the sales channel chose to forward.

The new arrangement makes the gap into a cost

Move the same person onto the software company's payroll and the terms invert.

Their salary becomes a charge against product gross margin, visible to finance. Anything they build that serves one customer and no one else is an unrecovered cost inside a business meant to have software economics. The pressure is toward either generalizing that work into the product or not doing it.

Which means the engineer's success condition is, oddly, the elimination of their own current task. A custom integration written last month should become a supported capability this quarter — or be read as evidence that the product's model of the world needs revising. Under the old arrangement, a third client with the same awkward requirement was a third engagement. Under the new one, it's closer to a specification.

The part that usually gets rendered as a personality trait — the engineer who flies out and hacks something together over a weekend — seems to me the least important part. What matters is the return path. Deployment stops being the last step of the sales process and becomes an instrument for discovering what the company is actually building.

There's a second reason this matters for systems built on models rather than rules. With deterministic software the specification was knowable in advance: tedious and politically expensive to extract, but knowable, and therefore handed across an organizational boundary. With a system whose behavior is statistical, you can't really know whether it works until you run it against a customer's actual inputs — and the artifact that settles this can only be written by someone who knows the domain well enough to say what the right answer is in the awkward cases. That knowledge rarely survives being written into a requirements document. It has to sit with the person building. The embedding is less a relationship strategy than a technical necessity.

What the arrangement doesn't fix

Three limits worth stating.

The inversion is often nominal. A software company can put field engineers on its own payroll and then run them as an internal services business with a utilization target, which reproduces fee-for-service inside the building under a better title. A fair number of roles advertised as forward deployed are a travelling solutions engineer with a new business card. The tell isn't the org chart; it's whether anyone measures what fraction of field work becomes product.

Vendor employment enables the return path without creating it. An engineer with no authority to change the product, and no route to the people who have it, is a well-paid implementer whose learnings evaporate at roughly the consultant's rate. The arrangement removes an obstacle. It doesn't supply the will.

And the old model had a virtue the new one gives up. A consultant with no product to defend could tell a client in week one that the software was the wrong choice, and that was occasionally the most valuable sentence in the engagement. An engineer paid by the vendor is unlikely to say it, and over time may stop thinking it — not through dishonesty, but through the ordinary effect of working somewhere for years. The old arrangement paid people to describe the gap accurately; the new one pays them to close it. Something is lost in the substitution.

The question worth asking

The function is roughly thirty years old, and the skills carry from each era to the next, which is why the people who are good at it have often been good at it under two earlier names.

What changed is that the gap between the general and the particular stopped being a revenue line for one company and became a cost line for another. That single move is what turns deployment from the end of the sales process into the beginning of the product one.

So the question worth asking about any role with this title isn't what the engineer does in the field. It's what happens to what they build when they come back.