Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Mergers and Acquisitions: Collaboration tools hold a key to bringing cultures together

23 November

Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.

Acquisition / Integration
Internal Communication
Collaboration
Neelima Annam

Neelima Annam

Sr. Director Information Technology at Outmatch HCM

How to Build Rapport With an Introverted Manager

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.

Managing Expectations
Internal Communication
Collaboration
Coaching / Training / Mentorship
Juniors
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

The Benefits of Stakeholder Communication

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares how to understand the stakeholder communication process better and why it is essential.

Meetings
Internal Communication
Collaboration
Ownership
Stakeholders
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

How to Work With People Who Are Different Than You

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, shares how effectively he collaborated with a newly-joined team as a diverse candidate.

Acquisition / Integration
Leadership
Collaboration
Cultural Differences
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

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.