A practical approach to tech debt
Why am I writing a newsletter? Good question. I intended to create a post, and LinkedIn suggested I create a newsletter. So here we are.
What's the newsletter for? It's a vehicle for learning. For me, product management is similar to being a skilled craftsman. We typically follow a trajectory that's akin to the path from apprentice to journeyman to master. I am now in my third decade of doing this sort of work and like to think I've developed some level of mastery. I also want to continue learning, and a good way to do so is to share what I know and see what others have to say in response.
Perhaps the most valuable lesson I have learned as a product manager is to prioritize my tech debt. We are under constant pressure from our customers and potential customers to release new features. We are also under constant pressure from our engineering team to resolve tech debt. Since our customers pay our wages and those of our engineering teams, the typical approach is to develop the feature first and then resolve the tech debt. Makes sense, right?
Wrong. Let's say that my biggest, most strategic opportunity is dependent on developing a new widget in my application. At the same time, my engineering team is telling me that they need to update to the newest version of one thing or another in our tech stack. Which of the following options should I choose: A) build the widget, then do the version update, and then refactor the widget to work with the new version; or B) update the version and then build the widget in the new version?
Recommended by LinkedIn
Option B is the clear winner. And it helps me win with both my customers and my engineering team. By prioritizing tech debt in this manner, my overall feature velocity is higher in the long run, so my customers win. My engineering team avoids the frustration of building the same feature twice and feels seen and heard, so our sense of unity as a team is enhanced, and our performance improves.
What do you think? Is this a winning approach? When should I make exceptions?
I look at tech debt the same way I look at financial debt. Maybe that’s my accounting background coming back into play. In the finance world, good debt has the potential to increase your net worth or provide strategic leverage. Bad debt involves borrowing money to purchase depreciating assets for the purpose of consumption. Similarly, I believe in good tech debt and bad tech debt. Good tech debt (prioritizing new features over maintenance of our tech stack in order to close a big prospective client or retain an existing one, or skipping corners to release features quickly, knowing you’ll have to go back and refactor things later) has the potential to dramatically increase or retain revenue. Sometimes it can also stop the bleeding if you have a serious bug. Good tech debt is taken on with a strategic benefit in mind, and, most importantly, we take on the debt only if we have a repayment plan in place so that we don’t allow ourselves to become over-leveraged. Bad tech debt is typically incurred due to frivolous feature development and turning a blind eye to the long-term consequences of your recklessness. There is a place for strategic tech debt, but be responsible with it. It will own you if you aren’t careful!