Making the Case Without Overclaiming

The standard business case multiplies build minutes by developer cost and presents the product as a saving. It rarely survives the first question.

Why the time-saved figure fails

Saved minutes are not recovered as output. Ten minutes returned to a developer's day does not produce ten minutes of extra feature work, and everyone in the room knows it.

It assumes uniform utilisation, which is not how development works.

It is unfalsifiable, which finance recognises immediately.

One challenged number discredits the rest, including the ones that were sound.

What holds up

Batch size. Faster feedback produces smaller changes, and this is directly measurable: changes per pull request, before and after. Smaller batches are easier to review and to debug, and that argument does not need a currency figure.

Failure localisation. Time from a failing build to identifying the cause, measured.

Pipeline cost, which is a real invoice. Caching, better selection and right-sized runners reduce compute spend, and that appears in a bill someone already receives.

Onboarding time. Days from a new joiner's first login to their first merged change. Concrete, comparable, and it is a number recruitment and management already care about.

Reliability. Proportion of failures that are genuine. A pipeline whose red is meaningless has stopped functioning as a control, and that is a risk argument rather than a productivity one.

Retention, carefully. Toolchain frustration appears in exit conversations often enough to be worth mentioning and not worth quantifying.

The strongest single argument

Trust in the signal.

If a red build is assumed to be flaky, people retry it. If they retry it, genuine failures reach the main branch. If genuine failures reach the main branch, everyone downstream loses time and the safety net has stopped existing.

That is a correctness argument, not a speed one, and it lands with people who are unmoved by developer convenience.

What to commit to

Not a percentage improvement in productivity.

A specific change in a specific measure, with a date and the same measurement method afterwards.

"Median time from push to first signal from fourteen minutes to under five within two quarters, measured the same way."

Checkable, which is uncomfortable and is exactly what makes it fundable a second time.

Sequencing the argument

Start with the cheapest visible win, and report it.

Then the pipeline cost reduction, which pays for the work in a currency finance recognises.

Then the reliability argument, which is the one that gets the structural investment.

Leave developer experience last, not because it is unimportant — it is the actual point — but because it is the least persuasive to the people approving budget, and by then you have their attention.

The pipeline bill

The argument that works with people unmoved by developer experience, because it arrives as an invoice.

Compute current CI compute spend, which finance already receives.

Identify the waste: runs on unaffected changes, cold caches, superseded runs not cancelled, oversized runners.

Estimate the reduction conservatively from measured cache hit rates and selection ratios.

Report the actual bill afterwards, not the projection.

This is the one number in the field that appears in the general ledger, which makes it the easiest to defend and the right one to lead with.

What to promise

Commit to something checkable, which is uncomfortable and which is what makes the second phase fundable.

Not a productivity percentage.

A named measure, a target, a date, and the same measurement method afterwards.

"Median time to first signal from fourteen minutes to under five within two quarters."

Report it on the date, whether or not it was met.

A missed target reported honestly costs less than a met one nobody believes, and it is the difference between a programme that gets a second year and one that does not.