There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
When Technical Debt Isn’t Bad
Certainly there are consultants and thought leaders and purists out there who will tell you that you should never intentionally take on technical debt, and that you should always tackle any technical debt that you do find as soon as you can. And sure, you can do this. And you’re product will wind up in a constant death march where it never actually sees the light of day. The reality is that you will have to take on technical debt, especially when working with an older technology, but even with new work. There are near-infinite ways to solve almost any problem with technology and each of those will have strengths, weaknesses, and follow on work that will need to be done later. Technical debt that comes about because you’re making an affirmative choice to move forward towards the market is good technical debt. Technical debt that comes about without consideration or without a clear goal is bad technical debt.
Ask The Right Questions About Technical Debt
Which leads us directly to the next topic…how do we make sure that we’re taking on good technical debt and minimizing bad technical debt? The reality it’s that it’s easier said than done, because every decision is going to be made as part of a holistic product strategy. Sure, there are some questions that we can ask which might make us more likely to avoid bad technical debt, but even debt that seems “good” when taken on can hide in the wings and come back to bite us in the ass when we least expect it. A few good questions that one night raise when considering whether to take on any given but of technical debt include:
• Do we understand the reason why do we don’t believe we can fully solve this right now?
• Do we understand the work that we’re going to need to take on in the future because of this decision?
• Do we have others who will depend on the chosen approach, such that later revisions might break more than just the current context?
• Is the benefit we will gain from pushing forward worth the cost of future rework?
• Are we really willing to commit to coming back and fixing this later?
A Product Manager Always Pays Their Debts
Ultimately, from a Product Manager perspective technical debt comes about because we’re making a short term sacrifice for longer term gain. But the problem is that over time all of these shortcuts and utilitarian choices build up, to the point where one of two things happens: (1) the whole damn system comes crashing down, or (2) the infrastructure of your product becomes so fragile that we can’t actually keep moving forward workout breaking multiple contexts. This is where the consultants and thought leaders have it right – whenever you decide to take on technical debt, you must make sure the work to fix it lands on your backlog and never leaves it until it’s done. It might never get highly prioritized, but it will always be visible, there to poke and prod at you and the team, a reminder of choices made and promises to be kept.
