The question boards used to argue about was whether to fund a shared machine learning platform. That argument is over, and winning it bought nobody anything. Nine organisations in ten now report an internal developer platform, so the asset no longer separates anyone from anyone, and the research finds the effect of AI adoption on organisational performance swinging from strong to negligible on quality alone.
This report sets out five findings on where that swing comes from, and five decisions a board can carry out inside a quarter and verify afterwards with one artefact.
The findings describe one population splitting in two. Both halves hold a platform, a platform team and a budget line for AI tooling. These three properties are what separates them, stated so an executive can ask about each one directly rather than inspect an engineering practice.
Read the strong half's properties and most reduce to whether a team can finish a piece of work without stopping for somebody else. DORA put 5% on it in 2024: developer independence, the ability to complete a task without waiting on an enabling team, improved productivity at both team and individual level. It is the property AI tooling multiplies.
The strong half funds the platform as a product, with a named owner, a budget line and a backlog other teams can file into. Where it is instead charged to whichever product needed it first, that product's owner builds the version clearing their own deadline, which is the right call for them and the wrong one for the eight teams behind them.
Instability measured monthly is what lets a board tell a J-curve from a failure. Where throughput is reported and change failure rate is not, the trough looks like evidence the investment was wrong, and the funding moves to something promising a faster return. The half that measures both reads the same chart and holds the line for two more quarters.
Replace the existence line in the operations pack with two measured properties: how long a new team takes to reach production unaided, and how long a rollback takes with nobody from the platform team helping.
Apply 35% to 40% only to genuinely new build and 10% or less to complex legacy work, then set the result beside the number your board has already approved.
Change failure rate and time to restore belong next to throughput, monthly. The published value model assumes failure rate rises after adoption, so reporting only the upside guarantees a surprise later.
Set the review date beyond the expected trough rather than inside it, and give the platform one accountable owner with a published roadmap. A programme reviewed at month twelve against month-three performance gets cancelled on schedule.
Only with its qualification attached. It is the output of a value model built on assumed inputs for an illustrative 500-person organisation, about $11.6M returned on $8.4M invested with roughly an eight-month payback, and the report presents it as illustrative.
Cite it as a model and the sensitivity it carries becomes the useful part.
Probably not, and the dip is the expected shape. Platform engineering follows a J-curve: relief, then a trough as the platform takes on complexity, then recovery. Nothing in the data separates the organisations that abandon the programme from the ones that complete it except the decision taken while looking at that trough.
It puts you in the ninety per cent. Nine in ten organisations report an internal developer platform and three quarters have a dedicated team, so neither fact locates you anywhere in the distribution.
What locates you is whether a team that never asked for help can reach production and roll back on its own.
The 39% return, the eight-month payback and the 5% to 6% change failure assumption all come from the same illustrative value model rather than from a measured population. In the retelling, the return survives the journey into a slide and the failure assumption does not, which is how a sensitivity analysis turns into a promise.
Not here. This report describes the distribution and the decisions available at board level; it does not locate you inside it. Benchmarking MLOps and Model Serving is the hundred-point instrument for that, scored across four domains with an artefact behind every row, and it reads better after this one.
Executives and boards funding both the platform and the AI tooling that runs on it. It assumes the build decision is behind you, since it is behind almost everyone, and that the open question is what the platform hands the teams you are now asking to go faster.
Drop your details and we'll send The MLOps and Model Serving Report straight to your inbox - no spam, unsubscribe anytime.
Bring the two measurements the operations pack does not carry: time for a new team to reach production unaided, and time to roll back without help. We will work through what they say about the return. SECTION 7 - FAQ - 5 to 8 questions
Book a quality review