Sixty engineers each wait for a build roughly 15 times a day. The build takes 4 minutes. Roughly what does that cost a year, and what does the number rule in or out?

The arithmetic, shown

• 60 engineers × 15 builds × 4 minutes = 3,600 minutes a day, which is 60 hours a day.
• Over roughly 230 working days: 13,800 hours a year.
• At about 1,700 productive hours per engineer-year: roughly 8 engineer-years.

The distractors are the three ways people get this wrong. 0.3 counts one engineer's time. 1.5 counts a day's 60 hours against a year of one person, which is the arithmetic slip of mixing daily and annual units. 25 assumes every minute of waiting is a minute lost, ignoring that some waiting overlaps with useful work.

The assumption that dominates the error

How much of the wait is actually lost. A 4-minute wait is the dangerous length: too long to hold attention, too short to start something else, and long enough for a context switch whose recovery cost exceeds the wait itself. Research on interruption consistently finds recovery measured in minutes rather than seconds, so the real cost is plausibly higher than the raw wait, not lower.

The second dominant assumption is build count. Fifteen a day is a team with a fast test suite; teams with slow feedback build less often and pay elsewhere, in larger changes and later discovery of defects. A low build count is a symptom, not a saving.

What the number rules in or out

8 engineer-years a year justifies a dedicated person on build performance, and most organisations will not staff one because the cost is spread across every engineer's day instead of appearing in a budget line. That is the argument to make: the work is already being paid for, invisibly, in the currency the organisation is shortest of.

It also sets the bar for what is worth doing. Halving the build saves about 4 engineer-years, so a remote build cache, more parallelism or better test selection at a cost of one engineer's quarter pays back inside a month. Conversely, shaving 4 minutes to 3 minutes 30 is under an engineer-year and probably not where that quarter should go.

When this estimate is the wrong argument

When the build is not the constraint. Measure before spending: if the same engineers wait 40 minutes for a preview environment or two days for a code review, the build is the cheapest number to compute and the wrong one to fix. The general rule, consistent with what the DORA research programme has reported since 2018 about feedback speed, is to instrument the whole inner loop and attack the largest wait. Choose the build only if it is the largest one; otherwise the investment fails the same way a faster car fails in traffic, and the 8 engineer-years stay where they were.