As we get ready for our Road to RevOps event, as our How to Future Proof Your Tech Stack discussion, I canât help but think about the phrase tech debt.
We know âdebtâ of any kind to be not-so-great, so how would you describe tech debt? And more importantly: how do you measure how much debt youâre in?
What about:
The time it takes per week to manage a duplicate system
The amount of money it costs for a human to manage a duplicate subscription
How do you define tech debt, and how do you measure it at your company?
Love this question! My working definition - Tech debt is the implied cost caused by inefficiencies affiliated with the technologies used to support a businessâs day-to-day operations.
In regard to measuring tech debt, there are three core areas I evaluate.
The direct cost affiliated with the tech used across the organization. Conduct regular tech audits to identify any overlapping applications so you can consolidate or find an alternative application able to replace two or more existing tools.
Productivity costs caused by inefficiencies within your tech that require duplicate work or long workaround tasks to resolve. You donât want your key players wasting time on basic tasks that could be automated or addressed by an integration.
Lastly, there is team morale (closely related to number two). If the inefficiencies are causing your team to want to pull their hair out on a daily basis, that can result in a number of high-cost outcomes.
Tools along with SonarQube and Coverity allow you to measure technical debt and decide your technical debt ratio (TDR), thatâs the ratio of the cost to repair the software program system vs. The value to construct it. The TDR is vital because it tells you how lengthy itâd take to convert elaborate code into first-rate code.
Wow! Iâve never heard of this TDR metric before. Have you been able to get
others in your company to adopt / use the TDR metric? Can you use it /
calculate it even if you donât use the tools you mentioned?