It is normal for a company to have periods of accruing technical debt, and usually necessary. Attempting to operate in a way that never adds any debt means making decisions too slowly, wasting effort in analysis steps, often producing solutions that are more complicated than eventually needed, and even those don’t solve the problem completely.
You have to come to terms with the fact that technical debt will always be around. Your job, then, is to manage that debt, both the rate that it is growing and whenever it is time to “pay back” some of it.
When it comes to accrual of debt, it is vital for it to be a conscious decision. Just as it would be irresponsible to take up any loan offer you get in the mail, your team shouldn’t be adding debt willy nilly. Anything relatively small as part of a development cycle is fine, as long as it’s already accounted for in the planning for the next milestones.
If your team seems to be gaining debt in a faster rate than you think is reasonable, it is crucial to understand the causes behind this. It might be because certain employees aren’t knowledgable enough in a specific area. It also might be because there are a lot of business unknowns, making it hard to decide on building the “Right Things.”
A very common cause, that is also a smell for deeper issues, is that the team is working in some sort of blitz mode. They are rushing to get things out the door, usually in order to meet a certain deadline. Yes, these are obviously going to happen, but if this is in fact your daily modus operandi then you are effectively grinding away at your team’s sensitivity to technical debt. Always working in war mode means you get used to seeing bad things. This is when debt piles on rapidly.
When it comes to managing debt, I’m a big believer in managing a budget, like you manage your team’s budget. Big technical debt, whenever it is decided to be taken on as described above, should be written down and collected. Having some sort of Jira/Trello bucket where the team can add these things to means that it’s visible. You should then decide on a strategy for making your regular payments.
Some teams successfully devote a certain chunk of their velocity each sprint into tech debt, making sure the pile never gets too big. As a big believer in slack (the management concept, not the chat app), I’ve seen first hand when autonomous developers have enough of it they tend to cut down on debt that’s bugging them.
And lastly, you should keep an eye on the size of your tech debt backlog. It should not be growing with time, but kept at a sane level. Track urgency and importance of your different “loans” and always be aware of the trends. Otherwise you risk going bankrupt!