How to Creatively Juggle Technical Debt and Product Priorities

Problem

Working in a fast-paced delivery environment can be pretty exciting and motivating, especially if one enjoys this type of challenge. For one to be successful in such a workplace, it’s essential to learn how to juggle multiple high impact projects, keep a close eye on delivery timelines and prioritise and reprioritize constantly. I recently worked with a team that had a very fast-paced delivery schedule and was responsible for rapid delivery of several enhancements to an internal user facing application.

However, there was a large obstacle in that the codebase was quite clunky in parts and had some suboptimal patterns which needed a good amount of refactoring. This meant that while our delivery timelines were tight, the obtuse nature of the code made it that much harder to stick to them. We definitely needed to invest some time and effort in rewrites, but there was no clarity on what part of the codebase to tackle since almost everything had scope for improvement.

Actions taken

It sometimes happens that teams face conflict between the engineering goals and the product goals, and more specifically, conflict between the Engineering Manager and the Product Manager. The Product Manager, understandably, would like to emphasize business deliverables, while the Engineering Manager would also like to tackle technical debt and enhancements. Tackling these technical priorities are critical to overall system extensibility and stability, as well for developer productivity.

Speaking with our Product Manager in depth about the shortcomings of our system helped get them on board with prioritizing some of the technical work we had planned. Clear outlines of why this needed to be addressed now, and why neglecting some of this work would lead to cascading issues in the future, were helpful in emphasizing the urgency of this effort. We were able to agree on allocating a larger amount of time and effort towards minimizing tech debt in the upcoming quarters.

Once that was sorted, it was time for us to start creating a backlog of tech-debt stories. We refrained from making large unplanned refactors, and instead, created detailed tickets for any non trivial work that needed to be tackled. We then started brainstorming ways to prioritize our tech debt. One of our engineers suggested adding a “pain points” system. For instance, we would rack up the “pain points” on an area of code every time an engineer was slowed down because this code was not optimally written or obtuse. Similarly, any bugs that originated from a suboptimal implementation also racked up the “pain points” for that area of the code. At the start of every sprint, we would prioritize the tickets with the highest number of pain points. This way, we could ensure that the most critical and oft encountered areas of code received the appropriate attention.

The above system was great for smaller code changes, but we also needed to tackle larger refactors and replacing outdated patterns. We started to bake in tech debt and refactors into the scope of new product development. If we had to build a brand new feature that touched an area of code that needed a rewrite, we would try and extend the deadline by a bit and include the rewrite as part of the feature scope. As part of this process, we started taking some additional time before the actual implementation to understand the potential areas for refactor during the discovery phase. We also tried to scope an additional week of buffer time in case the refactor turned gnarlier than expected.

Using our tactics above,

• We were able to address the most critical areas of technical debt
• We were able to bake refactors into the scope of the project itself and ensure that we weren’t spending time on costly rewrites that weren’t immediately useful.
  

Lessons learned

• As the Engineering Manager, it is essential to have a solid trust-based relationship with your Product Manager. Having a great, transparent relationship with your Product Manager makes all the negotiations and conversations that much easier.
• In the case of legacy systems, it is sometimes overwhelming to know where to start addressing technical debt. Surface the most problematic areas early in order to get the maximum utility for time spent.