Technical debt often arises when decisions are made for short-term gains with the expectation to course-correct at a later time. Unfortunately, later time becomes a moving target for many companies. This results in a snowball effect impacting the company’s ability to innovate or operate efficiently. Though this article focuses on product teams, tech debt isn’t limited to that. All teams can incur some form of debt such as inefficient processes, tools, organizational structure etc.
Not all tech debt is bad, in fact some are often necessary during the early-stages of a company. The key is to prevent such debts from going unaddressed for extended periods of time.
Some of the many reasons why technical debt occurs include:
- Tight Deadlines/Schedules: Schedules and deadlines are necessary otherwise many things won’t get done. Unfortunately, tight deadlines often lead to teams taking short-cuts in order to adhere to schedule.
- Varying Development frameworks: Software development is constantly evolving. Every few years, there are newer frameworks, each with its own pros and cons. Sometimes, a framework that is chosen might be unable to scale with the product leading to further debt.
- Turnover: High turnover in development teams results in the codebase devoid of consistent ownership and timely updates.
All teams, not just the engineers should be concerned about tech debt. Product managers should be vocal advocates for reducing technical debt, setting proper priorities, and getting buy-in.
The essential things product teams need to focus on are:
- Assess which technical debt needs to be addressed
- Get buy-in from stakeholders
Assess which technical debt needs to be addressed
I believe that tech debt should be continuously attacked as part of development efforts; however, it is unrealistic to address every one. If that’s all teams worked on, I suspect they will get demotivated and quit.
As a product manager, I have experienced challenges with squeezing in tech debt resolutions alongside planned feature releases. To make the case for which debt to pay back, I review the roadmap with engineering teams and ask:
1) Which upcoming features/key releases are we unable to adequately deliver on because of technical debt?
2) What experiences or opportunities could we unlock if we didn’t have existing debt?
Which upcoming features/key releases are we unable to adequately deliver on because of technical debt?
Asking this question with your engineering teams reveals where tech debt and feature delivery overlap. If there are issues with delivery, the outcome will be to reassess the roadmap as some reshuffling might be needed. Also, teams will need to properly account for additional time to tackle the debt en route to feature release.
If the answer to the question is NONE, then nothing to see here – ok to accept any existing debt as is and move on!
What experiences or opportunities could we unlock if we didn’t have existing debt?
This question is for future roadmap planning. There may have been experiences or features that were given up on because the burdens of the debt incurred are just too great. The important thing here is to understand the value of unlocking such experiences and whether the price to pay for addressing the debt is worth it.
Get buy-in from Stakeholders
Once you figure out which technical debt is hindering delivery efforts, you’ll need to make the business case and set expectations appropriately. It’s possible that more time may be needed or a feature needs to be bumped to the next cycle – whatever it is, make sure to thoroughly communicate with your stakeholders and prevent any surprises.
Technical Debt should be addressed on an ongoing basis
Organizations need to be proactive about maintenance just as they are about innovation. Paying down debt that was incurred intentionally or unintentionally unlocks long-term productivity gains for product teams. Teams that aren’t saddled with technical debt ship faster and are able to compete in the ever-changing landscape.
Liked the post and think someone else will? Please share 😃
