Technical Debt as a Strategic Tool
I'm amazed how people think about the concept of debt differently in different scenarios, and how they decide to act on it differently.
Most of us use credit cards as a way to manage our finances better, collect some sort of points they can cash out, build a healthy credit score, and buy things they couldn't if they only used their cash inflow.
But technical debt is seen differently. Tech teams see technical debt as something bad that slows them down, and they want to get rid of it as soon as possible.
Your team could spend 3 months refactoring the auth service, or ship the new billing feature that unblocks enterprise deals. Which is the right call?
When Technical Debt Enables You to Grow
It's easy to find examples of technical debt empowering teams to move faster and ship product value. And it's not always the case that technical debt needs to get repayed immediately. AirBnB managed to scale their platform to a multi-billion dollar company with a monolith codebase that had a lot of technical debt. They made the decision to prioritise shipping product value over refactoring their codebase, and it paid off.
Why not seeing technical debt as a financial medium to grow your software into what you want it to be?
I learned to think about technical debt in terms of risks and opportunities from Jack Danger's Book "executive engineering". It proposes a framework to think about debt in terms of the costs of paying interests over time, factors that make the interest rate change, and deadlines to pay the debt off.
I find it useful to categorise technical debt into different buckets and prioritise accordingly. One way to categorise debt is in terms of interest and how it gets more complex over time or as your system grows. Another way to categorise debt is around the impact that it has in moving fast in different areas of your business, which is also a way of seeing interests you're paying.
Last quarter, my team chose to invest that 10% in improving our design and developer experience. We had some technical debt in our codebase, but it wasn't really slowing us down. Instead, we chose to invest in improving our developer experience by building better documentation, improving our onboarding process, and creating better tools for our developers. This investment paid off in the long run, as it allowed us to move faster and ship more value to our customers.
A Decision Matrix: When to Take On Debt
Prioritising technical debt can be challenging, especially when everything seems critical. One way to approach this is by using a decision matrix that considers the impact of the debt on your business and the cost of paying it off. This is an exercise that you should do alongside your product manager and engineering leadership, to align on priorities.
| Positive Impact (on Business, DX) | Negative Impact | Cost to Pay Off | Priority |
|---|---|---|---|
| High | Low | Low | Low |
| High | Low | High | Low |
| High | High | Low | Medium |
| High | High | High | Low |
| Low | Low | Low | Low |
| Low | Low | High | Low |
| Low | High | Low | High |
| Low | High | High | Medium |
Focus your resources in opportunities to move fast. If some technical debt is slowing you down in a critical area of your business or your developer experience, it's worth investing in paying it off. If the debt is not impacting your ability to move fast, it might be better to focus on other areas that can have a higher impact. Also consider the cost of paying off the debt. If the cost is low, it might be worth investing in paying it off and reaping the benefits. These are usually good opportunities for new joiners or junior/mid-level engineers looking for opportunities to drive.
Code Complexity and AI
A lot of teams think of code complexity as technical debt, without identifying interests that you're paying—probably difficulty to change code. If some code is ugly, but you're not thinking of changing that, is it really worth spending any time optimise it just for the sake of optimization? there might be better opportunities to use those resources.
AI code assistants can now explain that 500-line method in seconds. The cost of understanding legacy code has dropped 10x, which changes the debt calculation. It's more valuable to document in code any special considerations to have in the future, write some tests, and make sure that ugly spaghetti code serves what you want and just let it be.
Final thoughts
I'm comfortable using credit cards responsibly. They allow me to access to expensive things and finance that cost in time. Mortgages allow you to get a home, and repay in time. Yes, you pay some interests, but having the option to use that credit is certainly a strategic advantage.
Think of technical debt the same way. Don't get yourself in a situation you can't control, but leverage what some debt will allow you to do with your system. Always be mindful about your debt state and use it in your favour!