People say "technical debt" like it's a bad thing. But those who are serious about software development know that this game is all about managing technical debt. Technical debt is a natural part of the landscape in any software development team’s world. It's neither good, nor bad. Yet when trade-offs are mismanaged, technical debt is likely to cause your productivity to grind to a halt. For people who hit that point and wonder why - there should be no mystery about what causes technical debt, the answer is right in front of you. 

What is technical debt?

We can thank an early agile-manifesto-ist Ward Cunningham for the term 'technical debt' which is a fantastic metaphor for this dynamic. Technical debt, code debt, or design debt functions the same as financial debt: a team can take a shortcut to deliver something quickly, but the short-term advantage of that short-cut can make future work harder. The team gets a convenience in the short run, but has to pay it down with some interest later.

Not all technical debt is equal

Every team at every company regularly makes trade-offs about incurring debt to get something done, then hopefully cleaning it up and refining it afterward. You get a quick win, then you do the work to strengthen or refine your short-cuts. Where this gets dangerous is when it's not a conscious or intentional choice - a team can stumble into a situation where previous decisions they've made have a disproportionately high impact on the work they're doing today. They've built to their best understanding, done their best efforts, but somehow they are still bogged-down. If you find that your team seems stuck in firefighting-mode, unable to deliver new features, facing quality challenges, you may have unintentionally ended up with technical debt.

Where does technical debt come from? (spoiler alert: it's your team)

If you're deep in it, you may be wondering how did we get here? There's a lot of writing online about the causes of technical debt. I'm sure you've read them already. But when you boil it all down, unintentional tech debt comes from two sources: your engineers and your product managers.

Your engineers contribute to technical debt

If your engineers lack the experience and skills to manage complexity, to refactor effectively, to advocate for refactoring/automation/re-architecting, they will build more than you need and have a hard time maintaining it. They may not have the discipline to regularly review, refactor, test, and remove the junk.

• No standards
• Not reviewing code
• No test automation
• No regular refactoring
• No regular re-architecting
• No evaluating new tech or libraries
• Not helping product managers understand what's needed
• Not advocating for process

Your product managers contribute to technical debt

If your PMs aren't effective with stakeholder management, if they engage in deadline-driven prioritization, if they have poor collaboration with technical roles, lack of clarity in what customers need, lack of clarity in what the business needs. These all conspire to let your teams write code that doesn't serve the business.

• Saying yes to your CEO's hairbrained idea
• Setting a string of date-driven milestones
• Being unclear on what your customers really need
• Not working to solve a measurable problem/solution
• Saying no when your engineers advocate for time to refactor/rearchitect
• Saying yes to big bang change

But wait, there's more: technical debt == design debt

Designers face challenges of managing complex technical assets (Figma), contributing to product development, and driving learning efforts to get closer to users. In our experience helping companies develop and deliver software products, we've seen how this kind of trade-off can create a similar compounding-interest with the design effort for a product. People love to start building as quickly as possible and inevitably build something based on assumptions. Maybe they get lucky and their assumptions are good enough to work with - more likely they will miss the mark with their customers. When they get around to learning what their customers really need, they will begin to understand the real effort that's needed.

The impact of technical debt

Each of these things in isolation might not have a big impact on your planning or your business. But in aggregate they'll start to show up. Have you seen something like this: defects piling up, poor application performance, poor UX, reduced customer satisfaction, your teams spending time on manual tasks rather than automating their work (driving up operating costs), simple work carrying too much risk (which nobody wants to take), customers preferring to talk to someone on the phone rather than use your website. The obvious end result is massive waste from friction in delivery and lack of capacity while everyone is fighting fires.

A less obvious casualty is your understanding of the cost of development. My personal peeve about the software development world is that very few teams have clarity on the value of what they're working on. The value of our work needs to incorporate the costs of development. When the costs of development are obfuscated by technical debt, it's very hard for a team to establish clear priorities and make effective tradeoffs.

Solving technical debt challenges

There is no one-size-fits-all solution - everyone's situation is different. We often hear teams lament that they are too busy to get help, so solving this isn't going to be straightforward. Without getting too deep into the weeds, you can see that the only way out is by changing practices that your product and engineering roles lead. A healthy approach to managing these trade-offs include regular reviews and refactoring, prioritizing this work that incorporates learning, maintaining high visibility into debt-generating trade-offs, and relying on partnership between engineering and product management in building your roadmap. Want more specifics to help tame and manage technical debt more effectively? Re-read the bulleted lists above and change all the "nos" to "yesses", and vice versa.

How are you managing these two common causes of technical debt in your org?