Why is it difficult to reflect tech debt on the balance sheet

Spelling out the cost of technical debt in a financial sense is crucial for several reasons:

• We are expanding markets and portfolios, but the product keeps breaking. The gazillions we spent on development are still not enough?
• We budget and plan, but now we don’t have enough resources to deliver feature on time. Where did we waste our money?
• Our velocity is too slow for the money we put in. Where did it all go?
• We need to be more cost-effective and sustainable for our future value, where shall we start?
• We don’t seem to innovate any more. But everyone looks so busy. What are they doing?

Can you capitalise tech debt? Does it have to be on a balance sheet? Would putting it on the balance sheet jeopardise the financial health appearance of a company…? Disclaimer: I went to business school, but Accounting and Finance courses I never knew how I passed. So there won’t be any discussion on financial technicalities.

The call for reflecting tech debt on a balance sheet stemmed from wishes and frustrations.

Wishes

If we substantiate tech debt with a € sign next to it, we’ll treat it seriously, shape it up, and suffer less from it ever after.

Frustrations

Everyone tosses their discontent at the product team for being slow, not delivering, and doing the wrong things. Revealing the true face of what’s killing our product can be a way out of this scapegoating.

So why can’t we do that?

Debt is not the worst

Not all debt needs to be repaid. If the biggest countries in the world don’t pay their national debts, surely a company can stand straight and ignore a bit of tech debt. Currency devalued? We just raise the price.

Business needs investors. Investors need to see growth. Growth requires expansion — into new markets or new segmentation. So far so good, until product adaptation becomes essential. Among the chained events, the worst is by far not tech debt.

PM’s self-defeating effort

To point out tech debt to a level that attracts C-level attention, it has to be openly spoken of. As PMs, we are not always helpful.

From when we define the features, compromises are already made:

Due to the legacy, when we develop this new feature, let’s scope out any functionalities that touch upon that part of the code, so that we can move forward with the development.

And we do this with calculated risks, which we are incentivised to justify when being questioned. We’d justify them based on customer use cases and market needs, cuz they are the strongest evidence, and we mention less about the technical drivers — it will take indefinite development time if we were to cover the legacy.

Prioritisation gets in the way

Every minute the Devs are doing refactoring is a minute they are not “shipping features”, which is what they are supposed to do in a strict conventional sense. In the meantime, it’s a common setup that Devs report to the Engineering department, not PMs. So PMs don’t have Dev resources, we must win them based on a set of criteria, in which priority matters greatly.

The truth is when we must drive the desired business outcome, we can’t treat tech migration at the same level of priority, although it’s utterly important. Whenever we run into a resource crunch, we are asked to prioritise. And we prioritise business impact most of the time and live with the guilt. No root cause analysis. No more mention of tech debt.

Nearly impossible to quantify tech debt

When there’s tech debt, the development is slow, the code quality is low, and the innovation is blocked. But by how much? e.g. speed.

What a small start-up can produce in a month can outperform what big organisations can do in a year. Does that mean the big org is 12 times slower than it should be? Start-ups can be born with the new technology that older products didn’t have the chance to. With more customers onboard, even if not making too many changes to the product, each small change creates significantly more impact than start-ups with fewer customers.

Lastly, there are many more reasons and hurdles, especially from the perspectives of Ops and Devs. But at the end of the day, the entire organisation needs to think the same and work together towards calling the tech debt out. And it’s just the beginning. How to reduce tech debt and how to follow through with the plan will be the actual key.

What’s your experience or success story in handling tech debt? I’d love to hear from you.