Over the last few years, the concept of technical debt has become a mainstream metaphor amongst the product management community. Here are the most common types of technical debt as well as a few strategies to help product teams manage it…
When Speed Trumps Perfection
Sometimes teams knowingly take on technical debt because they need to get a product or feature to market quickly. It’s valuing speed over perfection. Product teams make a conscious decision to use a suboptimal solution because it’s quicker, easier or cheaper to implement. Usually when they do this they also rationalize that they will clean it up as soon as they can after the product or feature has launched. The quick and dirty work that is a result of the conscious decision to implement a suboptimal solution in order to get to market faster will have been worth the extra effort of doing right later.
When We Just Didn’t Know
This is the technical debt that’s shouldered unwittingly. Sometimes teams unknowingly take on technical debt because they’re learning a new technology as they’re developing or they lack experience with a particular software architecture pattern. In another instance, they might not fully understand or appreciate the scope of what’s being built and its impact on the rest of the product. The act of unknowingly taking on this sort of technical debt should be minimized, but isn’t a sign of mismanagement or incompetence. Rather it’s a side effect of high speed nature of digital product development.
Obsolescence
The third form of technical debt is a contentious one in software development circles. Some see it as tech debt, other don’t. It occurs when languages, frameworks, libraries, tools and other technologies—open or closed source—become obsolete, deprecated, or fall out of the mainstream. It’s not always possible for product teams to forecast which technologies will succumb to this sort of instance and when—especially at the moment at which adoption decisions are made. But when something like this does happen (and it will), teams should consider it technical debt in order to put together a plan for retiring it, adopting a better solution or figuring out how long they can ride it while still making forward progress.
Technology leaders and product managers now have to consider technical debt more frequently than they ever had too. Poor planning around the identification and retirement of technical debt can stall product roadmaps and result in business objectives missed. Here are a few ways teams can better manage their technical debt…
Building a digital product?
Make Time to Think Hard About Technical Debt
Product teams need the bandwidth and space to look beyond individual features on the roadmap and consider the entire roadmap. They need to be able think through how well the current technical solution is positioned to enable future development of features both user-facing and those designed solely to allow engineers to create more extensible products and be more productive in future user-facing feature development. When teams are disciplined about dedicating time to think about technical debt, they’ll consistently find themselves in a better place.
Accept Technical Debt’s Existence in the World
Technical debt is not necessarily a bad thing. Companies take on financial debt to accelerate growth. Individuals do it to make large purchases. The common key in these situations is understanding how critical it is to track the debt. Teams (or companies or individuals) need to know when debt is creating value and when it is projected to become a burden. Prudent product managers will not only know when a technical debt becomes too heavy, but they’ll also be quick to develop a mitigation plan before it becomes a significant hindrance.
Set and Challenge Your Growth Goals
With new products, teams are typically hyper-focused on the MVP and showing value to the user. This often leaves technical debt ignored at a stage where it should really be watched if not serviced. An intelligent way to keep an eye on technical debt early on and throughout the product life cycle is to create and regularly review key product growth metrics in the vein of “the product should support 10,000 simultaneous users” or “the product should process one million messages per second.” (Those are just random examples.) Whatever the metric, teams should be prepared to challenge the product by “adding a zero” to their metrics. If the product can’t manage that new target and if the team has some ideas as to why, that can be a sign of technical debt creeping up. Obviously not all of those reasons will, in fact, be technical debt. That’s not the real point. The real point is that this exercise creates a simple litmus test that can start the conversation within the product team to identify potential debts that weren’t consciously taken on. From that point, the team will determine what decisions need to be made and when.
Engineers Should be Stakeholders in Technical Debt
For engineers, products and features are never done. They know they can be better, faster or more elegant, but time, money and management get in the way. Engineers have to make technical decisions with imperfect information from the product roadmap and users. (Even in truly great products, engineers may not find the perfect technical solution for months or years because a full understanding of the product’s actual use can’t be known upfront.) All of this is why engineers should be active participants in technical debt identification and management. Teams that empower engineers to do so will not only have happier, inspired engineers, but also better products and greater efficiency.
Know that Not All Debt is Technical
Sometimes product debt occur as a result of teams pushing features that their users ultimately did not want. Or sometimes design debt is incurred when UI/UX decisions don’t align with how users want to use a product. Despite perfect technical implementation, things like these are still debt—just not technical. It’s important to recognize that because treating all debt as if it were technical debt can have unintended outcomes. Product teams should constantly collaborate with cross-functional teams so that everyone involved can understand which types of debt are which and how they should be dealt with.
Don’t Service a Debt—Particularly a Large Technical Debt—All in One Shot
Pushing a full release or version cycle with no new features or improvements can be excruciating for users and downright boring for design and development teams. To combat these scenarios, product managers should figure out how to amortize debt servicing so that a balance of forward progress on product is sustained while debts get paid down. This approach will make everyone—from designer to engineer to user—much happier.
Shahrukh Tarapore is the Head of Engineering at Arcweb Technologies and is committed to reducing the national technical debt for our children’s future.
