Notes on the engineer in the room.
Or: what forward-deployed engineering is rediscovering, and what is new about it.
A great deal of money is moving toward a single idea: placing engineers inside operating organizations to redesign workflows around frontier models. Some of it is structured as joint ventures, some as new firms built for the purpose, and the sums are large by any measure. The framing is that this represents a new operating model for enterprise technology. From inside the work, it does not read as new.
What it reads as is a recognizable role being scaled and given a name. The role is not new to financial services: it has appeared under different titles, with different tools. Some of the practitioners who will land in those rooms have done versions of this work for decades. Others will be encountering it for the first time. It is worth saying out loud which parts they will be rediscovering and which parts are different this time.
The role has been there before
In 1996 I was a research analyst at CIBC, a member of the firm's Strategic Technology Committee, and the desk's vendor liaison for technology. I built the desk's first research website that year, a thing most analysts at name-brand firms were not yet doing. Visualizations I built for emerging-markets coverage started showing up, watermarked, in colleagues' research at other shops. None of these activities had a single job title. The firm had structurally recognized that someone who came up through the trading desk could also be the one to evaluate the technology, and could also be the one to build small things that mattered. There was no name for it then. Today the same shape gets called Forward Deployed Engineering.
Solutions-E, the consulting practice I co-founded in 1999, served seven small hedge funds and institutional shops in four years. We designed trading floors. We picked vendors. We wrote integration specs. Same shape. Cambrian, my next firm, ran simultaneous engagements in London, Frankfurt, Zurich, Tokyo, New York, and Dublin. Financial services only. A senior practitioner in each city, deep enough in the local context to be admitted to the room, working alongside vendor teams to land the migration. Same shape, six cities at once.
What the new ventures will rediscover
What the new ventures will discover, if they have not already, is that the technology is the smaller part of what they are selling. The larger part is judgment formed across many engagements, and the institutional discipline to act on it.
The trust problem. You cannot impose a workflow on a desk. You can show up, deliver, listen, and earn the standing to be heard. On the Aladdin migration at Deutsche Asset Management, I spent the first months doing very little except listening. By the end of that period, traders had started giving me literal floor access to surface issues that email could not move fast enough. The seat on the floor was not negotiated. It was earned. The seat on the floor is also the difference between an engagement that finishes and one that does not.
The documentation problem. Documentation has a short shelf life. What people remember outlasts it, and leaves when they do. I have written elsewhere on this site about a stress-testing program where the only person who could explain an intermittent data error was someone months from retirement, the fix living in his head and nowhere in the record. That kind of institutional reading (knowing whom to ask, and which silence is meaningful) is not a thing you can pick up from a project plan. It is also the thing forward-deployed engineers will most often need and most often lack.
The metric problem. Anyone embedded inside an organization will be tempted to negotiate against the easy metric, because the easy metric is what stakeholders ask for. The discipline of refusing to do that, of insisting on the harder measure, is what separates an engagement that compounds from one that does not.
The detractors. I have also argued elsewhere that the people who appear at the start of a transformation to be obstacles are usually the most knowledgeable people in the room. The same is true of the rooms forward-deployed engineers are about to walk into. The senior practitioner who has been running the existing system for fifteen years already knows which edge cases will break the new one. Treat that person as the syllabus. An engagement that reads them as an obstacle has thrown away the thing it most needed.
What is new this time
The capability of frontier models is different in kind from what came before. They write working code and handle ambiguous instructions in ways deterministic software could not. An engineer placed inside an operating company in 2026 can ship things in a week that would have taken a small team three months in 2020.
The pace is also different. Prior cycles unfolded over years. The current one is unfolding in months. Capital is flowing into specific operating models faster than the operating models are stabilizing, which means many of the engagements being scoped today will be re-scoped before they close. The engineers landing in these rooms will need to plan around that churn rather than wait for it to settle.
And the capital itself is bigger. Money at that scale arrives with expectations attached, and the institutions writing the checks are not expecting incremental improvement. That changes the political weight an embedded engineer walks in carrying, and the length of the leash. None of this changes the people-work.
Which is which
The institutions hiring forward-deployed engineers are paying for judgment more than for engineering. Judgment is what the established consulting firms have always sold, and the new ventures now compete for it directly. Some of the senior practitioners now showing up under the FDE title are doing work that has been done before, with new tools. Others are meeting it for the first time. It is useful, on both sides of the engagement, to remember which is which.
The practitioners who treat the role as a recurrence will move faster than the ones who treat it as a discovery.
// DG