Despite I am not a software engineer, for the majority of my professional life, I’m working with engineering teams. I have the pleasure to be working with people great at what they do. So, I will try to answer the question on the title from a product management perspective of a non-engineering background guy.
It’s a fact that there will always be the pressure coming from the backlog, business teams, management or the market and will be demanding to build new features. The thing is that if you are too ignorant about your technical debt, soon enough you will realize that it is too late to start dealing with it.
Marty Cagan is describing it very well in his book “Inspired”. In this book, you can learn how technical debt almost destroyed unicorns like e-Bay.
I have felt it with products I am working on as well. During my time working on Avocarrot Exchange we had that huge project, aiming to merge two products into one. Our SSP (Supply Side Platform) with the Mediation product. After 10 months of planning, meetings, development on how those two products would merge into one, we finally did it. And then reality kicked in.
Stability issues came up in various services, mainly arising from technical debt that was always “too minor to deal with it now”. The whole team started feeling the pressure, since those services, was not only used by our clients, but from internal users as well. At that point, the team had to make hard decisions, since we were practically suffering. New features and product backlog on the one side, technical debt on the other one. Obviously, the technical debt became our main focus, where we invested most of our resources. Fortunately, it was not too late for us, but this might be pure luck. In most of the cases, products with great potential rarely manage to come back from this.
This experience taught me the hard way that you always have to be proactive when it comes to technical debt. No matter how small the issue is, or how unimportant you believe it is, at a specific moment. Deal with it as early as possible. What I am trying to achieve now, is that we always have some people from the product team, that are exclusively working on technical debt resolution in each sprint, so that we won’t have to dedicate more resources on that later.
For example, if a team of 10 people is working on a product, it is a good idea to always have 2 of them working on technical debt projects. I realize that it might seem weird to the upper management and especially to people responsible for product or feature release deadlines. However, in my perspective, it is better to sacrifice 2 or 4 weeks of a feature release, than having no product in 4 months. The management might initially push against this. It is essential to explain the benefits of compromising with this and here comes the strong trust that should exist between the product team and the management.
If your product is really great the market will still be there for it. The question is will your product still be there for the market?
Last, it is of great value to be working with a super-strong team to back you up on this without even having to ask for it. I remember a Monday, when a guy from the team is coming in our daily standup saying “you know guys, I had some spare time over the weekend and I decided to rewrite the Exchange in Python” (this guy is a Python guru). Well, the result was that the new version of the product was performing 9x better compared to the previous one, cutting the cost in half. No planning, no speccing for the project. Just a very talented guy with a will to take initiatives. Such behaviors should not only be embraced, but become part of the product team DNA and workflow.
Concluding, be proactive when it comes to technical debt, always keep some balance between resolving technical debt and building new features and you must always be able to rely on a strong team in terms of skills and culture as well. After all, Lannisters are still in charge of the 7 kingdoms, and their house moto is “a Lannister always pays his debts”.