Let’s face it, technical debt is something that every Product Manager has to deal with on a constant basis — whether it’s making snap decisions that unblock your team so that they can keep working, short-cutting an ideal architectural solution because you have time-to-market pressures, or deciding to put off working on bugs found after a story’s been closed. While the common wisdom may be that you should never take on technical debt, the real world intrudes on such a fantasy each and every day, and if we don’t want to wind up in a death march that never sees the light of day, sometimes we have to make the choice to sacrifice some long-term stability in exchange for short-term gains. But how do you determine when there’s too much technical debt, or when the specific item of debt is too much to bear? That’s what we’re going to discuss today…
Technical Debt is a Fact of Life
Repeat after me: “Technical debt is a fact of life.” Say it again. Now take a deep, cleansing breath. Perfect, we’ve just accepted reality. It doesn’t matter whether you’re building product using waterfall or agile methods, it’s inevitable that you’re going to wind up running into some technical detail that was unforeseen (and perhaps even unforeseeable), which positions you in the awkward place of deciding whether to invest the time, effort, and resources to fully resolve it right now…or to take on some amount of technical debt that you may (or may not) have to come back to later. These can be very small things — UX that isn’t quite perfect, a UI that could use some clean-up, an API interface that returns most of what you and your users need, etc. These can also be very large things — limits to the underlying architecture of the project, dependencies on outside libraries that are no longer supported, or some fundamentally broken user experience that ends in unhappy paths more often than happy ones. Small, medium, large — you’re going to run into all of these at some point in your project, and it’s what we decide to do with them that matters. You can’t bury your head in the sand and pretend that technical debt doesn’t exist — it does, and we simply have to deal with it.
Is It Technical Debt or Is It Scope Creep?
I won’t name names here (*cough* developers *cough* architects *cough*) but one thing that every Product Manager needs to critically assess when faced with a question of taking on technical debt is whether the issue really is one of technical debt, or whether it’s some form of scope creep. I’ve run into many situations in my career where an “issue” with the solution being built was uncovered which was well outside the scope of work that we were all engaged in. This could be a refactoring need of some underlying component that you’re relying on for your work, or it could be an aspirational UX design that stretches the work outside of the common approach in your company, or it could be some architectural improvement in the infrastructure that would be really awesome for the future, but isn’t really “needed” right now. Each of these types of situations fall well outside the definition of technical debt, though in many situations these can be presented as such. It’s really important as Product Managers that we think critically about the positioning of such requests or reports, and insist on a tight definition of technical debt that is related to the work that’s in-scope for the project that you’re currently working on. It may disappoint some people that they’re not able to wedge in the improvements they’d like, but we have market delivery needs that sometimes trump these improvement opportunities.
Balancing “Now” and “Later”
Ultimately, the question of whether to take on technical debt is a question of incurring costs to fix something now, or taking the risk that it will cost more to fix in the future. It’s important in these considerations to understand that it’s always cheaper from a time and resource perspective to resolve some item of technical debt now; when you come back to it later, you’ll have lost context, momentum, or even expertise (especially if you lose people in the meantime). This doesn’t, of course, mean that we must always take on this debt immediately, but it should be our bias to do so. We can overcome that bias if there’s good reason to do so — but we really have to think carefully about the tradeoffs that we’re making between now and later, and we have to make sure that we’re setting the “future us” up for success. We need to clearly document technical debt that we’re taking on, why we’re making the choice to do so, and plot out some user stories on the backlog to catch up to ourselves in the future. It’s also critical to know that the longer technical debt sits, the greater the risk that something is going to go wrong and turn us away from being thoughtful, proactive Product Managers and fall into our role as firefighters. And we do not want that. So whenever possible, we need to position technical debt work to be done as soon as possible after the situation which forced us to take it on is resolved. This can be a tough discussion, but it’s a necessary one; we need to fight for the right choice, not necessarily the easy one. That’s why we’re Product Managers after all!
