A single number carries most AI tooling decisions, and it is usually the 39% first-year return from DORA's value model. The same model assumes change failure rate climbs from 5% to 6% and books $344,000 of downtime against the organisation.
Those are not a benefit case and a risk case drafted by different teams. They are two outputs of one arithmetic, driven by the same thing: more change, produced faster, arriving at production.
Both figures are illustrative rather than observed, which is precisely why they can be argued with.
Give the same model to two organisations of the same size with the same tooling spend and the same engineers. What separates the outcomes is organisational, and all of it is visible to an executive without reading a line of code.
One executive name against the instability the model predicts, reported wherever the throughput gain is reported. Organisations without that owner meet the modelled failure rate through incidents instead, which is a slower and more expensive way to learn it, and by then the discussion is about an outage rather than about a capacity nobody funded.
Greenfield and legacy effort separated in the plan, with the high gain rate applied to one and the low one to the other. A single blended percentage is where the greenfield assumption hides, and nobody can challenge a blend they were never shown. Counting the split takes a week and moves the answer further than any debate about which assistant to buy.
A named individual able to halt a release without asking first, and backed afterwards rather than questioned. This is the cheapest item on the list and reliably the hardest to get signed, since it hands one person the ability to interrupt trading for a reason nobody has yet confirmed. Everything else here costs money or a week of counting; this one costs only political capital.
Take the published model's structure and substitute your headcount, loaded cost, current failure rate and work mix. Require the output to carry the instability line as well as the return.
Count the share of engineering capacity pointed at genuinely new systems against the share absorbed by code nobody wants to touch, then apply the two Stanford rates separately rather than one blend.
Put a person's name against the instability the model predicts, in whatever pack already carries the upside. The owner tends to become the person asking for review capacity, which is the point.
DORA describes seven. Write down which one your organisation is, who decided it and when it was last examined. An afternoon of work, and most boards cannot currently answer it.
No. The figure comes out of a value model whose inputs were assumed rather than measured, set at a notional 500-person scale where about $11.6M of first-year return sits against $8.4M of spend and the payback lands near month eight.
No population was surveyed arriving there, and DORA says as much. Treat it as a structure to re-run, not a result to quote.
That trade is not on offer. The throughput gain and the additional failures come from the same cause, which is more change produced faster and arriving at production. What you can change is what sits in between: review capacity, release gating, rollback and a standing authority to stop.
Those make one number smaller without dragging the other down with it.
Stanford research cited by DORA puts the gain near four times higher on simple greenfield work than on long-lived code, at 35% to 40% against 10% or less. That spread is set by what your engineers spend their week on, not by which assistant they use.
Two firms with identical tooling budgets land at opposite ends of it.
The research does not nominate one, and neither do we. Seven stable patterns were identified across nearly 5,000 technology professionals, which tells you a shape exists whether or not anyone named yours.
The useful act is to write down which one you are running, who chose it and when it was last examined.
It becomes queue rather than delivered change. DORA 2024 put developer independence, defined as completing a task without stopping for an enabling team, at a 5% productivity improvement for teams and individuals alike.
Code produced faster only reaches the business if it can then move, and the queue an engineer waits in is usually a reporting line before it is a piece of software.
After. This report tells you what the distribution looks like and which numbers are modelled rather than observed. Benchmarking Engineering Team Design for AI is the scoring instrument, and it reads better once you know that the seven archetypes carry no ranking and that the return figure comes with an instability assumption attached.
Boards, CTOs and VPs of engineering who have to approve an AI tooling case and will be asked afterwards what it bought. It assumes you have seen the 39% figure on a slide and now want the rest of the model it came out of.
Drop your details and we'll send The Engineering Team Design for AI Report straight to your inbox - no spam, unsubscribe anytime.
Give us the path a change takes from one of your teams to a customer, and we will walk two weeks of it with you to find what your own failure rate and waiting actually look like. SECTION 7 - FAQ - 5 to 8 questions
Book an engineering shape review