Cost of Delay

The partial derivative of how money changes as a function of time.

Last week’s paper on Software Development Waste prompted me to look into the Cost of Delay model, a concept introduced by Don Reinertsen in the book Principles of Product Development Flow. Cost of Delay is a method for calculating the monetary value of potential product investments that is fairly well known within Lean-Agile circles. I have recently met several engineering leaders who use Cost of Delay to justify investments in improving developer experience, so I wanted to learn more.

My summary of Cost of Delay

This summary is based on Don Reinertsen’s book and several related talks.

We’ve all heard the aphorism “time is money”, but how does time impact money when it comes to delaying the release of new products or improvements?

Cost of Delay (CoD) is a quantitative model for addressing this question. Described by Don Reinertson as the “partial derivative of lifecycle profit with respect to a change in the availability of a product”, CoD is the partial derivative of how money changes as a function of time, in terms of dollars per unit time. (e.g., “$10,000 per month). In layman’s terms, CoD transforms “change in time” into “change in money”.

A core principle behind this model is that profit depends on availability. That is, the realizable profit from a product depends on when it becomes available, therefore, prioritization decisions can be made based on monetary value. For example, if you have two products, how do you decide which of them to prioritize? The answer — assuming equal costs to build — is that you would delay the product with lower CoD in order to service the one with higher CoD.

CoD can also help determine the monetary impact of deferring products or improvements that are being given lesser priority. In other words, opportunity cost. This is where I’ve seen it being used by engineering leaders.

Applying Cost of Delay to engineering

Most engineering organizations’ primary focus is to deliver value to customers. As a result, internal problems are deferred and slowly pile up.

Last week’s paper on Software Development Waste highlighted factors such as technical debt, inefficient tools, and difficult frameworks or libraries as common areas of waste in software development. Developers and leaders regularly experience the pain of these problems, yet are often unable to convey the importance of addressing them to business stakeholders and executives.

CoD can help engineering leaders garner support for internal improvements by presenting them in monetary terms that matter to the business. For example, Crystal Hirschorn from Snyk’s Platform group regularly uses CoD calculation to get support for initiatives. “We calculate the cost: how many engineers we have and their salaries, and tools we’re running for a period of time. Then we look at what the business impact would be if we, for example, reduce build times from 40 minutes to 20 minutes.”

As Crystal’s example shows, CoD may be useful for gaining support for projects that stakeholders may otherwise not realize the value of. Developers often complain about the lack of time spent on technical debt, saying for example: “It's frustrating how little time we're spending on technical debt, it feels like product managers only want to ship features.” The CoD model may provide a path for rational, sustainable investments in developer experience.

---

That’s it for this week! If you know someone who would enjoy this newsletter, please consider sharing it with them.

As always, reach out with thoughts about this newsletter on Twitter at @abinoda, or reply to this email.

-Abi