How to Measure Tech Debt (Both Types!)

Tech debt is one of the biggest obstacles facing organizations who seek to modernize their operations, but its relative invisibility is precisely what makes it so hard to tackle.

Without a thorough accounting of the technological debt that a company has accrued over the years, old and outdated systems and programs can have an outsized negative impact. Tech debt can act as an unseen albatross around the neck of even the most successful organizations, preventing engineering teams and the business from reaching their unseen potential.

But how do you measure that which is largely invisible, something whose appearance on your year-end balance sheets may cloud just how much it’s dragging down your ability to innovate and achieve your business goals?

Below, we’ll look at how to measure tech debt (both types; more on that in a moment) and explain how you can pay down this debt once and for all, through a repeatable framework that continually pushes you to cut products, services, and programs that are no longer serving your best interests.

But first…

What is Tech Debt? A Brief Explanation

One of the most important things to understand is that there are basically two very different types of tech debt, and each can impact an organization in myriad ways.

On the one side, you have a definition similar to that put forth by McKinsey, where they emphasize what happens as a business evolves and winds up with a collection of both new and legacy systems throughout their operations. Each of these has an attendant cost, and the patchwork of various tools, services, and pieces of software creates unnecessary redundancies that harm a company’s bottom line.

This is a very business operations-centric definition, one that often clashes with how engineers conceive of tech debt. In engineering parlance, tech debt is what happens when, in the haste to release a product or meet the deadline for a software update, the development team cuts corners to get the thing out the door.

So rather than an issue being solved, there it sits, festering, acting as something that programmers must work around or address in future updates, taking valuable time and resources from improving the product in other ways. This definition is what’s used in this helpful article from Atlassian.

Is it any wonder that McKinsey would lean on the business-related definition while Atlassian, an Agile- and software-focused company, would go in the software direction? Of course not. In fact, it speaks to something we’ve covered previously, wherein the miscommunication between engineering teams and business leads can create conflict within organizations.

So which version of tech debt should you be focused on measuring and paying down? Both, of course!

How to Measure Tech Debt: Business Style

Any measurement of tech debt in business operations begins with a thorough accounting of all the systems and tools used throughout the organization.

The larger the organization, the larger this list will likely be. But even relatively small companies or departments can acquire a substantial list of tech products and services over the course of doing business.

The reasons are many. You could lose and gain employees, many of whom were champions for one tool over another. You may be paying for 100 seats of a given Software-as-a-Service (SaaS) product, but over time you’ve pared that down to a dozen or so users, and no one bothered to update the information to reduce the price. You could have two departments paying for two applications that do the same thing or even paying separately for the exact same application.

By querying each of your business units to find out what tools they’re using and then gathering all this information in one readily accessible, easy-to-edit spot, you can see where overlap exists and where cost-savings may occur.

In the example of two teams using the same tool but paying separately, you can combine those accounts for an enterprise version of the solution that reduces costs. When teams are using different tools that accomplish the same goals, such as multiple versions of project management software, you can work with those teams to unite under a single product so you can eliminate those redundancies.

This process also forces your internal teams to give more consideration to the tech they rely on. They will quickly uncover systems and services they haven’t logged in to in months. You can then begin the process of eliminating those tools or moving into newer, better systems.

More difficult to deal with are legacy (i.e. old and outdated) tech solutions that your business units nevertheless continue to rely on in the current environment. There can be myriad reasons for this: security concerns, lack of expertise, no interest in learning a new system, an employee in a leadership role who doesn’t want to migrate, etc.

Regardless of the reason, coming up with a strategy to address this tech debt is somewhat more difficult. But it’s necessary to do if you’re to realize cost-savings while spurring innovation.

For instance, a company may use exclusively on-site server infrastructure for all their data needs, and costs have spiraled out of control as the amount of data (and in turn the number of servers) has increased, along with the number of employees needed to manage those servers.

This is a clear-cut example of a critical part of business operations that is nevertheless accruing a deep amount of technical debt. To solve the problem, you must recognize it as a problem and come up with a strategy for solving it, envisioning what a full or partial migration to the cloud might look like, along with all the steps you’ll take to get there.

This is one example among many. But the only way you’ll see these potential barriers to success is by accounting for all the technology you’re currently using, along with its attendant cost.

How to Measure Tech Debt: Engineering Style

Tech debt can be measured somewhat more easily in the engineering sense of the term: by the number of bugs your developers are required to fix on a regular basis.

Bugs are the numeric visualization of any corners that were cut to get a product to market. The longer it takes to correct these in subsequent updates, the more time you must take out of future development to focus instead on solving problems and rescuing the customer experience.

Now, actually affixing a lost opportunity cost to these bugs is a more complex endeavor. It’s hard to put a specific dollar amount on, for instance, tech debt’s impact when it prevents you from developing an innovative new product feature that will increase your customer base tenfold. Tech debt is prohibiting you from achieving those blue sky ideas that will allow you to innovate, but actually assessing the dollar impact of this is difficult.

What you can do instead is look at the amount of time it takes to swat down bugs and compare that with what it would take to solve the underlying problem. Bug-fixing time definitely has a cost, and when it starts to be greater than rebuilding your digital architecture the right way, you can begin to chart a path to a new product that frees, rather than shackles, your development team.

Get Out of Tech Debt

Whether you’re using the business or engineering definition, tech debt is something you don’t want to encounter within your organization. It can eat away at your ability to succeed just like fiscal debt and, if left unchecked, inhibit you from reaching your full potential as an organization.

To learn more about addressing tech debt, including solutions that will help you integrate business systems and engineering products the right way, contact Aviture.