Back to resources

How to Creatively Juggle Technical Debt and Product Priorities

Conflict Solving
Tech Debt

10 June, 2021

Shruti Venkatesh
Shruti Venkatesh

Engineering Manager at Capsule

Shruti Venkatesh, Engineering Manager at Capsule, talks about what goes on an EM’s head when faced with technical debt and tight product deadlines.


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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Hiring a Data Team With a Stubborn Manager

24 May

Liz Henderson, an Executive consultant at Capgemini, shares her experience hiring a data team with a manager who was difficult to work with.

Managing Up
Building A Team
Conflict Solving
Data Team
Liz Henderson

Liz Henderson

Executive consultant at Capgemini

How Less Viable Solutions Solve Common Architectural Challenges

13 May

Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.

Different Skillsets
Conflict Solving
Tom Hill

Tom Hill

Engineering Manager at Torii

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Dev Processes
Conflict Solving
Internal Communication
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Balancing Technical Debt Innovation: How Roadmaps for Development Help Your Company Succeed

4 May

Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.

Tech Debt
Career Path
Brad Jayakody

Brad Jayakody

Director of Engineering at Motorway

Leading Your Team in Stressful Situations

27 April

David Kormushoff, Director at Koho, recalls how he galvanized his team to tackle a time-sensitive problem, sharing his tips on how to shift chaos into calm.

Goal Setting
Conflict Solving
Health / Stress / Burn-Out
David Kormushoff

David Kormushoff

Director at Koho

You're a great engineer.
Become a great engineering leader.

Plato ( is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.