One of the perrenial topics at any software org I’ve been in, big, medium, and small, is “tech debt”. How much we have, how much we’re generating, why it’s the root of all evil, how it’s a bullshit engineer excuse. It’s a very popular metaphor, if often poorly considered.
So, let’s look closer at the metaphor, itself. The idea is that there is some level of quality, elegance or completeness that software should be at. However, it is in use at a lower level of quality, elegance or completeness. The work (usually measured in man hours, abstract points or development cycles) to move from the current, to the desired level, is the “tech debt”. You can pay it down, or keep racking it up. You can estimate how much you have. It will naturally grow over time, unless payments are made, akin to compound interest. Oddly, it’s also a kind of “friction”, which “slows” development, causes bugs and makes work less enjoyable. But, let’s set that aside for a moment, and talk about the implications of the debt metaphor.
One implication is that PMs, as the owner of the product with the debt, need to understand how to be comfortable with their debt, and how to manage it properly.
In the late capitalist economy it is not desirable to have no debt. Governments have major debts and will never pay them down (only forward). Citizens are heavily incentivized to get mortgages. Students need loans to make more money in the future. Eight in ten Americans are in debt, and despite what moralists say, that’s not a sign of personal flaws, but a natural result of a system where debt is advantageous. I would argue this all applies to software and technology as well. Being debt free means you passed up an opportunity.
Why? Because debt is moving growth forward in time in exchange for risk. If you can afford zero risk, then yeah, never have tech debt. Building nuclear submarine hardware drivers? Please have no tech debt. But most of us can afford some, managed, risk, and we can often exchange it for growth.
This applies to software very directly. Ship with a few features incomplete? You add risk of bugs, or that a missing feature would have been key to market acceptance. Running on an old, poorly maintained server backend? Risk of mass failure, data breaches, or dev ops revolts. But the flip side of cutting scope short is shipping to meet a sales opportunity. The good side of the old backend stack is that it works, costs nothing to maintain and is a well known quantity.
This is how to “manage” your debt load. Just as you try to fairly consider stakeholders input to come to the best solution, you can, for your team’s goals, step back and look at the benefits and costs of your debt. How bad are your risks? How great is the potential growth moved forward?
So if debt is useful, as long as it’s managed and risk is okay, why do teams, especially technical and design teams often view debt as only a great negative?
I would posit that it’s because of what engineers, and others, mean by debt. They deal with it every day, while for the PM and management it is more abstract, with benefits. But there is a pain to this very productive jargon, that they deal with in their lives. The reality is, they don’t like or understand their own previous, or their predecessors, work. Or they weren’t given time to do something the way they wanted, or as completely as they want. Or they need to refactor based on added features, or functions, or new models, or new best practices. They want something that was done changed, or they want to change something that was left undone. Sometimes they are right. If business imperatives, or you, are overloading them, debt will accrue. Risk will mount. And it will slow things down, and suck for them, and eventually your users. But how much debt to carry, and how risky it is, is for you to manage.