Tech Debt for non-Tech People

If your product is anything more than a week old, there is Tech Debt. What is Tech Debt? How does it hurt your Product? What should you do about it?

Tech Debt is A-OK

Though Tech Debt may seem like the pot hole your team could at any moment stumble into, it’s a healthy part of the SLDC. Similar to have credit card debt in your personal life, it allows you to purchase larger ticket items as you wait for your paycheck to come in. Or it can be like student debt where you rack up a bunch of it while you are growing and once you are in a steady state you can start paying it back. In both cases, debt is required to get you where you want to go. The same goes for Tech Debt.

Tech Debt is the remnants of previous releases which make developing new features more tedious than it would be if you were starting from scratch (like a Tetris board). Don’t get mad that it exists, your engineering team was (hopefully) operating under whatever knowledge they had at the time of development and working with the best intentions of reaching the targets set for them. Remember that racking up tech debt is most common when there are deadlines set by product and corners are cut. You or your peers probably had a role in getting you to the current state, and you have to own that.

Though engineers claim to loathe tech debt and wish they could eliminate it, it is rarely the best idea to attempt to plan for all potential futures that are not well defined today. You will end up investing a lot of engineering time in things that may never happen. If you have a good idea on your direction down the line, share it with the development team so that they can keep it in the back of their heads as they architect the software. Don’t make it the primary focus, that should always be the customer or business value the team is working on right now.

When to “Pay Down” Tech Debt

Again with the credit card analogy, the phrase for getting rid of excess tech debt is to “pay it down”. Note that it’s not pay it off, as it is pretty near impossible to eliminate all tech debt, and isn’t worth the effort even if it was. But you don’t want to be drowning in tech debt anymore than you want to be haunted by high credit interest rates.

Engineers don’t love having what is referred to as spaghetti code or non-optimized code out there. Engineers are problem solvers. If the problem is tech debt, they will want to pay it down. They are the people who seemingly are most affected by the tech debt as when they are working on new features or bug fixes, it will take them longer to do what they need to do.

But Engineers are not the only teams impacted. Customers may experience a buggy experience, account managers may deal with churning clients, sales teams may have to wait longer for features that help close deals. Tech debt is felt throughout the organization in different ways, and therefore you as a product manager should prioritize paying it down, but when? Here are some options on how and when to pay down tech debt.

Regular Refactoring: I describe this process as cleaning out the vegetable drawer from rotten veggies before you put fresh ones in. The rotten ones will in fact spoil the newly purchased ones. If you clean a little bit every time you open the drawer, it will often be maintained for a few months without any issues. Similarly, if you encourage the engineers to “leave the code better than they found it” as they add new features the code base will continuously get better. Be sure to timeboxthis effort (work with the engineering lead on what is appropriate), but know that similar to bug fixes this should be allocated as part of resource planning.
Periodic Rearchitecting: Every so often your fridge needs a deep clean and the same goes with your code base. Maybe you now have dozens of transactional emails sent by the system and the team wants to consolidate them into templates. There could be a big initiative that the current architecture won’t support. Alternatively, your product may have performance issues that are causing churn or a certain part of your application is too buggy for customers to use. These are all good reasons to invest heavily in paying down a lot of tech debt.
Platform Transitioning: Now your fridge is old, it’s time for a big upgrade. You have to figure out whether all needs to go, or that it just needs a new shelves, or that only the freezer is broken and you can buy a separate deep freeze. In tech, the situation is that you’ve built a solid product with monolithic architecture and are now changing your business strategy to become a platform, and there will be APIs which will be built to support the ecosystem. Those APIs can also be used internally as well and a big effort maybe required to transition the current application(s) to those APIs. As applications are changed to consume the APIs (which is a rearchitecture in it’s own right) additional optimizations will generally also be made. Be careful with building everything from scratch as you can generally segment out big or small chunks of functionality together similar to that separate freezer instead of throwing out everything.

When you’re considering doing something like a big architecture change, be sure to understand the full costs of the current situation and the potential benefits of a big change. Weigh the costs (including customer service time, lost deals, maintenance costs, wasted engineering time, etc.) against the potential benefits (new logos, faster customer onboarding/revenue recognition, ability to bring on partners, etc.) and make sure that the effort is a sound business decision. This is easier if you have solid Product Operations dashboards available, but estimating each of those drivers will be key to making the right decision. It will also help you scope the project to be “right-sized” and deliver maximum value.

Have you done a financial analysis and proven that the effort to pay down tech debt is worthwhile? That’s awesome! We’d love to hear about how you evaluated the cost and benefits, please share.