Technical debt is an area that always causes heated arguments between product and engineering. Actually, scratch that. Arguments mean that this is being discussed, passionately. In many cases, it is left hanging out there, without a real resolution, and leaves both sides frustrated. 

I’ve heard engineers saying that product isn’t letting them do things right, and product managers who claim that engineering is always stalling things. I’ve seen engineers who decided that they work on technical debt although there was a specific decision not to do it or simply load it on top of other features (and no one knows it is actually technical debt), and product managers who refuse to even discuss it. But I’ve also seen (many) cases where it works well, and I’ll explain here how to get there.

The Technical Debt Must Be Managed

Technical debt, like any other debt, is a risk. The implications of it when it materializes can be very wide – from production stability and scale issues, through long development cycles and constant fire-fighting, all the way to employee happiness and even impact on recruiting. However, since it’s a risk, it means that it doesn’t always materialize, and not every little piece of technical debt has or can have that impact.

As you can see, the decision on whether or not to repair specific technical debts is not straight forward (unless you have unlimited resources, which I’m pretty sure you don’t). If you decide to always repair all the technical debts that you have, you will not be able to move fast. Some teams won’t be able to deliver new functionality at all for a very long time. If you decide not to repair any technical debts, the risk will eventually materialize for sure.

The result is that each case requires some analysis and thinking in order to make a sound decision. It is up to engineering to identify the gaps and raise the needs, together with a suggested solution. This will always be the case since the technical debt is, well, a technical issue.

But who should they raise it with?

The product manager is not necessarily a technical expert, and in most cases will not be able to contribute anything to the technical discussion itself (I’m saying that as someone who has a deep technical background and still found myself unable to help with the technical details many times). Many aspects of the product manager’s work are not their responsibility in this case: identifying the need, defining the problem to be solved, and the approach for the solution. 

So why should the product manager be involved at all?

Because repairing the technical debt often requires much time and effort from the team, and it impacts other commitments and priorities that the team has. So at the bare minimum, the product manager needs to know that the team is working on something else. 

Of course, this minimum is usually very insufficient. If the discussion ends there (“hey, product manager, just FYI that in the next few sprints we will be repairing some technical debt so no capacity for anything else. See you in a bit”) the product manager will feel that they have no power to make the decisions that they need to be making, and rightfully so.

But to start explaining to the non-technical product manager what this issue is about and “asking for permission” to work on it is also not productive and leaves engineering frustrated and not at all empowered.

Some companies solve that by allocating a certain percentage of engineering time to technical debt related work. While it saves the need for these somewhat tedious discussions and perhaps helps in reducing frustration, in many cases it doesn’t really solve the problem and creates new problems on top of it. Certain technical issues require much more than the allocated time (or they would take forever to repair), so we are back in stage one. Moreover, in smaller teams who need to move fast, and particularly in startups where there is still a large functional debt to close, allocating a considerable amount of the resources to technical debt prevents you from optimizing the work and delivering value fast enough.

Technical Debt Is a Product Issue

The product manager’s job is to deliver value to customers quickly and effectively. Technical debt meets this definition in multiple ways: first, it competes on the same resources, so it by definition impacts the outcome, and second, in some cases it impacts the value customers actually get either directly or indirectly.

That’s why I see the technical debt first and foremost as a product issue. And as such, I expect the product manager to own it just like they own any other product issue. Specifically, I expect product managers to own the prioritization and time allocation for repairing the technical debt.

Some product managers translate “owning the prioritization and time allocation of the technical debt” to “allocate to it as little time as possible, ideally none”, and that’s absolutely not what it means. Your job as a product manager is not to be the gatekeeper of the roadmap from engineering. Your job is to deliver value, and continue to do so (either personally or set the ground for your predecessor to do so) regularly and forever.

When you look at it this way, if you completely neglect technical debt, your ability to do your job is guaranteed to be impacted. If your product doesn’t scale, you won’t be able to deliver value to a larger audience (and if you did your job right, you should meet that challenge at some point). If your dev cycles are too long and engineers are fire-fighting most of their time, you won’t be able to get any new functionality out the door on a reasonable time to market. If your dev team is losing motivation and can’t recruit great talent, you are in a much bigger problem in terms of your ability to take the product in the right direction. 

To do your job as a product manager, you want to repair the technical debt. The question is, like many other things that you want to get into the product, is which ones, to what extent, and when.

Making Technical Debt Resolution Easy

Now that you understand that you should not only care about technical debt but also actually prioritize it over other things, here are three things you can do to make this process less painful – both for you and for engineering. If you follow these guidelines, you will see that technical debt is no longer something that no one wants to discuss, and handling it doesn’t have to cause so much frustration on both sides. It will become another tool for you to get things done.

Ask the right questions

As I stated above, engineering should still identify the areas with technical debt and raise them to you. Since you have the final word on prioritization, you need to understand what this is all about. If you have a technical background, it is very easy to ask technical questions and fully understand the technical issue itself. But that’s usually not what you really need to do.

You need to ask a very different set of questions, ones that you can ask even if you don’t have any technical knowledge. You would need to trust engineering’s answers here, but don’t be shy of asking for clarification and some additional technical explanation if that’s what you need to fully get it. 

Instead of asking about the technical issue itself, you should focus on the impact of the issue, its magnitude, severity, and likelihood to show up in the near future. You should ask questions like:

• What happens if we don’t repair this? [seek to understand how this impacts customers and in which use cases on one hand, and the impact on developers on the other hand]
• How severe is it? [try to quantify the impact and translate it to potential business loss or person-days spent on working around it until it is repaired]
• When are we going to see the impact mentioned above? [some issues develop faster than others, while others are a much longer-term risk]
• What happens if we defer the repair? [seek to understand if the impact gets bigger with every day it isn’t repaired, or is it the same effort and same impact as long as you repair it before it materializes]

At the end of this discussion, you need to fully understand the issue and the implications of not resolving it now or in the near future, so that you can make a smart decision about prioritization. Note that in most cases, the decision is not straightforward, and involves risk management practices. You should understand the risk you are taking with each decision, and decide accordingly.

Assume good intentions

Trust is everything when it comes to the product and engineering relationship. With technical debt, this is even more extreme. You often need to rely on engineering’s answers as is since you simply don’t know any better. Some product managers feel very uncomfortable in this position. If the relationship isn’t good, it is easy to feel that engineering might be trying to push their own agenda and trick you into accepting it. I assure you that if you ask the questions I listed above it would be very hard to do so, so you should not feel helpless in this situation.

When you get a new request to work on technical debt from engineering, assume that they are doing so because they care about the system as much as you do and not because of some hidden agenda. It will allow you to genuinely have a discussion on the above questions and make a decision that everyone will be happy with. If you have your own agenda (which is a result of you assuming they have an agenda that you need to fight), your decision might be biased. 

Instead, you should be happy that such a technical issue was brought to your attention. Blind spots are never a good thing, at least now you can make an informed decision and potentially keep an eye on the issue so that you know what you are up against.

Say yes

Your end goal here is not to put minimal effort into repairing the technical debt. Your end goal is to continuously and regularly deliver value to your customers and to the company. Closing the technical debt is yet another way of doing so, so when it is right and worth it – you should happily and easily say yes to engineering. Allocate a decent amount of time for issues that truly need repairing. 

If you follow the questions I suggested above, for some issues it will be clear that they need repairing, and the sooner the better. When this happens, give engineering what they asked for without too much hustle.

Not only will it make your product better, but it will also build and strengthen the trust between you and your important partners. If for nothing else, it will make it easier for you to say no at other times when you are not convinced that an issue is worth solving. But I hope that by now you are convinced that saying yes to (some) technical debt repairing is good for you nonetheless.