Closing the distance between generic software and a particular company is a thirty-year-old job with four names. What changed isn't the work but who pays for it — and that decides what happens to whatever gets built in the field.
Forward Deployment
Software sold to many companies arrives in a general form. Any company buying it works in its own particular way. Closing that distance has been somebody's job for thirty years, under four different titles, and it currently goes by forward deployed engineer.
Most of what's written about the role describes what the engineer does in the field. These essays are about the structure around it: who pays for the work and how that changes what happens to it, what supervision looks like when a role produces no documents, and why the specification for a modern system can only be written in the customer's building.
The through-line from the earlier series still applies. If verification is the scarce thing, the question that follows is where the person doing it has to stand.
In progress. New essays as they're written.
Implementation used to be three jobs, and the documents existed because the work changed hands. One person doing all three writes nothing down. That paperwork was how anyone could tell whether the work was good.
The specification for systems built on models can't be produced anywhere but the field. It needs the customer's actual data, which doesn't travel, and the customer's expert, who won't.
The earlier series, Verification, works through the problem this one assumes: how anyone knows a system is doing what it claims.