Last week I found myself arguing with one of our engineers at Simple Energy about the ‘correct’ implementation of a feature. This argument centered around the issue of accruing ‘tech debt.’

(If you’re not familiar with the concept, check out the wikipedia page.) He argued that a longer implementation time to add additional functionality would save us time in the future. I argued for a shorter, less full functioning solution which was ‘good enough,’ but would likely lead to a small number of distractions for the engineering team in the future. We have very intelligent and highly capable engineers at Simple Energy, so I knew when we couldn’t reach a mutually agreeable conclusion, that I was missing something.

 

One of the most difficult things to work into any engineering workflow — in all the startups I’ve worked at — has been tech debt. This issue becomes highly charged at times because it is painful to deal with for the engineering team, but often hidden or difficult to see for the business decision makers. Having previously coded and led engineering teams, and now leading a product management team, has given me perspective into both sides of this argument, yet I still found myself frustrated trying to explain my position.

 

Then suddenly it hit me. The engineer was convinced that his side had merit because in spending extra time building this feature right, he would be saving more time than he spent in the future. There was a clear net gain, so why would we not build it? The answer is actually relatively simple: opportunity cost.

 

Opportunity cost is an economic concept used to address the allocation of a scarce resource towards mutually exclusive investments. In the tech debt scenario, our scarce resource is developer time and the mutually exclusive investments are specific instances of tech debt.

Example

 

Let’s look at an example to bring some clarity to this. Let’s assume that I have 1 engineer across a four week period and 4 pieces of tech debt with estimated paybacks over the next 18 months. (Granted it’s never this black-and-white in the real world — maybe just try to put it in hours, days, weeks, months instead.)

Item	Initial Cost	Time Saved — over next 18 months
Issue A	3 weeks	5 weeks
Issue B	1 week	4 weeks
Issue C	3 weeks	8 weeks
Issue D	6 weeks	5 weeks

 

Looking quickly at this list, we can see that Issue D should simply never be address. It has a net value of -1 week of productive time. From there it gets trickier though. We have 3 issues, all of which will provide net productivity gains from completion.

 

Yet we don’t have infinite resources; we have 4 person-weeks of time. Assuming the repayment of the debt is simply evenly distributed across the next 18 months, we will want to make sure that those limited resources are being used to address the largest gains possible first. In this case, Issue B wins by providing us with a 4x multiplier on our investment. Following this, Issue C gets us a 2.67x multiple and Issue A returns 1.67x. Therefore, our best option is to invest our 4 weeks into issue B followed by Issue C, returning a total of 12 weeks of benefit for our 4 week investment.

 

Looking at this through the lens of opportunity cost, we see that addressing feature A comes at the cost of not addressing 2 higher return issues, leaving us with a less-than-optimal outcome. This means our best choice is not to address issue A0 at all in this scenario.

 

This is the piece I was missing while explaining why I didn’t believe we should have been addressing the issue raised by our engineer. While building this feature ‘right’ would cost us roughly a week and likely save us 1-2 weeks of wasted time in the future, there are a number of other items in our tech debt backlog which we could be spending time on which will provide higher-than-1-2x multipliers on time investmented. Those are where we should be focusing our time, or we will lose ground with competitors, or worse, run out of capital before we reach our goal.

 

Coming Soon:
All this theory is nice, you may say, but how the hell do I intelligently put tech debt into my feature backlog? Well, that’s for another blog post.