You're underestimating the scope of time lost by losing a few percent in productivity per employee across hundreds of thousands of employees.
You want speed limits not speed bumps. And they should be pretty high limits...
After I saw the announcement, I immediately knew I needed to try out our workflows on the new architecture. There was just no way that we wouldn't have x86_64 as an implicit dependency all throughout our stack. I raised the issue with my manager and the corporate IT team. They acknowledged the concern but claimed they had enough of a stockpile of new Intel machines that there was no urgency and engineers wouldn't start to see the Apple Silicon machines for at least another 6-12 months.
Eventually I do get allocated a machine for testing. I start working through all the breakages but there's a lot going on at the time and it's not my biggest priority. After all, corporate IT said these wouldn't be allocated to engineers for several more months, right? Less than a week later, my team gets a ticket from a new-starter who has just joined and was allocated an M1 and of course nothing works. Turns out we grew a bit faster than anticipated and that stockpile didn't last as long as planned.
It took a few months before we were able to fix most of the issues. In that time we ended up having to scavenge under-specced machines form people in non-technical roles. The amount of completely avoidable productivity wasted from people swapping machines would have easily reached into the person-years. And of course myself and my team took the blame for not preparing ahead of time.
Budgets and expenditure are visible and easy to measure. Productivity losses due to poor budgetry decisions, however, are invisible and extremely difficult to measure.
> And of course myself and my team took the blame for not preparing ahead of time.
If your initial request was not logged and then able to be retrieved by yourself in defence, then I would say something is very wrong at your company.
You are suggesting a level of due process that is wildly optimistic for most companies. If you are an IC, such blame games are entirely resolved behind closed doors by various managers and maybe PMs. Your manager may or may not ask you for supporting documentation, and may or may not be able to present it before the "retrospective" is concluded.
But regardless, I already left there a few years back.
That seems unreasonably short. My work computer is 10 years old (which is admittedly the other extreme, and far past the lifecycle policy, but it does what I need it to do and I just never really think about replacing it).
It depends what you're working on. My work laptop is 5 years old, and it takes ~4 minutes to do a clean compile of a codebase I work on regularly. The laptop I had before that (which would now be around 10 years old) would take ~40 minutes to compile to the same codebase. It would be completely untenable for me to do the job I do with that laptop (and indeed I only started working in the area I do once I got this one).
For a single person, slight improvements added up over regular, e.g., daily or weekly, intervals compound to enormous benefits over time.
XKCD: https://xkcd.com/1205/
Saving 1 second/employee/day can quickly be worth 10+$/employee/year (or even several times that). But you rarely see companies optimizing their internal processes based on that kind of perceived benefits.
Water cooler placement in a cube farm comes to mind as a surprisingly valuable optimization problem.