The value is in the translation layer
There is a version of the artificial intelligence story where the value accrues to whoever builds the most capable model. It is a good story and it is mostly about a handful of companies that will not include yours.
There is a second version, less discussed, in which a large share of the value goes to whoever works out how existing institutions can actually use the thing. Not who invented it. Who made it usable at scale, inside organisations that have regulators, legacy systems, procurement cycles, risk appetites and people who were doing a different job last year.
I find the second story more interesting, partly because it is where I work, and partly because it is where the evidence points.
The pattern is not new
Electrification is the standard example and it is worth being precise about why.
Electric motors were available to factories for decades before factory productivity moved. The technology was not the constraint. What took thirty years was rearranging the factory: abandoning the central steam engine and the overhead line shafts, and rebuilding the layout around machines that could each have their own motor and sit wherever the work made sense.
The value did not come from the motor. It came from the reorganisation the motor permitted, and that reorganisation was slow, unglamorous, and mostly done by people whose names are not attached to the invention.
The same structure shows up in every general-purpose technology. There is a capability, and then there is a long, expensive, institutional process of becoming able to use it. The second part is where most of the time goes and, frequently, most of the money.
What this looks like now
Sit in an enterprise for a while and the pattern is hard to miss.
The organisation has models that work. It has teams that can build them. It has executives who want the capability and are willing to fund it. And it has a surprising amount of work sitting in a state that everyone describes as almost ready, for periods measured in quarters.
The blockage is rarely the model. It is that the organisation is not yet arranged to run one. Nobody has decided who operates it. No control function has seen anything like it before, so nobody knows what evidence to ask for or to bring. The downstream business process was designed around a human making the decision. The cost model assumed inference was free. The team that built it is funded to build things, not to run them.
None of that is a research problem. All of it is a translation problem, and it is where a specific kind of work becomes valuable: knowing enough about the technology to be credible with the engineers, and enough about the institution to be useful to the people who have to sign.
Why this is genuinely hard
It is tempting to describe this as coordination, which makes it sound like project management with better vocabulary. It is harder than that, for three reasons.
Nobody owns the whole path. Every control function owns its own decision, and correctly so. The delivery team owns the build. Operations owns running things. The business owns the outcome. The route through all of them is owned by nobody, which means it does not exist as an artefact, which means each team rediscovers it. That rediscovery is expensive and invisible, and it gets misattributed to governance being slow.
The requirements are legitimately unclear at first. When something is new, a control function cannot tell you what evidence it needs, because it has not yet decided. This looks like obstruction from the outside and is nothing of the kind. The work is to help them decide, which requires understanding both what the technology actually does and what the control is actually for.
It is hard to make visible. A model with strong performance metrics demos well. A repeatable path from experiment to production does not demo at all. Its value shows up as the absence of a delay that nobody attributed to its absence in the first place, some months later, in somebody else's project.
That last point is why this work is chronically underfunded, and it is worth naming, because it is a real career problem for anyone who does it.
Where value actually lands
The framing I have found most useful is that value in this kind of work is created at the point where a capability becomes governable, repeatable and fundable.
Governable means a control function can say yes to it, and knows what it is saying yes to. Repeatable means the second instance is materially cheaper than the first, because the path is now known. Fundable means somebody owns the ongoing cost with their eyes open.
A capability that is none of these things is a demonstration, whatever its technical merit. A capability that is all three is infrastructure, and it compounds. The gap between those two states is not a technical gap and does not close on its own.
What follows from this
If it is right, a few things follow that are inconvenient for how organisations usually plan this work.
The first instance of anything is infrastructure, whatever the plan calls it. It is where the organisation decides how that class of work happens. Scoping it as a single delivery gets you the delivery and not the capability, and the second team starts from nothing.
Elapsed time and wasted time need to be separated in the conversation, because work that involves control functions early takes longer on the calendar and substantially less effort in total. Defending the calendar without making that distinction is a losing argument you did not need to have.
And the people who do this work should be assessed on the second instance rather than the first, which almost nobody does, because the second instance is where the compounding shows up.
The unglamorous conclusion
The organisations that do well out of this technology shift will not, in the main, be the ones with the best models. Very few organisations will have the best models. They will be the ones that got good at absorbing capability repeatedly: that built the path once, kept it current, and could take the third and fourth and fifth use case through it without ceremony.
That is a boring competitive advantage. It is also, on the historical evidence, the durable one.
I spend my working life on that layer. Most of what I write here is some version of this argument, applied to something specific.
No spam, no sharing to third party. Only you and me.
Member discussion