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

🔥

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

Identifying the “Right” Problem to Solve

2 December

Anurag Jain, a leader role at Fortinet, speaks about finding a solution when for a project the apparent needs were not the thing to be solved.

Alignment
Conflict Solving
Collaboration
Strategy
Anurag Jain

Anurag Jain

Leadership Role at Fortinet

Increasing Collaboration Within Your Team

2 December

Anurag Jain, a leader at Fortinet, discusses his strategy to promote growth within his teams, using servant leadership concepts.

Scaling Team
Personal Growth
Leadership
Internal Communication
Collaboration
Anurag Jain

Anurag Jain

Leadership Role at Fortinet

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

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.