Discussions between development and product management about technical debt are good and important, since not every technical debt needs to be paid directly. In fact, what is relevant and what is not is best determined in a joint discussion.

However, it is striking that even experienced developers have difficulties in communicating the benefit of reducing technical debt well. Product management often focuses on the costs without recognising the benefits, which naturally leads to a clearly defensive position.

So, how can developers communicate technical debt effectively? From our perspective, there are two key elements to consider:

1. Building mutual understanding and trust.

Trust is the basis for good collaboration within any (Scrum) team [1, 2]. If trust is missing, any collaboration is difficult and tough. So, how can you build trust?

First, it is important to understand the situation of the other person in detail [3]. Everyone wants to be heard and understood. For open communication, it is therefore essential to take the first step. Instead of directly trying to push one’s own ideas, it helps to first listen carefully to the other person’s position and to be really open to his or her point of view. This is the only way to jointly develop a solution that takes into account the concerns of both sides.

Next, you describe the problem and the benefit clearly and simply [3]. On this basis, you can then look for a solution together. The result will probably be somewhat different from what you originally had in mind. Nevertheless, it is a result that has been understood and accepted by both sides. This is extremely valuable, as it creates a common understanding and strengthens the relationship.

When doing so, it is helpful to start small. Especially when there is strong resistance, it is easier for both sides to keep the risk small. Small steps can help build trust, demonstrate the benefits of reducing technical debt, and ease fears and anxieties on both sides.

2. View technical debt as an investment and clearly illustrate the benefit of refactorings.

In some situations, the metaphor of technical debt can be quite hindering. While on the one hand it clarifies the additional costs of further development, on the other hand it complicates the value-based discussion. Therefore, it is even more important to describe the tackling of technical debt as an investment when communicating with product management.More specifically, this means clearly pointing out the benefit that eliminating technical debt brings and matching it with the estimate of the effort required for the refactoring. In other words, answering questions such as:

  1. Which of the planned features can be implemented more easily through the refactoring?
  2. Which features can then be implemented in the first place?
  3. How strongly will disturbing factors be reduced in the daily work?

All of these questions can be estimated and assigned a value for the company []. This creates a discussion about the value of the refactorings compared to other requirements, which can be used to prioritize it.

If, on the other hand, it is not possible or very difficult to quantify the benefit of a refactoring, the suspicion of a “golden faucet” seems likely. Just to make the code a little prettier or to give the architecture diagram a more appealing look, a major refactoring of the system is not worthwhile [4]. Software development is not an end in itself and it is necessary to keep the balance between further development and the reduction of technical debt (Three myths about technical debt).

A positive side effect of a value-based discussion about technical debt is that the refactorings that add the most value to the business automatically get the highest priority. In other words, when technical debt is dealt with, it is always the one with the greatest impact on day-to-day operations. Finally, delivering good and relevant results also builds trust over time.

Conclusion

A certain amount of tension between product management and development is absolutely normal and necessary. If the discussions are based on mutual respect and trust and focus on the common goal, it is possible to find the best way for the team and thus for the company.

References

[1]: The Five Dysfunctions of a Team: A Leadership Fable, Patrick M. Lencioni

[2]: The Speed of Trust: The One Thing that Changes Everything, Stephen M. R. Covey

[3]: The 7 Habits of Highly Effective People, Stephen M. R. Covey

[4]: Software Architektur TV - Folge 37: Technische Schulden, Eberhard Wolff

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