What Thirty Minutes of Waiting per Engineer per Day Really Costs

Half an hour a day. It sounds like nothing.

You wait for a build. You wait for someone to look at your pull request. You wait for an environment to free up, for an approval, for a pipeline that takes twelve minutes to do something that should take two. Nobody logs it, because it does not feel like time you are losing. It feels like the work. Work it through and it is €5,000 per engineer per year. At a hundred engineers, half a million euros. Every year, on no line of your P&L.

There is no trick in it. You can check it against your own numbers:

• Half an hour per working day is 2.5 hours a week.
• At roughly 220 working days a year, that is 110 hours per engineer per year.
• At a loaded cost of about €45 an hour, that comes to €4,950, call it €5,000.
• A hundred engineers: €495,000 a year.

Substitute your own rate. The point does not change: this is not a rounding error, it is a payroll line the size of a small team, and there is no invoice attached to it.

Once you start watching for it, it is almost never one big block. It is small pieces that accumulate:

• Waiting on builds and tests. An eight-minute pipeline run five times a day is forty minutes. If it is flaky, you run it more often than that.
• Waiting on review. Usually the largest single component, and almost never measured separately. Your pull request is ready; your colleague is in a meeting.
• Waiting on environments. One staging, three teams.
• Waiting on approvals. Somebody has to tick a box and that somebody has other things on today.
• The hidden cost of switching. This is the cruellest one. Fifteen minutes of waiting rarely costs fifteen minutes: you start something else, and finding your way back to where you were costs another ten.

You see cloud costs and licences because an invoice arrives. Waiting comes from nobody, so it arrives nowhere. There is also no moment where anyone decides. Nobody ever approved an eight-minute pipeline; it grew there over two years, one reasonable step at a time, and every individual step was defensible. And the people it hurts most are precisely the people least likely to raise it. Waiting does not feel like something you escalate. It feels like how the work is now.

This is the part that catches most teams out. If code gets written faster, there is not less waiting. There is more: more changes reach the review queue sooner, and the same reviewers and runners have to divide themselves up. The bottleneck does not disappear, it moves to where no model can reach it.

Which is exactly why making code cheaper does not remove the cost but concentrates it. We set that argument out in where we stand on AI in software engineering: once writing stops being your constraint, everything around it becomes your constraint, and only then do you find out whether you ever measured it.

This does not need a programme. Three things surface most of it:

• Break lead time into phases. A single number from commit to production hides exactly what you are looking for. Once writing, waiting for review, testing and deploying are separate, the largest component announces itself.
• Measure review latency on its own. The time between "ready for review" and "somebody looked at it". In most teams this is the biggest single component, and almost nowhere is it on a dashboard.
• Measure pipeline duration, not just whether it passes. A pass rate tells you nothing about the time you spend waiting for it.

Measure for a month before you change anything. Without a baseline you cannot demonstrate an improvement afterwards, and then the strongest opinion wins the argument. The interventions are rarely dramatic, which is exactly why they never get done.

• Agree a review turnaround. "Pull requests under 300 lines get reviewed within 24 hours" often removes more waiting than any technical change.
• Make pull requests smaller. Smaller changes get reviewed sooner, and the waiting falls faster than the size does.
• Speed up the pipeline with caching and parallel tests. Eight minutes to three, across a hundred engineers, is a serious number.
• Give every change its own environment instead of queueing for shared staging.
• Remove approvals that never block anything. A box that is always ticked delays without controlling anything.

Halve those thirty minutes and across a hundred engineers you recover a quarter of a million euros a year. That is not a saving you have to win in a budget round. You only have to know it is there. Half an hour per engineer per day is €5,000 a year per person and half a million across a hundred. No invoice records it, nobody approved it, and it grows on its own as long as nobody is watching.

My claim: most teams investing in AI tooling right now would get less out of it than out of halving their waiting time, and they do not know it, because they measure the one and not the other. Once writing gets faster, waiting is the only thing left that matters. So measure it before you invest. Otherwise all you will know afterwards is that you produce code faster, not that you deliver anything sooner.