This post was written by Cliff Gilley, Product Management Specialist and founder of The Clever PM.
There’s a common belief among product managers and technical delivery teams that “technical debt” is something to be avoided—and when it cannot be avoided, that it’s some sort of “dirty secret” that should be hidden. But nothing could be further from the truth. In reality, technical debt is a fact of life when teams are working iteratively to deliver high-quality, innovative solutions.
There will always be a time when the work outstrips the available technology and expertise, or simply provides too many options from which to choose. When it makes sense, we need our teams to take on technical debt so that they continue moving forward and don’t succumb to analysis paralysis, adding unnecessary delays to our constantly moving target.
You Can’t Accommodate Debt You Don’t Know About
Most importantly, product managers need to dispel the feeling that technical debt is something to be hidden, a secret held amongst those “in the know.” The root cause of this behavior is a fear that others in the organization will see a decision to take on technical debt as a failure or a lack of understanding or expertise.
It’s up to us as product managers to educate not only our technical teams, but our stakeholders as well—so that we can openly discuss the technical debt we’re taking on and position the work to correct or refactor these decisions in a way that makes sense to everyone. If we don’t know about technical debt, we simply can’t do anything about it—and it will inevitably pop out of the shadows to bite us when we least expect it (and when we can least accommodate it).
Know When You’re Taking It On, and Plan Accordingly
Once we convince both our stakeholders and technical teams that technical debt isn’t something that needs to be hidden, but rather embraced and discussed just like any other requirement, we need to ensure that we’re handling it appropriately. And that means we need to weave refactoring, reworking, and rearchitecting into our roadmap, preferably as close in time to taking on the debt as possible.
Just like any other debt, we accrue “interest” on our technical debt—in time rather than money. The further we get from the point we take on technical debt, the more code is added, the more complex the system becomes, and the harder it will be to effectively excise that debt so that it can be paid off. This is where the education of your stakeholders becomes essential. If everyone understands the nature of technical debt, the risk of not making payments against it, and the danger that it poses if left untouched, it becomes easier for us to include such work in our roadmaps and tactical plans.
Managing Technical Debt Is Part of Product Management
When we start to view technical debt as simply another part of the product puzzle, the perceived complexities of doing so wash away. Working on repayment of technical debt is really no more difficult or complicated than scheduling any other work that we do.
We need to engage with our stakeholders and subject-matter experts, understand the nature of the work needed and the risk/benefit of taking it on, and create backlogs that can be prioritized so that teams can take on the work. When we are transparent about the type of debt that we’re taking on, it is far easier to seamlessly work it into our daily efforts defining our product vision, strategy, and tactics.
Get more advice from Cliff Gilley in the on-demand webinar, The Clever PM: Practices, Metrics & Principles for an Agile World >