Should Your Team Focus on Technical Debt or New Features?

As software engineers, especially those of us working with legacy code, we often find ourselves caught in a familiar tug-of-war: should we focus on shipping new features or address our mounting technical debt? Recently, I experienced this firsthand when our team faced this exact dilemma during a skip-level meeting with upper management.

The Situation

During a skip level with my manager’s manager (wow, I sound like corporate Erin—iykyk), we had a huge discussion about technical debt versus new features and whether we should focus on one or the other.

On the one hand, our codebase was showing its age. We had inconsistencies that were slowing us down: some parts still used Sass while we had moved to SCSS, and we had an inconsistent implementation of Redux across different features. On the other hand, our leadership was laser-focused on hitting quarterly KPIs through new feature development and rightly so, because hitting KPIs usually means more money! (or at least keeping our jobs).

However, one of my teammates voiced what many of us were thinking: the technical debt was actually making it harder to implement new features. That's when I shared an analogy that helped shift the conversation.

The Kitchen Analogy

I explained it this way: "Developing new features is like cooking a meal. Dealing with technical debt is like washing the dishes."

Think About It:

You can keep cooking new meals (features) without washing dishes (addressing tech debt) but eventually, you'll run out of clean pots and pans (development becomes increasingly difficult), the dirty dishes pile up (technical debt grows), and you'll spend more time working around the mess than actually cooking (development slows down).

As someone who loves cooking but hates washing the dishes, I know this first hand. And that’s probably why I made the analogy.

The Turning Point

This simple analogy resonated with our manager's manager (maybe he’s a chef who hates washing dishes too). It helped illustrate that dealing with technical debt isn't just an engineering preference—mounting tech debt can be a real impediment to delivering business value. The result? We were granted an entire sprint dedicated to addressing technical debt.

The outcome was so positive that it became a regular part of our development cycle: we now dedicate one sprint per quarter to technical debt. This scheduled maintenance has made our codebase more maintainable, readable, and—most importantly—easier to extend with new features.

Should Your Team Focus on Tech Debt or New Features?

Before I go into the questions that you should ask yourself and your team in order to decide whether you should focus on tech debt or new features, I want to explain what tech debt is for those who don’t know.

Sonasource says that “Technical debt, also known as code debt or design debt, is a term used in software development to describe the cost of additional rework caused by initially choosing a quicker delivery over clean, efficient code that would take longer.”

For us, the Sass or files that didn’t have Redux weren’t considered tech debt in in of itself. However, the fact that we decided as a group that we would use SCSS instead of Sass and Redux for our state management but did not fix the legacy code to reflect those changes caused our code to be inconsistent. That we piled on without making the changes is what is considered the tech debt.

This is what slowed us down. That being said, if you are facing similar issues on your team of software engineers but also want to meet your KPIs please consider the following questions.

Questions to help your team decide

1. Technical Debt Assessment

   • Can you identify specific instances where quick solutions were chosen over better approaches?

   • What's the actual "interest" you're paying on these decisions?

   • Are there critical areas where technical debt is accumulating risk?

2. Codebase Health Check

   • Are there inconsistencies that make onboarding new developers more difficult?

   • Do developers frequently need to context-switch between different patterns or approaches?

   • Would standardizing approaches across the codebase significantly improve productivity?

3. Business Context

   • What are your current business priorities and deadlines?

   • Can you quantify the cost of delayed feature delivery versus the cost of maintaining the current state?

   • Are there upcoming major features that would benefit from a more consistent codebase?

4. Risk Evaluation

   • What are the risks of not addressing true technical debt now?

   • Are codebase inconsistencies causing bugs or making testing more difficult?

   • Could current practices lead to major issues in the future?

Finding the Balance

The most successful teams find ways to balance new feature development with codebase maintenance. Here are some strategies that worked for us:

• Dedicate regular time to both technical debt and codebase improvements

• Include standardization tasks within feature work when possible

• Maintain a backlog of technical improvements, prioritized by impact

• Set clear criteria for when issues need immediate attention

• Communicate the business value of a clean, consistent codebase to stakeholders

Conclusion

While the pressure to deliver new features will always be present, ignoring technical debt completely is a false economy. Meaning, you think you're saving money/resources in the short term, but it actually costs you more in the long run you. Or with the dishes analogy: you may be saving time but, in the end, the dirty dishes are piling up making it harder to cook up some new features. By helping stakeholders understand the real impact of technical debt on feature development, you can make a compelling case for addressing it proactively.

The key is finding the right balance for your team and communicating the value of technical debt work in terms that resonate with business stakeholders. Sometimes, you need to wash the dishes before you can cook the next meal.

What's your team's approach to managing technical debt? How do you balance it with new feature development?