An experienced and well-established team with a high level of trust and mutual respect from development and product management, as well as the necessary seniority and experience, can certainly do this. However, many - if not most - teams are not at that level.

There is a lack of seniority and experience. Individual developers feel they are not allowed to refactor. Everything is so urgent that refactoring issues just keep falling to the back of the list. The wrong issues are addressed. Refactorings simply don’t improve code quality. The technical debt is just too big for a single team. The complexity of the task is overwhelming.

The list of why a team may not be able to handle technical debt on its own could easily be extended.

In such situations, relying solely on a team’ s sense of responsibility is fatal.

Here, the technical management must be aware of its responsibilities. It must drive the reduction of technical debt itself and create the necessary space for the team.

So what exactly does that mean?

  • Setting a clear technical direction. Only when the destination is well-known can you strive towards it in your day-to-day work. In other words, it must be clear to everyone where the system is supposed to evolve, what good solutions to recurring problems look like, and where what is to be implemented. The clearer the technical direction, the better a team can follow it. The technical direction can come from the team itself, or it can be set externally, e.g., by the technical management or an architect.

  • Encourage and support teams. Urgent is whatever has two legs and is standing in the door. Especially when a team has a dominant product owner with a really compelling vision, it can happen that the team gives in to the pressure and - instead of finding a balance between the further development and maintenance of the code - only implements new features as quickly as possible.

In such a situation it is important to help the team to find a voice. The entire team (including product management) needs to become aware of existing technical debt. To make this work, a team needs usually outside support. This can be a Scrum Master, experienced developers from other teams or technical management itself.

  • Mentoring / coaching of junior team members. To reduce technical debt, especially with systems that have evolved over many years, it takes experience, patience, and a little courage. On the one hand, not every refactoring is necessarily an improvement per se, on the other hand, you have to know the system well enough to be able to assess all (or at least most) of its dependencies. Last but not least, refactoring is an activity that requires certain skills that simply have to be practiced. Pair programming, code reviews or simply thinking through a refactoring as a team can help inexperienced colleagues to get familiar with the system and to build experience faster.

  • Learning to delegate. In many cases, complex refactorings depend on individual, experienced employees. These can quickly become a bottleneck for the entire company. It is therefore crucial to delegate also more complex issues. This is easier said than done. Especially when a person knows a system very well, it is very difficult to hand over responsibility to less experienced colleagues. Especially if in the beginning the effort of the handover is greater than to do the task quickly by oneself. It is important to be aware that it is not about getting the job done quickly. Rather, it is about training less experienced developers to be able to perform more complex refactorings themselves in the future.

  • If the technical debt is too high, it might make sense to appoint technical product managers who give the topics the necessary urgency and represent them to senior management in the same way as the business topics. This not only creates a better overview of the existing issues, but also makes it possible to prioritize the topics in a meaningful way and thus tackle the most relevant refactorings first.

Especially in long-living systems, technical dept and is omnipresent. The challenge is not only to continuously reduce technical debt while maintaining a balance with ongoing product development, but also to identify the most relevant debt at any given time and to work on exactly that debt. Of course, this is far from easy. But what is the alternative?

Webinar: Scaling software development as a SaaS company without becoming consumed in the growth process.

The webinar addressed exactly the pain points that are occurring as we grow. With an ever-increasing number of employees on the Dev & Product team, we've had to find out for ourselves how difficult it is to set up a sensible structure that brings out the maximum efficiency and performance in everyone, while also leading to a healthy working atmosphere.
Pascal von Briel, Co-Founder & CPO @ exporto GmbH