Product development is exhilarating. There is something special about a team rallying around a vision and creating a product that users love.
However, it isn’t fun to redo a product every three years. Unfortunately, technical debt can do that to your team. And that’s on a good day.
At its worst, technical debt can drive organizations out of business by causing serious security issues.
The cost of technical debt is exorbitant. Stripe estimates that the total global impact of technical debt might be over $3 trillion. No wonder Forbes calls technical debt the silent company killer.
What is Technical Debt?
Technical debt refers to the cost you accumulate by favoring easy and quick solutions over best practices in engineering.
These costs might not be visible at the time and surface in the form of rework required further down the line. For example, it can show up in the form of potential time lost on fixing bugs, refactoring code, or damage control for security breaches.
But technical debt isn’t always bad, and some of it is unavoidable. The key to managing it is understanding the risks and rewards of acquiring it, just like any other debt.
How to Manage Technical Debt
It’s impossible to be technical debt-free. But it is possible to manage it in a way that doesn’t jeopardize your organization’s goals.
1. Understand & Prioritize Types of Technical Debt
Just as some features are more useful than others, some forms of technical debt require more attention than the rest. Understanding their impact on the business bottom line will help you manage it better.
Engineers love the smell of clean code and would ideally love to refactor each line. On the other hand, business executives care about features and “visible improvements.” Identifying the sweet spot in between is the key to managing technical debt.
For example, code that isn’t written according to the best practices but has no negative impact on the application performance would be a lower priority than running an unsupported version of a framework, which has serious security implications. Covering them both in the garb of technical debt is a gross oversimplification.
But prioritization itself isn’t enough. The next step is even more crucial as this is where teams often struggle with crafting a concerted response to technical debt — communication.
2. Explain the Impact in Business Terms
Every product has a backlog of features that are important to meet the organization’s revenue goals. Unfortunately, technical debt eats away the limited time organizations have to work on those features. That’s why managing technical debt requires buy-in from the stakeholders.
The best way to convince business executives of the importance of technical debt resolution is to do so quantitatively.
For example, working on an application infrastructure that’s not scalable and might break with 2X the traffic is an easy sell to engineers. Still, the executives with their aggressive revenue goals might not understand its urgency. However, stating that the infrastructure might collapse in six months based on the existing user growth, leading to a $1000 revenue loss each day, helps put things in perspective.
Image inspiration: Aequillibrium
Communicating the impact of technical debt in business terms makes it visible, which helps stakeholders prioritize issues on the product roadmap.
3. Align Technology & Product Roadmaps
Our partner Aha! provides an elegant way to look at both technology and product roadmaps — they are two sides of the same coin. The product roadmap describes the “What” and “Why,” and the technology roadmap focuses on the “How.”
Engineers don’t have the sole responsibility of communicating technical debt in business terms. Product and business executives must hold their end of the bargain. They need to understand the implications of the organization’s technology roadmap on the product roadmap. Only then would teams find consensus on managing technical debt.
This alignment needs to come from the top. When the CTO and CPO find alignment in their strategic goals, it becomes easier for the team on the ground to prioritize issues in their sprints.
Product managers often have a better understanding of the UX side of the product compared to engineering. According to a report by Airfocus, only 5% of product managers know how to code, and 60% feel that technical training will help them perform better.
Aligning technical and product roadmaps helps teams understand hard requirements to achieve product goals. They gain a better understanding of dependencies in feature development. For example, if they want faster load times in the app, the technical roadmap will paint an accurate picture of the level of refactoring it entails.
4. Avoid Non Negotiable Deadlines
There is no better way to guarantee technical debt than to set non-negotiable deadlines. Various organizations publicly announce planned feature releases, which sets a hard target for developers. This inadvertently encourages developers to do whatever they can (read cut corners) to meet the target date, accumulating technical debt in the process.
Therefore, it helps to adopt the famous “underpromise, overdeliver” mantra in external communication and be a little vague about feature release dates. For example, note how Atlassian’s public roadmap mentions quarters instead of specific dates to give more cushion to their development teams. This helps maintain accountability without setting arbitrary target dates.
Of course, there would be situations when hard deadlines are unavoidable. But that shouldn’t become the norm, and the subsequent sprints should allocate more time to technical debt to make up for aggressive feature releases.
5. Factor In Refactoring
When planning for stories at the start of a sprint, understand if they require refactoring. It’s better to have a discussion during planning than after a feature is launched. This allows the team to work on refactoring in parallel with feature development and make a more accurate estimation of the completion date.
Dedicating a percentage of each sprint to managing technical debt is a much more sustainable approach than exclusive technical debt-focused sprints. Many high-performing teams dedicate 10-30% of their sprints to technical debt resolution and system maintenance.
Technical Debt: The Gateway to Application Modernization
Managing technical debt often gives teams their first taste of application modernization. It can pave the way for a more ambitious app modernization strategy such as implementing micro-frontends, enabling micro-services, decoupling front-end and back-end, and hybrid application development.
If you would like help with managing technical debt, talk to Modus. Our team has helped some of the world’s leading enterprises accelerate product development with application modernization.
