Tech debt can’t be solved as a roadmap item. It needs to be part of your daily routine

As an engineering leader, I’ve seen the following pattern play out multiple times, across multiple companies

1. Executives complain about engineering velocity not being high enough. “I just want to show the user’s birthday on the settings page. Why does that take a whole year?”
2. Engineers respond that tech debt is holding them back
3. Executives tell managers to work on “Tech Debt Improvements” in order to improve velocity
4. Managers go looking for big “Tech Debt Projects” to put on their roadmap
5. Ambitious engineer pitches a big shiny project that is fun to work on, looks great on the resume, and/or will get them promoted. “Let’s migrate to an Event Driven Architecture. And this time, we’ll do it Right™”
6. Manager loves it because it demonstrates impact, looks good on their resume, and shows that they are actively “Improving Eng Velocity”
7. Executives have no idea how the current system works, much less how the proposed event driven architecture would work. But they like it because it promises a solution to their biggest problem. “In the future, I’ll get all the features I’m asking for in a fraction of the time!”
8. Half the engineering team gets pulled in to work on the Big Tech Debt Project for the next few quarters. Minimal user-visible improvements are delivered in the meantime
9. One year later, the project is wrapped up. Everyone celebrates. People get promoted
10. Engineering velocity is now slightly better. But still bottle-necked by numerous other problems that have not been addressed
11. More tech debt starts piling up on the new system, as soon as the first feature request comes in

The trap that people keep falling into over and over again: assuming that “Tech Debt” is a single technical problem. And the best way to solve it is by putting an item on your roadmap, where you tell a few people to “go work on Tech Debt™ for the next month”.

The reality is that tech debt is death by a thousand paper cuts. It is things like:

• Flaky tests, which waste people’s time debugging imaginary problems, and slowing down your CI/CD deployments
  
• Coverage holes in your test suite, because of which people spend hours and hours manually testing all their changes
  
• Poor documentation, resulting in people taking 30 minutes to figure out who to do something which can be done in 1 minute
  
• 200-line functions and 3000-line classes with poorly named variables and functions, which makes it a nightmare for people to understand and work with
  
• Gnarly OOP hierarchies with too many abstractions and unexpected side-effects, which takes people an entire day to mentally untangle before they can make any changes

Yes, sometimes tech debt can be a single big problem… like having a fortran codebase, or using a text file as your primary data-store. Yes, in those instances, you need to solve it by having a big roadmap project to migrate your tech stack. But these examples are not representative of the most common forms of tech debt.

You cannot solve flaky tests and overly complicated code and poor documentation via a big roadmap item. There are simply too many little hurdles, too spread out across too many nooks and crannies. Trying to enumerate all of them, assign to DRIs, map to sprint-planning tickets or OKRs, track their completion… will take as much time as doing the work itself. What’s even worse: such a formalized top-down process won’t even succeed in identifying most of the problems out there.

The best way to fix these thousand speed bumps is through a bottom-up approach. One that permeates your team’s culture and way of operating, every single day.

• Encourage your developers to spend a little more time polishing their code, rather than simply rushing things out the door

• Create a PR-review culture where people pay close attention to things like complexity, readability, documentation, and testing

• Treat PR-reviews as an integral part of people’s responsibilities. Treat reviews as a way for more senior engineers to guide the developers in the team, and maintain technical excellence… and budget time for them accordingly. Don’t just pawn reviews off to junior engineers for a hasty stamp

• Encourage and empower everyone to fix the little problems they notice in their day-to-day life. Don’t bog these little things down in sprint-planning bureaucracy. People shouldn’t expect to create a JIRA ticket, and wait for it to be groomed and prioritized, just to add some documentation. “See something? Do something.”

• Tell your senior/staff engineers that their primary responsibility isn’t just to work on big shiny projects, but to enable and accelerate the entire team. That they should spend significant time every week identifying and fixing anything that is contributing to tech debt, or slowing down their teammates. Even if it’s mundane unglamorous stuff, like refactoring a complicated function, or filling in spotty documentation

• Acknowledge and reward your engineers for doing the little things on a day-to-day basis that lead to technical excellence and tech debt improvements. Acknowledge and reward your senior engineers when their leadership produces great team-outcomes… even if they haven’t personally delivered any big shiny projects themselves

A better metaphor for tech debt is oral health. Yes, you should go to the dentist every few quarters for a deep clean. Yes, you sometimes need to schedule a big dental surgery to get your wisdom tooth removed or to get a root canal done. But if you’re relying primarily on these appointments to maintain your oral health… you’re in big trouble.

The only way to keep your teeth and gums healthy is to incorporate oral hygiene into your daily routine and way of being. To brush your teeth every day, floss, and reduce your intake of sugary food and drinks. If you neglect oral hygiene in your day-to-day life, no quarterly dental appointment is going to solve your problems.