Managing technical debt

When you build a budget—allocating time, resources, and funds for a project or timeline—you might (rightly) expect that the agreed-upon numbers at the end of that planning session are your budget. They are the money, the time, and the allocated resources you get so that you can complete a project, launch a feature, and meet a goal.

But, as you may know, if you’ve been around awhile, that often isn’t quite true.

Those hard-won resources, funds, and people-power hours tend to get siphoned off along the way. In fact, research by McKinsey found an average of 10 to 20% of new product budgets are redirected to technical debt.

A hefty price to pay for past shortcuts—and a compelling reason that we need to talk about technical debt. Now.

What is technical debt?

Technical debt (also known as tech debt or code debt) is a metaphor for what happens when teams fast-track a technical project with the intention of fixing issues or improving quality later. 

For example, if your product team wants to launch a new product quickly and asks you to develop the MVP (minimum viable product) and launch without key features—which you will tackle later—those key features become your technical debt. The part of your product that isn’t quite paid off.

Less strategically, if your tech team rushes through a dev project to hit a tight deadline, but takes some shortcuts and skips some QA, the resulting buggy code and customer complaint pile-up become your tech debt.

In other words, any unfinished project business post-launch is now technical debt your team has incurred.

The 2 types of technical debt

First identified by Steve McConnell, there are two key types of code debt: intentional and unintentional.

Intentional debt happens when a business makes the strategic decision to prioritize speed over perfection. It’s when “getting it done” is more important than hitting the highest quality marker.

For example, a company might choose to launch Product V without Feature Z because they promised Product V to customers by the end of the year, and adding Feature Z later poses a low risk to customer satisfaction and team velocity.

Or a team might choose to take a known shortcut (knowing they will have to fix a step they skipped over) because the person who can do that step is out with the flu and they can’t afford the blocker.

The first example above (Feature Z) is what we call long-term debt. It’s debt that will have to be paid off later—perhaps after launch or in another sprint. The second example is short-term debt. When Team Member X has triumphed over their bout with the flu, they can return and fix the skipped step, bringing the quality level back into line.

Unintentional debt, on the other hand, is the dark side of the tech debt spectrum. It’s what happens when mistakes, reckless decisions, or a lack of strategy cause unplanned tech debt.

Is technical debt ever a good thing?

Much like with financial debt, not all technical debt is a bad thing.

You buy a car to get to work and pay it off over time. You get a mortgage on your house because you need a roof over your head. And you launch that product quickly because it’s more important to solve the problem now than to launch the product perfectly.

It all comes down to strategy when managing technical debt. If your primary goal is to get a product or feature to market ASAP, you may choose to incur some technical debt in order to reach that goal. If your primary goal is to deliver a fully realized product or feature, you may choose to work on a longer project timeline and forego tech debt.

There are pros and cons to each approach. A fast-track approach gets you to market quicker, which can increase profits and benefit customers. But it may also come with more customer complaints about missing features, lower quality, or bugs.

Adding those features and fixing bugs may also take more time or risk more outages when connected to a live product and often software development teams pay a “tax” in interruptions and urgent fixes until the debt is fully paid back.

Much like going into debt for a house or car, your technical debt typically comes with interest payments—a bit more time and hassle later for a pay-off now. But there’s a reason pretty much every team has tech debt these days: because customers expect extreme agility. And sometimes it’s the better strategy to launch now and pay off the bugs in installments.

The Technical Debt Quadrant

The most common way to think about and understand technical debt is using the Technical Debt Quadrant (designed by Martin Fowler). It visualizes technical debt on two axes: from deliberate to accidental and prudent to reckless.

The other type of prudent debt is the accidental kind. This typically happens when you believe your solution will result in perfect code—but learn after implementation that there was something missing.

Work in tech long enough and you’ll find that this type of technical debt is inevitable. No matter how careful and committed to perfect code your teams are, sometimes a better solution will come knocking after the fact.

Much less desirable is our third type of debt: reckless and deliberate. This happens when teams intentionally prioritize speed over quality even when that speed will harm the business, customers, or process.

Finally, we have reckless, inadvertent debt, which happens when teams don’t have the knowledge or experience they need to build the product or feature, and, eventually, they create accidental and often massive problems for themselves down the line.

The bottom line here is that understanding technical debt can help us avoid the part of the quadrant that can sink us and plan appropriately for the types of tech debt we might encounter or choose to take on.

How to avoid technical debt: 5 ways to get out and stay out

Some code debt is inevitable, yes, but the truth is a lot of us are drowning in it—and that’s alarming. The same McKinsey survey reported 60% of surveyed leaders said their technical debt has risen perceptibly in the last three years. And just 15% said they’ve noticeably paid theirs down.

This is a problem. And companies need to get smart about solving it—taking on good technical debt when it makes sense but also having concrete plans for digging out of the debt trench.

Here are five ways to stay out, get out, or otherwise smartly plan for your technical debt:

1. Destigmatize technical debt

Much like anything in life, if there’s a stigma around tech and financial debt, nobody wants to talk about it. This is why step one is to destigmatize the term and talk openly about it as a business.

Destigmatizing debt doesn’t mean embracing it recklessly. But it does mean talking honestly about it, and being transparent not only within teams but with leadership and the rest of the organization. It does mean planning for it and being realistic.

2. Track your technical debt and build it into the planning process

Do you know what your technical debt looks like? If the answer is no, how can you possibly manage it and pay it down? A report from Gartner explained when leaders actively manage and reduce their technical debt, they can cut service delivery time in half.

You read that right: 50%.

Actively managing starts with tracking and organizing your debt so that you can strategically pay it down. It also means making technical debt a part of (and a priority in) sprint planning, capacity planning, and velocity conversations.

3. Keep up your backlog

Speaking of active management, a key component of this work is keeping your backlog up to date and prioritized. Backlog management should be a core part of your planning process, a well-defined part of someone’s job, and something that happens before sprint planning.

Experts suggest that technical debt shouldn’t last more than 90 days.

You and your development teams may incur new debt during that time. You may never fully be out of debt. But don’t let individual debt fester, grow, and cause more problems. The longer you wait, the more your complexity tax tends to grow.

The key thing to understand here is that one of the reasons technical debt gets deprioritized is that it can be tedious work. So assigning firm deadlines and attaching real value to those deadlines (in the form of accolades, bonuses, etc.) is a necessary part of pushing past the tedium.

5. Look for quick wins

If you’re looking at a mountain of code technical debt that needs to be paid down, it can feel pretty overwhelming. Research tells us that it’s easier to start if you can see a finish line. It’s more manageable to tackle a project if you are already three steps in. This is why it’s helpful for development teams to find quick wins to manage technical debt.

Paying down a chunk of debt is sometimes as simple as documenting a process, retiring an irrelevant feature, or putting guardrails into place for the next project. Choose a quick way into the problem, a win that makes the mountain feel more manageable, and start there.

6. Reward the process of paying debt down

Too often, the accolades and financial rewards in a company go to those who innovate on something new, deliver the next shiniest thing, and tackle the future feature in record time.

And that’s a problem.

If we want teams to prioritize technical debt, it needs to be just as important and just as rewarded within the organization. This means leadership needs to get on board with how important it is to pay down your debt, and performance reviews and bonuses should factor in code debt wins.

Tackling your technical debt

Here’s the good news: technical debt is correlated to business success.

That’s right. Top performers handle technical debt better.

This feels like a pretty strong argument for why your organization should make it a priority.

So, where should you start? In response to the alarming upward trend in technical debt, McKinsey released a technical debt scoring system (Technical Debt Score, or TDS)—a quick, handy way to see where you fall on the top performer scale.

Once you understand where you stand, use a tool like ClickUp to set goals, track progress, and keep everyone on the same page about current tech debt and tech debt you’re planning for on future projects.

If you want to get in the driver’s seat to manage your technical debt, sign up for ClickUp today! It’s absolutely free—meaning zero, zilch, nada—to get started with managing your projects.