Notes on the engineer in the room.
Or: what forward-deployed engineering is rediscovering, and what's actually new about it.
This week, two of the largest AI companies announced ventures backed by some of the most established names in finance. Both ventures are about the same thing: placing engineers inside operating organizations to redesign workflows around frontier models. The capital structures are large by any measure. The framing, in both announcements, 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 has been in financial services for thirty years, 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 genuinely 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 the late 1990s, 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.
The technology was different in each iteration. The role was the same.
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. People's memories are shorter. On a stress-testing platform consolidation at Morgan Stanley a few years later, we ran into a data-corruption issue that none of the contemporary documentation could explain. The problem was traceable only because a senior engineer remembered why a particular shortcut had been inserted into the codebase years earlier. That kind of institutional reading (knowing where the bodies are buried, knowing whom to ask, knowing 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. I have argued elsewhere on this site that the metric you can measure is rarely the metric that matters. I will not relitigate that here. I will note that 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, more honest 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 is not standing in the way of progress. They are the reason the firm has progressed this far. Treat them as obstacles and the engagement loses. Treat them as teachers and the engagement has a chance.
What's actually new this time
All of that said. Some things are genuinely different in this iteration.
The capability of frontier models is different in kind from what came before. They write working code. They reason across domains. They negotiate ambiguous instructions in ways that deterministic software could not. An engineer placed inside a portfolio company in 2026 can ship things in a week that would have taken a small team three months in 2020. The leverage is real.
The pace is also different. Prior cycles (electronification, the buy-side outsourcing wave, the cloud-and-data era) 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 for that velocity, not in spite of it.
And the capital itself is bigger. The implicit return guarantees attached to some of the new structures, and the multi-billion-dollar anchor commitments behind them, are signals that the institutions writing the checks expect this work to redefine portfolio-company economics, not merely improve them. That changes the political weight an embedded engineer walks in carrying. It also changes the length of the leash.
None of this changes the people-work. Some of it changes the work itself.
What I keep
The institutions hiring forward-deployed engineers are buying engineers, but what they are actually paying for is judgment formed across many prior engagements. That judgment is what the established consulting firms have always sold. The new ventures are now competing 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 encountering it for the first time. It is useful, on both sides of the engagement, to remember which is which.
Forward Deployed Engineering is the latest name for a role that has been in the room before. The technology is genuinely new. The role is not. The practitioners who treat it as a recurrence will move faster than the ones who treat it as a discovery.
// DG