But there's an even better reason. Consistency, encapsulation of process, and a form of self documentation. This is the real goal - the time savings are a bonus.

For the next 6-12 months I get so much positive feedback about all the time that is saved while navigating the network drives.

I joke that the efficiency gains from its introduction organization-wide alone pay my salary!

But beware of Jevons paradox.

Say that eg. a software project has 10 developers, and each build takes ~15 minutes. Most developers would take at least some care to check their patches, understand how they work etc, before submitting. And then discuss follow-on steps with their team over a coffee.

Now imagine near-instant builds. A developer could copy-paste a fix & hit "submit", see "oh that doesn't work, let's try something else", and repeat. You'll agree that probably wouldn't help to improve the codebase quality. It would just increase the # of non-functional patches that can be tested & rejected in a given time span.

In other words: be careful what you wish for.

Thank you for sharing! I was inspired by the source material and created an interactive version of the formula mentioned in the source.