Back to resources

Overcoming Either/Or of Tech Debt

Collaboration
Tech Debt

17 May, 2021

Dale Hopkins
Dale Hopkins

CTO at Vendasta

Dale Hopkins, CTO of Vendasta, uncovers how to heal the relationship between Engineering and Product by allocating a slice of a backlog for tech debt.

Problem

Most managers are torn by the dilemma of working on features or working on tech. In most cases, they will flip flop between pure feature development and tech debt. They will do features until tech debt accumulates to the point where velocity sharply decreases, or customers become unhappy. The common scenario further unfolds: Engineering would convince the business that they should do tech debt. They would stop releasing features and start fixing a codebase. In the meantime, people would become impatient because of all the features on hold. When impatience culminates, they will switch to full feature development. And this would happen, again and again, becoming a rollercoaster for most companies.

Actions taken

While there are volumes of books and articles that you can delve into, what you need to do -- rather than studying the problem -- is to build a relationship between Product and Engineering. If you don’t do that, flip-flopping will become your modus operandi. A senior leader should step in and make Product and Engineering agree. Two functions should agree on a per-project basis and never switch only to tech debt or only project features. One should probably allocate on the order of 20 to 30 percent to either one of them at all times. That means you should be able to switch from 70/30 to 30/70, but you won’t be able to go from 100 to zero. Only that would allow for an approach different from flip-flopping.

The core of the relationship between Product and Engineering in our organization rests on the interaction between a product owner and engineering manager. By learning about that relationship, we understood a great deal about the process itself. In Agile, a product manager owns the backlog, which implies that the product person will schedule a sprint. Consequently, Engineering would have to write tech debt tailored to explain to the PM why addressing tech debt is important. That approach is inherently paradoxical; you will have to explain tech debt to a non-technical person and have them schedule it against regular product items. However, what we found to work better is that Engineering owns a slice of the backlog allocated for tech debt. Then Engineering can work with an EM to decide what is important and allocate that. You will still have an oversight of what you are going to schedule but without having to educate a product manager on tech debt and thinking about business value too. It is something that should be done at all times because it is a matter of long-term maintenance and as long as Engineering has its allocation, they should be able to self-manage it.

This approach also directs product people to think about customers. One of the worst-case scenarios is when product people start to think about technology. Then they start to discount customer ideas and start to unconsciously make tech decisions. Suppose we can separate their responsibilities off and demarcate that an EM and Engineering are responsible for tech debt and scalability and Product for customers and the features that the product needs to be able to serve our customers. In that case, that demarcation line becomes much more transparent and better grounded. Engineering shouldn’t do something because of customer requirements bypassing decisions made by a product manager. Also, Product shouldn’t decide not to build a feature because they think a database wouldn’t support that, for example.

Lessons learned

  • You need a continuous blend of both tech debt and features and not to work on one or the other. Rather than doing one thing at the cost of the other, you should work on both in parallel. Otherwise, you will experience a backlash against one or the other and have oscillations instead of a steady state.
  • If you can keep Engineering focused on engineering issues and Product on product issues, people will work on what they are good at. It is commendable that they understand each other but asking Product to understand and prioritize tech debt is an anti-pattern.
  • Establishing a clear split will allow Engineering and Product to have co-ownership of a product. They both care about the product but about delivering different aspects of it. The clear separation allows for cooperation and encourages them to be partners and not fight over what needs to be done. It paves the way for a non-antagonistic relationship between Engineering and Product, critical to addressing tech debt.
  • Investment in tech debt and maintenance is the most important one. If we look at the long-term cost of software, it is heavily weighted toward maintenance. Tech debt is not a minor investment in the total cost of the product; looking long-term, it is the largest piece of software development. As Tom DeMarco said, “Quality is free, but only to those who are willing to pay heavily for it.” That means you have to invest in tech debt all the way along, but if you do that, the payback is a velocity that stays where it needs to stay.

Discover Plato

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


Related stories

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Managing Different Time Zones: 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.

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.