Member-only story
The 7 Struggles of a Tech Debt Management Team
It’s the most crucial team for building scalable software
In the real world, there is no tech debt management team, a team that is dedicated to fixing and addressing tech debt. No one would like to be in such a team. It is a team that is cleaning up other developers’ messes. Who likes to be in that?
However, we do have teams that are named more professionally, e.g., infrastructure team, architecture team, core team, etc. — at a glance, glamorous names. The team is responsible for working on the core body of the application used, as shown in the example of a core coordinator / dependencies group in the diagram below.
Note: You can find a deeper dive into why such a group is required for the scalability of software (mobile) development in this article.
If we think back to day one of development, there’s no need for any core team since there’s only one team that does everything. However, over time, the team grows. We now need to partition the work better, where some teams are responsible for feature delivery and some teams are responsible for the common code, as shown below.
The team that owns the common code is then responsible to explore code across the feature teams to be refactored, improved, and better aligned, for the sake of maintainability and scalability. The work essentially is like managing tech debt. Hence it is not really a misnomer to call that group the tech debt management group.
Anyway, the focus of this article is not to define the name for the group — you may name it core, infrastructure, or architecture — but to lay out the struggles of such a group and explore ways to aid it.
Following on in this article, I will use the names core group, infrastructure group, and architecture group interchangeably to describe the struggle of such a group.
