Interest rates and maturity as tools for discussing technical debt

Leveraging concepts about debt from the financial industry, such as “interest rates” and “maturity” can help business, product, and engineering leaders find common ground when debating whether to build the quick, hacky version of a project, or take the time to build it the right way.

For the past 5 years, I've been at the EdTech company Clever, primarily leading the development of new products. When we were designing the first backend for one of those products, the Clever Library, we needed to make a decision: should we build a quick version that we’ll have to replace eventually, or should we spend more time up-front but save time in the long run by building the “right” version today? There is plenty of standard advice on this topic - “premature optimization is the root of all evil,” etc - but these truisms can feel dismissive to the teams that are asking very legitimate questions of why we would burden our future selves with extra work and technical debt. This is especially true when engineers feel like they have to fight hard to get company leadership to invest in projects that pay down technical debt. Instead of truisms, consider using concepts around debt used by the financial industry to discuss these sorts of trade-offs and build buy-in around doing the clean-up work later.

The reason why a company would assume financial debt is the time value of money: a dollar today is worth more than a dollar in the future, because we can use the dollar today to grow our business and (we hope) make more than a dollar tomorrow. Along similar lines, the core reason why a company might want to assume technical debt might be called the “time value of time”: a week of work is worth more today than a week of work in the future, because we can use the work today to learn new things from our customers and grow our business.

Borrowing concepts from the financial industry, we can think about building the quick, hacky version of a project as taking on a loan, with a particular principal, interest rate and maturity period, and use that to make a more informed decision. Taking the Library as an example - the engineering lead estimated that the quick version would take about 2 weeks and the full version would take about 6 weeks. If we did the quick version, we’d buy ourselves roughly 6 months before we’d have to replace it. However, the replacement would be more expensive than if we built the backend the right way up front, because we’d have to remove the old code and perform a risky backend migration on a live product. The engineering lead estimated that the eventual re-write would take 3 months, double the 6 weeks it would take to build it up-front. Putting this in terms of debt: we’re buying 4 weeks of time today, at a cost of an extra 6 weeks that we’ll have to pay down in around 6 months.

In the case of the Library, we were building a brand new product, and there was a high chance that we’d either shut it down or make major changes within 6 months based on customer feedback, so it made sense to take the “loan” and build the quick version. Bringing these “financial” terms into the conversation helped the engineering team understand the rationale for doing the quick version today, while building support with company leadership that if the product were successful, we’d have to pay down this loan in the future.

As it turns out, the Library has been a significant success, and when the time came eight months after launch to pay down the debt and rebuild the architecture, the engineers had full support from company leadership. Over the course of the months that the simple version bought us, we validated that the product was worth investing in, understood more about how customers used the product and how the backend should be designed, and grew the team from 1 to 5 engineers - well worth the extra cost!

I use the following table as a rule of thumb when making decisions about the “time value of time” in a startup environment, and find it very useful as a tool for having healthy discussions around technical debt.

The "interest rate" I'm willing to pay is fairly high, which I believe makes sense given the high velocity of change in startups; surfacing frameworks like this is one way that I make these beliefs explicit and encourage discussion.