Back to resources

Should Tech Debt Be Managed

Dev Processes
Collaboration
Impact

30 November, 2020

Anant Gupta
Anant Gupta

Sr Director of Engineering at Grand Rounds

Anant Gupta, Senior Director of Engineering at Grand Rounds, argues that tech debt shouldn’t be managed unless it negatively impacts the business.

Problem

Prioritization of tech debt has been a widely discussed topic. Many people are still surprised to learn that I am not particularly concerned with tech debt. Or to put it more mildly, the fact that tech exists, doesn’t mean that you have to do anything about it unless it has a tied impact on the business. If you can articulate that impact on the business, then you should do something about it.

As organizations get larger they allocate more and more of their time to managing tech debt. How often have you heard that this piece of code is old and you need to invest in the engineering stack to make it greatest and latest? To do so, you often have to convince your product counterparts that managing tech debt is of utmost priority.

Actions taken

Before taking any actions, and especially before convincing your product manager to take any actions, ask yourself if you -- as an engineer and shareholder of the company -- believe that it is the right thing to do. Most leaders think in a shorter timeframe and are often being driven by arguments such as My team is not happy, I should do it. However, if you would think from the lens of what is the most impactful for the business, you may arrive at an entirely different conclusion. Shifting your vantage point changes how you are thinking about the problem.

If still uncertain I would suggest asking yourself a sequence of Whys. Why prioritizing tech debt is important? “It’s old and hard to use and maintain” appears as a common explanation. I would continue asking, “Why is that important?” If they would reply that engineers who are working on it don’t like it, I would try to understand how often they work on it. I would want to arrive at a rough but concrete equation that would help me make an informed decision. For example, one engineer spends a week every month, it is annoying and affects the morale of the team.

What this tells me is that a person spends 12 weeks annually working on it. Is there anything more effective or impactful they could be doing during those 12 weeks? Because, if you decide to remove tech debt multiple people would spend six months working on something that takes 12 weeks for a person.

Sometimes people think of tech debt as a tool of influence or a bargaining chip with their product counterparts. If you think that the relationship between Product and Engineering is one of influence and power -- you are wrong, because it is not a hierarchy but a partnership. You and your product manager should have common goals that are right for the company and together you should determine what is the most impactful thing to do.

The best approach to do that would be to apply your entire roadmap against the Expected Value framework as stipulated by Ray Dalio in his famous book “Principles” and identify what decision would have the highest value. Engineers often fail because they don’t take into consideration the probability of success, i.e. them being right. If in the end, both your PM and you agree that the tech debt item is the most important item in the roadmap -- you should do it.

Also, engineers often hesitate to get involved in the business side of things. They often fail to understand why something is strategically important to the business and would rely on someone else to tell them what they should be doing. A PM shouldn’t tell you what to do, their job is to bring to you that information, but your job is to share the conviction and align your team to what is important to the company.

Lessons learned

  • If you are approaching a tech debt conversation as an attempt to convince your PM, then you missed out on having an in-depth discussion that will result in the best, collaborative solution. Negotiating percentages here and there would rob you of the opportunity to understand the deeper meaning of the problem. Maybe there is something that both you and your product counterpart are overlooking that you should be focusing more or investing in.
  • When you approach a problem with a mindset “my job is to focus on engineering” you are disconnecting yourself from the business. While in fact, your job is to ensure that the business has the highest impact. By approaching it from the impact perspective you are instilling the right culture in the team. You are explicitly telling the team that you are trying to do the most impactful things. That sets the right culture as opposed to the never-ending chasing of new, shiny things.
  • As a leader, you have to take a principle stance versus doing things that make the team happy. Your job is not merely to make the team happy, but to make the team happy because they succeeded in something. You have to be an advocate for the company as well as for the team.

Discover Plato

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


Related stories

Managing Different Timezones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

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.

Architecture
Different Skillsets
Conflict Solving
Collaboration
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
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

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

Plato (platohq.com) 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.