Technical debt is a myth

Now, I know what you’re thinking: Technical debt can’t be a myth. It has a clear definition and meaning. Ward Cunningham defined it for us:

When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.

It’s an interesting definition. In many ways it feels right, but if we take a step back and look at the bigger picture, I think it’s clear that Technical Debt is used to identify a local symptom of a systemic problem.

The truth is that the overall business has a much bigger hand in any debt that’s incurred than the technical team does. Let’s work through some examples of where the debt is assigned to technology, but belongs elsewhere:

• When a shortcut is taken to get a feature out the door, is it because the technology team, in isolation, wants to get it out ASAP? It’s usually the product, marketing, sales, or other commercially-minded parts of the organisation that want the feature to go out the door quickly. In this case, the debt belongs to the organisation, because it wants to shorten the timeframe for making money.

• When developers leave problems in the code, because they don’t know how to prevent them, or simplify things, is it the responsibility of the technical team? Yes, and no. Those people are technical. But the system which sets salaries, creates incentives, builds environments in which people work, provides space, provides demand, etc. are not technical in origin. Sure, you might have hired inexperienced developers, but the choices that lead to that hire belong to the organisation, not technology. In this case, the debt belongs to the organisation because the environment that enables a developer to cut corners is created by the assumptions of the entire organisation.

• When delivery pressure mounts to a point where corners are cut just to get something out the door that has a deadline associated with it, is it the responsibility of the technical team? Clearly not, but they’ll end up wearing the problems that are identified. In this case, the shortcuts are a result of business decisions to focus on feature delivery over quality. The technology team is responding to the prioritisation, not setting it.

When we use the term technical debt, lots of non-technical people hear, ‘This is a technical problem, with technical solutions.’ This thinking couldn’t be further from the truth. If the organisation is responsible for the creation of the debt (as established above), it’s also responsible for the elimination of it. Debt belongs to the entire organisation.

Rather than thinking of it as technical debt, consider it an organisational mortgage—a loan the business takes out against future capabilities to deliver, which has to be paid back with interest. In this way, it’s no different than any other loan, or any other debt the organisation incurs.

A bank loan, or a loan from an investor, comes with repayment terms attached to it. It has conditions that have to be met, and which are backed by the force of contract law. Unlike a traditional loan, investment, or other debt, the creditors for your organisational mortgage aren’t obvious. Interest on this debt can accrue for quite some time before it can no longer be ignored. People can continue to develop against borrowed time for a long time, because the ability to deliver quality, quickly, erodes so slowly that it’s easy to overlook. People leave the company, new people join, and the slow decline of the technical capabilities of the company get missed, because the people who understand ‘how it used to be’ have moved on to places that repay their debts.

For many companies, this lack of awareness can be fatal. Technical debt can cause companies to collapse. The overwhelming weight of historical interest can make it impossible to keep people, hire people, or ever repay the loan. This is one of the key ways that organisations end up disrupted — new players, who repay their debt, and don’t have generations of existing debt, move faster, adapt more quickly, generate more revenue, and have less interest to repay.

Fintechs aren’t successful because they have new interfaces, or new ways of letting people store or invest their money. They’re successful because existing banks are built on massive, old, debt-ridden systems which they don’t know how to change, adapt, or remove. Their debt has slowed them down to a point where they can’t respond to customer needs in a timely manner, which leaves a gap for newcomers to exploit. They spend so much time paying interest on their loan that they don’t have any time, money, or energy to do something blindingly obvious — build a new product from scratch. Fintechs don’t have any insights that aren’t available to traditional banks. What they have is zero interest payments, which gives them the ability to create value.

If we take a step back from the technology teams, and look at the entire business, it becomes clear that taking shortcuts is a technical response to an organisational demand. In this light, any description that lays responsibility for debt anywhere but at the feet of the organisational leadership is inherently flawed. As the group responsible for the environment, incentives, structures, pay, commercials, etc, they’re ultimately responsible for any debt that’s incurred as a result of the choices they make.

Taking out an organisational mortgage should be a deliberate choice. It has costs, interest, pros, and cons. While we may choose to take a shortcut in order to get something out the door faster, we should be careful not to mortgage the future to pay for the present. Because organisational mortgages, like any mortgage, if unpaid, will cost you your house.