Tech Debt and Company Growth
There are engineering concepts that are difficult to quantify. If you’re a fan of the 4 key Accelerate Metrics like I am (they are the foundations of our Service Delivery Assessment), one example is Time to Recover. Being able to measure time to recover is difficult because when does an incident actually start? When there is customer impact? When the problem was created? When it’s detected by automated monitoring? What if the monitoring only says there is a problem but not where the problem lies? Similarly, it’s difficult to know when an incident ended. When service is restored? When fixes are in place to prevent it from happening again? The list goes on and on.
Technical debt is another term that is difficult to quantify. Most engineering leaders will agree that having too much technical debt is bad, but how much is “too much technical debt”? Technical debt can’t be measured in minutes like we Time to Recover, so what can we do?
Why technical debt is like real debt
How much technical debt is too much? It’s a similar question to the ones we ask about financial debt. They have many similarities. I advise clients that tech debt is not in and of itself bad, but just like taking on any kind of debt, it needs to be a conscious choice. We have to knowingly take on debt and be aware of that choice. It’s the tech debt that happens “under the radar”, without recognition, that will ultimately overwhelm companies and prevent them from growing effectively.
By looking at which debt we are willing to tolerate versus which debt is causing major problems, it’s possible to reasonably prioritize what to tackle. Just like with financial debt, technical debt can operate at different “interest rates” within the same system. Some debt will be a hassle (low interest rate), while some debt will be crippling (high interest rate). No one will ever eliminate all tech debt, just as it’s unlikely (often unwise) to eliminate all financial debt. If I have a 30 year mortgage on my house and am able to make the payments comfortably every month, I should probably not go out of my way to use all my available money to paying down the mortgage. When debt is at a place that you feel that it is manageable (e.g. we can pay our mortgage this month and for the next X months without worry), then we can have the breathing room to really execute on the plans the company wants to deliver. This is often the reason that companies find themselves undergoing a major initiative to “pay down the tech debt”, it is so that they can execute more quickly on their initiatives.
This one of the reasons I dismiss most of the “it’s a bad analogy” think pieces out of hand. It’s actually a very good analogy!
What if our debt gets out of hand?
Just like with financial debt, if our debt ratio gets too high, we are going to have trouble executing on the things we want to get done. As with all things Devops, this is not just an engineering problem. As the debt grows (with interest) the business side of the house is going to get less and less of what they want accomplished, so it is bad for them as well. Projects will be delayed, the business will continually ask why it takes so long for engineering to deliver, and we will be unable to grow the business because we are simply carrying too much technical debt.
The classic example of this phenomenon can be found in the the stories I used to hear as an architect at Salesforce, talking about the big meltdown in the mid 2000s.
“But by 2006, we had experienced phenomenal growth—we had more customers, more revenue, more product, and a bigger company. And like with any growth spurt, it wasn’t pain-free.
All the things that used to happen with ease weren’t so easy anymore. As a result, we began to experience a slowdown in innovation.” Understand Why Salesforce Adopted Agile
The faster Salesforce grew, the longer the days grew between major releases and the less features were delivered per team. As with many companies, where the organizational debt often manifests itself as technical debt, Salesforce couldn’t get a release out the door. There were too many moving pieces that ground together to bring the system to a halt. Salesforce had to fundamentally change the way they delivered software to make sure that their debt would not continue to compound as they tried to do more and more as a company.
What can I do?
As with financial debt, software delivery needs to be addressed with intention. It is not enough to spin up sometwo pizza teams and hope for the best. It’s not enough to run up all our credit cards and hope for the best.
Companies need to have plans for their debt and recognize that at some point, they are going to have to pay it down and keep it manageable. Just as with financial debt, technical debt is best paid down continually and in small increments. I knew a development team that would take one Wednesday out of each sprint for months, dedicated solely to paying down technical debt.
By carrying a low (technical) debt load, we can allow our companies to execute on their initiatives continually. Instead of riding crest and trough cycles of paying down debt that hold the business back from growth at the top of each cycle, we can ride a smooth path into growth, innovation, and success.