Tech debt can be considered one of the most significant cognitive gaps between eng roles and others within software companies, and it often becomes a major obstacle in project communication and execution.
One major reason for the difficulty in reaching consensus among different roles is its abstract nature. Therefore, we need clear metrics to attach more concrete meanings to statements like “taking too long,” “difficult to implement,” “unstable,” and so on.
For example, “In the product introduction, stating that data analysis functionality can be completed within 2 hours, but 30% of customers receive reports after more than 4 hours. Additionally, this quarter has seen 10 complaints from key customers, each requiring a senior engineer to spend two days to resolve.”
This kind of communication approach can effectively and concretely reflect the severity of the problems.
Unfortunately, this scenario is overly ideal, and obtaining such clear metrics undoubtedly requires both foresight and a solid infrastructure.
For most teams, their daily work is more akin to dealing with a proliferation of bugs everywhere, leaving little mental capacity to consider what metrics they need and how to calculate them.
As a first step, which is both low-cost and easy to try, is to spend a few extra hours studying the third-party tools or services at hand to see if they have any useful features.
For example, adding a specific tag to Jira tickets caused by a technical debt-related complaint. By doing this, you can easily query and determine how many issues were caused, then calculate the time spent on opening and closing tickets to estimate the amount of engineering effort it consumed.
This is obviously not a simple matter that can be solved with just a few words. If it were that easy, there wouldn’t be so many software engineers feeling frustrated by technical debt.
However, besides hoping to land in a team that values software quality, using a mindset of technical management to escalate the problem is also an approach worth trying.