The role came out of a room nobody wanted to sit in

Ask where the job came from and you get a founding story: a young company, a customer who could not explain what it wanted, an engineer sent to sit with them until something worked. The story is broadly true and nearly useless on its own, because it makes the role sound like an accident of personality. The thing that got invented was a decision about where an engineer's desk belongs, taken repeatedly and at real cost, until the decision hardened into a company structure.

The loop came before the title

The first customers could not write a requirements document, and this was not a failure of imagination. The system they needed did not exist yet, so there was nothing to specify. The workaround was crude: build a rough version, put it in front of the user, collect the complaint, rebuild, and repeat faster than the customer's patience runs out.

That loop needs a particular kind of person. Close enough to hear the complaint the first time it is said, senior enough to change the thing that night, and present when the number is wrong at the end of the quarter. A consultancy can run the same loop and usually ends it with a recommendation. Here the loop ends with a running system, and the person who wrote it is the person who hears the complaint. The difference is where someone sits, not what they know.

The arrangement was known to be ruinous

One account of the early years has an engineer working out of a sealed room for weeks, a phone strapped to his head so he could keep one ear on the analyst and one on headquarters, because the room did not allow a speakerphone. He got the work done and then told the founder the arrangement could not continue. The founder's answer, as the story is retold, was to turn the unsustainable arrangement into an institution.

Treat the room as illustration, not history. The useful part is the sequence: the work was understood to be ruinous, it was chosen anyway because the alternative was worse, and the company then built a structure that could survive repeating it. An organisation that decides to do a damaging thing on purpose needs to price it, staff it, rotate it and keep it from becoming the whole business. FDE is that structure.

What the cost structure permits

A senior engineer resident with one customer is expensive in a way that is easy to understate. The available estimates are rough and should be read as orders of magnitude, not audited figures:

Cost fact	Figure, as reported	What it rules out
Annual delivery cost of one deployment	from about $75,000; a single-source industry estimate, best read as a floor	customers whose entire annual value at stake is tens of thousands
Fully loaded cost at a senior compensation basis of about $385,000	roughly $75,000 to $170,000 per deployment per year	accounts that cannot carry a resident engineer plus someone behind them
A ten-person team's year (modelled)	about $5m in cost, 10 to 15 deep customers, $1m to $4.5m in revenue	breaking even in year one; the pure-labour margin is 20 to 40 per cent and can be negative
Revenue per head	about $1m at Palantir, about $89,000 at a global consultancy, about $49,000 at a large IT services firm	reading FDE as an upgraded delivery bench

The table is the argument. If one well-paid person serves one customer, the work has to be worth enough to carry that person and the bench behind them. Value has to be large, concentrated, and attributable to a specific system. This is why the early customers were intelligence services and industrial manufacturers, and why the same shape reappears wherever a single deployment moves a number big enough to justify a body on site.

Why it is not consulting

Palantir's own distinction is the cleanest: a platform engineer supplies one capability to many customers, while a field engineer supplies many capabilities to one customer. The unit of work is inverted.

The second difference is the exit. A consultancy sells judgement, delivers a document, and leaves before the consequences arrive. An implementation vendor sells hours against a fixed specification and is paid on delivery. An FDE is measured on whether the production system is still used after the invoice, which is why the four responsibilities include adoption and handover and not only build. That last clause is what makes the cost structure tolerable: the most expensive person on the account is also the one who can see, early and cheaply, that the thing will not be used.

It also settles the recurring confusion about pre-sales. Pre-sales exists to help someone else close; an FDE exists to make the thing work after it is sold. The accountability is not, which is the argument in whether an FDE is a pre-sales role.

Why the shape returned in 2026

Nothing about the arithmetic changed. What changed is the size of the number on the other side. When a model can plausibly move a business function's cost or revenue by a large multiple, a resident engineer is cheap relative to the value at stake, and the deployment gap described in the 2026 market numbers is a great deal of value sitting on the wrong side of the last mile.

The deployment organisations built in 2026 are a bet on that ratio, not a fashion in job titles. The bet has a failure mode, and it is worth naming because it is the one independent practitioners walk into: copy the shape without the deal size. A resident engineer on a contract whose total value is a few months of salary is not a forward deployment. It is a subsidy with a job title, and it ends when the savings run out.

The test

Put two numbers on one line before a pilot starts: the fully loaded annual cost of keeping an engineer on this account, and the annual value the customer will state is at stake, in their own units. If the first is more than roughly a fifth of the second, the ratio does not support the model. Shrink the scope until it does, or decline.

The fifth is a rule of thumb, not a finding. The direction is not: the room was expensive when it was invented, and it still decides which customers can afford to have you in it.