Several years ago, when I led technology teams, I proposed halting new developments until we paid off our technical debt. However, due to the organizational culture and my inexperience, I was unable to achieve the results I desired. In this article, I will share my story and the lessons learned, so that organizations can effectively manage their technical debt.
We achieved the expected results but with some technical debt
Let's start with some context: In our first product (MVP), we had to learn new technologies. For instance, we implemented DevOps for the first time, automated tests for our web application, and used specialized frameworks for both the frontend and backend. Although we achieved the expected results in terms of the business strategy, we also accumulated some technical debt.
Shortly after that, we began working on the second product (MVP) while continuing to improve the first one. We made the strategic decision to build it in the cloud, but as a mobile application rather than a web application. This required us to learn new technologies for DevOps, automated tests for mobile, and new frameworks for both frontend and backend, in order to take full advantage of the cloud. Once again, we achieved the expected results, although both products incurred moderate technical debt.
I proposed a "freeze" to halt new development and address our technical debt
Before starting work on the third product (MVP), I proposed a "freeze" to halt new development and address our technical debt. Specifically, we needed to simplify our technology stack, correct errors, and eliminate duplications in order to prepare for building new products. This was necessary to effectively scale our existing products, deliver greater business value, and motivate the team.
Before starting work on the third product (MVP), I proposed a "freeze" to halt new development and address our technical debt. Specifically, we needed to simplify our technology stack, correct errors, and eliminate duplications in order to prepare for building new products. This was necessary to effectively scale our existing products, deliver greater business value, and motivate the team.
Lessons learned
So, what lessons have I learned? Over the years, I have identified several, and here I will share some of them in the hope that they can help you create better digital products.
Train business roles in technical debt from the beginning. If they do not understand why we incur debt and why it is inevitable, communication will be impossible.
Communicate every time you incur technical debt without waiting months to show it.
Add tasks to reduce technical debt to the backlog and keep an exclusive epic for it if necessary.
Assign a small percentage of tasks to reduce technical debt in all sprints. If necessary, dedicate a full sprint or half-sprint every three months to reducing it.
Accompany business metrics with the status of technical debt in digital products.