Roadblocks to repaying tech debt

You can tell a lot about a team by how they handle their tech debt backlog. A backlog full of unresolved tickets isn't just a technical problem - it's a mirror reflecting how a team communicates, prioritises, and negotiates identity.

In this post, I want to explore the roadblocks that turn tech debt into team paralysis - and how to transform group procrastination into collective momentum.

Let's start with the roadblocks that arise between teams, before moving inward to those that occur within a team.

Roadblocks between teams

Roadblocks between teams stem from the misconception that tech debt is solely a technical issue, rather than a cross-functional concern shaped by organisational pressures.

1. Tech debt is purely a technical concern

Reason for the roadblock

Non-tech stakeholders not understanding the consequences of technical compromises to meet a deadline.

How to overcome the roadblock

1. Ensure that when quality compromises are being discussed due to time pressures, the consequences of any compromises are discussed.
   1.1. Document where a compromise is agreed.
   1.2. Be sure to repeat that the consequence of taking a compromise is tech debt.
   1.3. Use language that the non-tech stakeholders can understand.
2. Socialise the knock-on consequences of existing tech debt.
   2.1. Provide proof of past decision-making.
   2.2. Provide concrete examples where existing tech debt is harming momentum.

This roadblock arises when decision-makers don't have visibility into the technical impact of compromises. Rather than relying on abstract technical explanations, it's more effective to share tangible examples of how past compromises are impacting current development efforts. Tracing how past compromises affect today's development can feel time-consuming, but it's essential.

Even the term 'tech debt' can unintentionally signal that it's a purely technical issue. Reframing it in terms of delivery risk or product velocity can help build shared ownership.

2. Tech debt is due to poor technical skills

Reason for the roadblock

The belief that tech debt exists due to poor technical execution, so the development team should "eat" the effort to repair the damage while delivering features.

How to overcome the roadblock

1. Ensure that when quality compromises are being discussed due to time pressures, the consequences of any compromises are discussed.
   1.1. Document where a compromise is agreed.
2. Ensure that the team members have learning opportunities to address any skill shortages.

Development doesn't happen in a vacuum. Some tech debt will result from a skill shortage among the development team, while other tech debt will be the result of the demands placed on that team. While the development team are responsible for actually repaying the tech debt, everyone involved in shaping and delivering features should be aware of the downstream impact of compromises. Be watchful for any technical gaps within the team and develop a plan to address them.

3. Tech debt can be sneaked into feature development.

Reason for the roadblock

The belief that tech debt is just polishing.

How to overcome the roadblock

1. Ensure that the consequences of past decisions are shared.
   1.1. Document where a compromise is agreed.
   1.2. Document the expected effect on new work in that area.
   1.3. Use language that the non-tech stakeholders can understand.
2. Ensure that successful tech debt repayments are socialised among the team with emphasis given to the knock-on effect of such work.

Ensure that any tech debt issues affecting feature work are well-known among the wider team. Come to any discussions with details about the current level of tech debt, how it hinders feature work, and what the benefits of repaying that tech debt are. Expect detailed questions, and come prepared with examples.

Roadblocks within a team

Roadblocks within a team stem from a combination of fear, perfectionism and lack of trust.

1. We should be building features instead of refactoring

Reason for the roadblock

The belief that any time spent addressing tech debt won't directly benefit the end user.

How to overcome the roadblock

1. Reinforce that feature work and tech debt work should happen in parallel.
   1.1. No need for one to stop while the other is happening.
2. Discuss the benefits of tech debt repayments in the language of technical excellence.

Like any form of engineering work, a software project needs to be maintained, not just added to. A healthy team should have a mix of both tech debt and feature tasks being actively worked on at any given moment. Of course, a team member who is working on tech debt can't be working on feature work. However, the primary objective of tech debt work is to expedite feature development, so by investing effort today, a team makes the feature work of tomorrow easier.

2. We should only be refactoring this particular feature

Reason for the roadblock

The belief that paying back tech debt on any other feature is a waste of effort.

Of course, someone else feels the same way about a different feature.

How to overcome the roadblock

1. Create time-based team objectives and use those objectives to guide your tech debt work.
   1.1. Objectives act as constraints to allow for quicker dismissal of tech debt work that falls outside of the objectives.
   1.2. Allows tech debt work to be grouped and prioritised.
   1.3. Re-assess these objectives on a regular schedule, e.g. once a quarter.
2. Once tech debt work has been reduced via objectives, vote for which tech debt work should be picked up against multiple rounds.
   2.1. Each developer is given a limited number of votes, which they can spend on each tech debt work option.
   2.2. Tech debt work with the lowest votes is eliminated, and the developers who voted for it are given their votes back to spend on the remaining considerations.
   2.3. Once the remaining tech debt work estimates match the expected capacity, the voting ends.

By ensuring that everyone is involved in the decision-making process and understands it, you can significantly reduce pushback. While some may disagree with the outcome, unhappy team members can't deny that they had a say in what the team will be doing. Tech debt prioritisation isn't just about code - it's about trust. When people feel heard, they're more likely to support decisions they didn't choose. Therefore, the voting system is always great for overall team morale.

3. We can't refactor that feature because it works

Reason for the roadblock

The belief that reopening a stable feature is an unacceptable risk.

How to overcome the roadblock

1. Before changing functionality, ensure that the current feature is well understood.
   1.1. Share documentation on the functionality.
   1.2. Fill any unit test gaps.
2. Directly address the fear of regressions by speaking to risks and how those risks can be mitigated.

The fear of regression has prevented the banking sector from updating its systems, and now established banks are under threat from more nimble competitors who have modern tech stacks that can meet the expectations of their customers. In tech, we can't stand still, locking away functionality and saying "it's done" is a risky mindset in the long run.

Ask yourself and anyone raising this roadblock - would you prefer to refactor a feature when it is impacting your end users and your manager is demanding hourly progress updates, or when you can take your time with the work?

4. We can't refactor anything until we agree on the solution

Reason for the roadblock

The belief that to avoid creating future tech debt, we need to find the perfect solution.

How to overcome the roadblock

1. No solution is ever perfect.
   1.1. In tech debt, work that results in a "better" solution today is more important than a "perfect" solution tomorrow.
2. Just because work has been undertaken doesn't preclude future work.
   1.1. Breaking down work into small tasks is sensible change management.
3. Empower the developer who will do the tech debt work.

It's important in any team situation to seek an agreed-upon approach; however, we don't operate in environments without time pressures, so if there is a team capacity gap, it is often better to partially repay tech debt than to spend that time debating the perfect solution. Where a fully agreed-upon solution cannot be found, the developer who will actually undertake the work has the final say in which solution they implement. The caveat here is that autonomy is only used where the partial improvement is better than the current solution.

5. We don't have time for that

Reason for the roadblock

It's natural for teams under pressure to feel that working on tech debt is a waste of effort.

How to overcome the roadblock

Roads travelled

Tech debt is inevitable, but how we respond to it is a choice. Every unresolved ticket in the backlog isn't just a line of code waiting to be cleaned up - it's a reflection of how a team communicates, prioritises, and negotiates its identity.

By surfacing roadblocks and committing to repayment, we not only reduce technical friction but also reshape team culture. Each decision to confront tech debt is a decision to favour clarity over confusion, courage over avoidance, and collaboration over silos.

A healthy backlog isn't one that's empty but one that shows a team consistently facing its compromises and turning them into momentum.