Editor’s note: This article was written by Dr. Mik Kersten. Dr. Mik Kersten is the CEO of Tasktop and author of Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. For more information, please visit, www.tasktop.com.

While “technical debt” is a term that’s frequently used by technologists, the implication and understanding of it tends to be opaque to the business until it’s too late – just look at how Nokia lost the mobile market that it helped create.

The business and finance side of Nokia had the usual tools for assessing financial risks – but why do we not have an equivalent tool for the operational or existential risks when the debts come from the more intangible investment in technology?

What’s technical debt?

Technical debt refers to the refactoring “shortcuts” taken in IT to meet requirements like time to value (TtV) and speed-to-market. Technical debt is like cholesterol; the more it accumulates, the more it impedes the flow of value.

Legacy systems are a perfect example of technical debt. We are all too familiar with that system that everyone dreads to touch and hopes that it doesn’t malfunction because any modifications to improve its business value will cost time and money. Yet the longer you wait, the costlier it will get due to lack of knowledge and support.

Speed-to-market pressures also increase the debt – such as first-to-market, responding to time-critical customer needs, and faster customer feedback to improve performance and value. Compromises are made with the notion of dealing with the consequences later.

Sometimes it’s as simple as realizing the technology or architecture chosen for a particular product is no longer scaling and needs refactoring. All of these technical decisions impact delivery speed and must be managed to ensure any future changes or products are not delayed. Taking on technical debt is not necessarily a bad thing, as long as it is understood by the business decision makers who put in place a plan for that debt to be paid down.

Why should the business care – isn’t this a cost that IT manages?

Technical debt additionally impacts delivery teams by bloating their work-in-progress (WIP) with neglected work. Neglected work can impact a team’s ability to focus and complete value-adding work. Less completed work leads to longer time to delivery, lower product quality, and less value, impacting customer satisfaction and business performance.

How can IT make technical debt visible to the business?

In a project-oriented view, where changes to IT systems are just another initiative, it’s difficult to prioritize and fund critical changes that will improve the speed of future changes. Yet software needs to go through a period of refactoring to maintain performance.

A product-oriented view enables the business to understand how all work interlinks, providing the ability predict and fix for the impact of technical debt. However, you can’t measure what you can’t see, so it’s crucial to make technical debt visible. The Flow Framework – a new way of seeing, measuring, and managing product delivery – introduces two metrics that help increase visibility of technical debt:

Flow Distribution

This metric shows the distribution of the different types of work that the IT team has delivered, such as value-adding work like features and functionality, and revenue-protecting work like defects, security related work. Yet the more new functionality they deliver, the less time they have to do the other types of work like defect resolution, working on security features etc. It’s important to keep an eye on what the levels are for technical debt in this equation. Has the level of completed tech debt work fallen in the last few releases? If so, it is leading indicator of more defects/delays in the future releases. In addition, the Flow Framework expands on the notion of technical debt to include infrastructure debt (e.g., data centers and servers), and debt in the value streams themselves (e.g., lack of automation).

Flow Load

Flow Load is a Flow Framework metric that shows the amount of work that a team or seat of teams have taken on. How much work do they have and what proportion of it is technical debt? Is there a lot of technical debt left in the backlog accepted but unfinished because new work is taking precedence? Accumulating technical debt on the backlog can have an increasingly negative impact a company and its products.

Budgeting for technical debt

There are two parts to budgeting for technical debt.

1. Correlating the impact of tech debt with value-adding work can help business understand its danger on the bottom line. Time and resources must be set aside every financial year to tackle technical debt as debt often accumulates due to a lack of funding and sponsorship.
2. IT and business should look at trends that determine an appropriate level for when appropriate action must be taken to “pay back”. It’s similar to the error budget in Systems Reliability Engineering that helps product development and system reliability teams work together on a level of unreliability that can be tolerated.

If technical debt is not actively monitored, it will gradually impact the flow of value to customer-facing products. Neglect the build-up and a cardiac arrest is inevitable. Make sure technical debt is visible and measured so that the business and IT can team up to proactively tackle and reduce technical debt to ensure a healthy product portfolio that can sustain the business.

Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework