The last week of an embedded engagement has a particular texture. Access gets revoked, badges get returned, and a final readout lands on the calendar with more executives invited than any working session ever drew. Somewhere in that week there is a directory — or there is not — and that directory settles an argument the industry has spent a year having about job titles.
The skeptics of the forward-deployed engineering wave are right about more than their critics concede. Thomas Otter traces the practice of embedding engineers with customers back to SAP’s R/1 deployments at ICI and John Deere — the work is nearly as old as enterprise software itself. Tom White’s verdict sits in his title, “Sexy Titles, Unsexy Work”: solutions consulting rebranded for a market that wants to sound startup-native. The worst response to this critique is denial, because the lineage is real. The right response is to concede the ancestry and name the delta precisely.
The delta is not the title, and it is not the rate card. It is what’s left behind.
Gergely Orosz’s shorthand for the role — a startup CTO for one customer — captures the posture. But posture is not proof. Proof is portable.
The artifact test
A consultant leaves a deck. Sometimes a genuinely good deck — a defensible analysis, a roadmap that would work if anyone built it. A forward-deployed engineer leaves running software, and the software is the smaller half of it: the eval suite that defines what working means, the configuration that encodes every hard-won constraint of the client’s environment, the runbook the client’s own team operates from, and the decision record explaining why the system behaves the way it does. One kind of leave-behind requires the client to start. The other requires them merely to continue.
The eval suite is the piece people underweight, and it is the actual line between advisory and engineering. An advisor is done when the recommendation is delivered and the invoice clears. An engineer is done when a defined set of checks passes against production behavior — and keeps passing after the engineer has left the building. OpenAI’s own description of the forward-deployed role makes the standard explicit: success is measured in production adoption and eval-driven feedback, not in artifacts about the work. Done stops being a milestone in the contract and becomes a property of the system.
Notice what this does to the shape of the engagement itself. When done is eval-defined, the first week gets spent arguing about what the checks should be — which is another way of saying the first week gets spent understanding the operation. Consultants interview stakeholders. Engineers negotiate acceptance criteria with production reality.
Inside a CMS-regulated health plan we operate in, none of this is philosophical. The leave-behind is the requirement. Evidence a compliance officer can review, a runbook that survives an audit, a record of what the system decided and who approved it — no regulated operation accepts “the vendor knows how it works” as an answer to an examiner. If the client’s team cannot run it and defend it after we leave, the engagement is not finished, whatever the invoice says.
The obvious objection comes from the vendor side of the table: dependency is the business model. Keep the critical knowledge in your engineers’ heads, architect a little stickiness into the integration, and the renewal negotiates itself. It works — for a while, and with a particular kind of client. But it selects for the clients who couldn’t tell the difference, and it forfeits the one asset that genuinely compounds in an embedded business, which is trust. Exit-by-design wins the second engagement precisely because the client watched you take the option of leaving cleanly. Firms that architect for dependency win renewals until a new CTO reads the codebase. Firms that architect for exit get invited back with bigger problems and shorter procurement cycles.
So judge any team wearing the title with one question: what does the client operate on the day after the engineers leave? A deck is an opinion about a system. Code, config, evals, runbooks, and the record are the system.
LockedIn Labs FDE is built around that test — the platform accumulates the artifacts as the work happens, so the handover is not a scramble in the final week. By the time the engagement ends, it is already written.
LockedIn Labs FDE is the platform forward-deployed engineers carry into the enterprise — the operating reality held as a governed asset, workflows and agents as reviewable definitions, and every privileged action stopped at a named human.