Overcoming Either/Or of 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.