How tech leaders can tackle technical debt: A 6-step guide
Written by: Adam Horner, CTO Coach & Fractional CTO
Introduction
Over ten years ago, after a conversation with an investment advisor to the fintech startup I was co-founder of, I began thinking of technical debt like a financial loan. This inspired the 6-step method I use today, which helps teams calculate the ‘interest’ on tech debt and frame it in a way that executive leaders understand too.
I refined this method to calculate the interest rate more simply and used it to manage a two-year migration project that started with so much tech debt that feature delivery was at a standstill. Scaling was impossible and no new customers could be added to the platform. There was no innovation and the startup was at risk of losing customers.
Technical debt is more than just an engineering concern, it’s a business risk. For CTOs and tech leaders, understanding, measuring, and managing technical debt is critical to maintaining productivity, driving innovation, and keeping your company agile.
But let’s be clear: technical debt is not inherently bad. In fact, accumulating some debt is often a necessary part of scaling quickly and delivering features on time.
Much like using a credit card is a sensible way to manage monthly finances, so is technical debt a normal aspect of building software. The real challenge is knowing how and when to manage it effectively, so it doesn’t spiral out of control and hinder growth.
In this article we will cover the business case for managing technical debt, finding the balance, and a 6-step process to easily measure and monitor it.
First let’s explore why it matters at the business level.
The business impact of managing technical debt
At its core, technical debt is the accumulation of shortcuts taken during development. This could be inefficient code, neglected refactoring, or quick fixes meant to solve immediate problems.
While these shortcuts help in the short term and are often appropriate to use, especially before product-market fit, they can lead to larger problems over time if not addressed.
At the startup with the two-year migration project, the leadership really understood that technical debt was a business problem. The accumulation of short-term technology choices slowed new feature delivery to a standstill and prevented the company from delivering customer value.
In many cases though, CTOs must make a strong business case for resolving technical debt before it reaches this level.
Here’s why managing technical debt at the right time should be a priority for CTOs:
1. It slows down innovation
Technical debt clogs the development pipeline. As debt grows, it becomes harder for teams to add new features, improve existing ones, or even maintain the current system. This leads to slower release cycles, missed opportunities, and frustration among both developers and other stakeholders.
2. It increases operational costs
Technical debt increases ongoing maintenance. Teams spend valuable time fixing bugs, modifying code, and working around long-standing issues. The more debt accumulated, the more time and resources are needed to maintain the system. This takes time away from new projects and innovations, driving up costs and stifling growth.
3. It impacts company agility
In today’s competitive market, agility is often very important. Companies that can’t pivot quickly to meet changing customer needs or industry trends risk losing ground to more nimble competitors. High levels of technical debt create a drag effect, making it harder to respond to new opportunities or threats.
4. It frustrates engineering teams
Unmanaged technical debt demoralizes engineers. Constantly working around technical debt to fix bugs or stabilize systems can lead to engineers leaving or burning out. When engineers feel like they’re spending more time maintaining or working around old code than building something valuable, morale drops, and productivity follows.
When this frustration reaches a tipping point, it often also creates friction between engineers and leadership. Engineers may feel that they are spending too much time fighting fires, while leadership wants faster releases.
Managing technical debt effectively ensures that the team stays aligned, motivated, and focused on what really matters: building new capability and driving the business forward.
Technical debt isn’t just an engineering issue, it’s a strategic business concern. If it isn’t actively managed, it threatens the company’s ability to grow and innovate.
Finding the right balance: managing technical debt and innovation risks
It’s important to recognize that some technical debt is healthy. Like any business decision, it’s about managing risk. Taking on technical debt can enable faster releases, help you meet tight deadlines, and provide the flexibility to experiment.
But there’s a limit. If the cost of technical debt grows too high, it starts to outweigh the benefits. The key is making debt a conscious decision—knowing how much you’re carrying and when it’s time to pay it down. Just like financial debt, there are different kinds of debt with varying sizes, interest rates, and payoff periods.
At one organization that I worked with, the CEO had mandated no bug-fixes or refactors on one older platform. After a while individual engineers talked to me about their frustrations with the state of the codebase because of the ‘no fixes’ situation. They couldn’t make pragmatic quality-of-life changes to the development environment or prevent issues that cost them and the support team a lot of effort.
The metrics also showed that feature delivery had slowed to a snail’s pace, much slower than expected. The balance was clearly not right. The next step was to understand how big the problem had become.
So, how do you measure technical debt effectively? How should you decide when to address it? That’s where this 6-step method comes in.
The 6-step proven method to measure and manage technical debt
Managing technical debt isn’t just about cleaning up old code—it’s about measuring and understanding the cost of carrying that debt over time. Here’s how to do it:
1. Pick a time frame to assess technical debt
Start by defining a regular time frame for measuring technical debt. This could be tied to your sprint cycle, a weekly review, or a monthly check-in. Consistency is key—it allows you to track changes over time and see how your debt is impacting team productivity.
2. Count total engineer hours in the team
Next, calculate the total number of hours your engineering team worked during the chosen period. This will give you the baseline number needed to understand how much time is being spent on building new features versus managing technical debt.
3. Estimate the time spent on technical debt tasks
Ask each engineer to estimate how much time they spent on technical debt during that period. This includes tasks like bug fixes, refactoring, addressing legacy systems, and other maintenance-related activities. Make sure they count all debt-related tasks—not just the obvious ones like fixing bugs.
4. Peer review to validate the technical debt estimates
To ensure accuracy and consistency, have engineers review each other’s estimates. This peer review process can help uncover hidden technical debt and help clarify your working definition of what constitutes technical debt.
Engineers might not always realize how much time they’re spending on it, or have different ideas of what is or is not considered technical debt. Collaborating on this ensures that everyone has a realistic understanding of the debt burden.
5. Calculate the ‘interest’ cost of technical debt
Once you have the data, calculate the "interest" on your technical debt by dividing the total tech debt hours by the total engineer hours worked during the period. This percentage represents how much of your team’s capacity is being consumed by technical debt rather than anything else.
For example, if your team worked 1,000 hours during the month and 200 of those hours were spent on technical debt, your technical debt interest rate is 20%. This figure gives you a clear benchmark for making decisions about whether to reduce debt or maintain the current level.
6. Benchmark and manage technical debt effectively
Use this interest calculation as a benchmark for managing technical debt.
If the percentage is too high, it’s time to prioritize short-term projects to pay down some of that debt.
If it’s low, it could indicate that your team is spending too much time perfecting the code, at the expense of innovation.
From my experience, 15% is a reasonable target to use if you have no better data or historical experience to guide you.
If you are below your target then your team is storing up trouble, potentially risking your future stability.
Above your target, and you’re likely spending too much time on maintenance, slowing down your overall progress.
Take control of your technical debt with proactive management
Managing technical debt is one of the most important responsibilities for any tech leader. It’s about keeping the codebase clean and making sure your team remains agile. Ensure your company stays innovative, and your engineers stay motivated.
By measuring technical debt consistently with this 6-step method, you can make more informed decisions about how to balance innovation with stability. And most importantly, you’ll ensure that technical debt never reaches a point where it holds your team back from innovation.
Is technical debt holding your team back from innovation and growth?
Start measuring it now and take control before it controls you.
For help creating or validating your engineering strategy, including how to assess and tackle your technical debt, read more about Synova’s strategy workshops.
For more personalized advice on how to manage your team’s technical debt, get in touch to talk about a consultation.
Learn more about:
How personalised, pragmatic CTO coaching can help transform you into a confident, strategic leader.
How a fractional CTO can help your business.
How strategy workshops can help drive strategic alignment to grow your startup or scale-up.
Don’t miss the latest episode of The CTO Playbook — the podcast dedicated to helping CTOs excel.