What tech debt does to velocity
Last week I thought about what happens to quality when a team starts moving faster. More changes can mean more bugs, especially while the team is adjusting. Leaving some slack in the sprint, making it clear who owns what, and getting feedback sooner all help the team recover.
I want to bring tech debt into that conversation because it often gets lumped in with bugs.
Say checkout applies the wrong discount. That's a bug. Now say the discount rules live in three places and you have to update all three every time marketing runs a promotion. That's tech debt. You can fix today's discount and still have the same work waiting for you next month.
When the shortcut is worth it
I've worked with good teams that carried plenty of tech debt by choice. Sometimes the simpler implementation gets you in front of users this week, and what you learn from them changes what you would have spent the next month building. I think that's a good trade.
I want the team to be able to explain why we took the shortcut, who owns it, and what would make us come back to it. That last part can be as simple as, "We'll consolidate the discount rules before we add a second kind of promotion." A few lines in a ticket are usually enough.
"We'll fix it later" is easy to say when everyone is looking at the release date. Six months later, somebody opens the code and has to figure out which parts were temporary and which parts are supposed to work that way. That's how accidental debt builds up. Eventually, a small change takes two days because nobody can tell what else it might break.
This is also on whoever leads the team. If saying "we took a shortcut to get this out" gets you blamed in a retro, people will keep those decisions to themselves. I'd rather have that conversation while everyone still remembers why we made the call.
What is it costing us now?
The way I think about interest on tech debt is how much extra work we do every time we touch it. An awkward config file that changes twice a year can probably wait. A deployment script that needs someone to babysit it on every release gets expensive pretty quickly. I'd start with the script.
I like how Etsy approached its move to TypeScript. It had more than 17,000 JavaScript files, and the team chose to migrate file by file, focusing on the parts of the site people were actively developing and the tools they used regularly. If you're trying to make day-to-day work easier, it makes sense to start where people spend their time. Etsy Engineering
When cleanup comes up in planning, I'd make the cost concrete. "We spend an hour doing this by hand on every release" gives engineering and product something they can weigh against the next feature. "This code is a mess" is a much harder conversation to have.
Leaving room in the sprint
The way I see it, this is a cycle. You pick up speed, bugs show up, and you use some of your capacity to fix them and deal with the tech debt that's making changes harder. When the sprint is already full, urgent bugs take whatever time is left. The work that could make the next release easier rolls over. After a few rounds of that, the same team needs more time to ship the same amount of work.
Google engineers have written about setting aside dedicated days and assigning teams to tackle build debt, including stale dependencies and dead code. That's one way to give recurring problems an owner and actual time on the calendar. Google Research
I'd leave some room in each sprint and use the retro to decide where to spend it. If deployments keep getting stuck on a manual step, automate it and see how the next few releases go. If the same test keeps holding up reviews, fix it and check whether reviews start moving faster. Over a quarter, I'd also look at how long it takes the team to recover when a release causes a problem.
At the next retro, I'd ask one question. What made the last release harder than it needed to be? Pick one thing that keeps coming up and give someone time to fix it in the next sprint.