Summary: To pay down technical debt, make a rotating team of devs who do two week stints. The team should be facilitated by a consistent lead dev. This allows for larger and smaller initiatives to be completed over time.

A few weeks ago was my first time on the Technical Improvement team (due to an usual set of circumstances), and I thought it was worth mentioning that it felt like it worked really well for reducing technical debt.

There are typically three developers on the TI team. The number can change depending on the percent of time the company wants to dedicate to TI.

These devs are taken out of their normal team entirely, so no stand ups or other ceremonies (though I did attend my team social – we were doing personal pecha kuchas!). I was on the team for two weeks, but if my particular TI project lasted longer I would have been welcome to continue.

Another important note is that the stints don’t all start at the same time. There will always be at least one dev who was in the previous “sprint” who can help with carrying over context.

There’s also the senior developer who manages the backlog and runs the weekly kickoffs. Theirs is a fairly permanent position, though they may be doing work on their own team. Their role is to make sure the right stuff is being worked on and making sure there’s enough work for new comers to pick up straight away. The rotation of devs is a huge help for planning too. They’re often the ones who bring suggestions or complaints about frustrating areas to work in.

Ultimately, what comes from this is a team focused on an arc of improvement work for the whole year. Something that’s impossible in a normal team where product and other kinds of work need to be contended with. Upgrade plans can be made and largely kept to. The team can even have OKRs and a spot in product demos.

The ticket I was working on (for an upsettingly long time, maybe another post to come on this) was the Haml 6 upgrade. It took longer because I was nervous about the backwards incompatible upgrade that affected literally every user facing page. The TI team gave me the freedom to spend the time on it to be sure it was safe to release. If I was working on this ticket in my normal team, I’d be fully aware of the “Add critical new feature” ticket that was just behind it in the backlog, waiting. Leaving me with a niggling thought of maybe this second round of testing isn’t important enough.

This only works on a team with enough developers. I imagine smaller teams, without enough devs to spin off another team, will have to continual to juggle priorities in a similar way.

Lemme know how you handle your tech debt over on mastodon.