Tech Debt Is a People Problem

Problem

Tech debt is like rust in a machine that is growing over time and impacts performance. It is hard to solve it for multiple reasons. First off, tech debt is hard to measure, and when something is hard to measure, it is also hard to plan, set goals around and take action. Second, tech debt is somewhat like global warming; everyone contributes to it, but it is hard to tell who is responsible for what. Everyone agrees it should be fixed, but no one wants to fix it. Moreover, Individual incentives are, in most cases, not aligned with global incentives due to a lack of clarity on ownership.

Actions taken

There are two things that could be done to fix tech debt:

Evangelize

Start by explaining to people how severe the problem is and how it could sink the entire ship if they don’t solve it. Your evangelization should raise awareness and motivate people so that you are able to allocate volunteer resources to solve it.

Every two weeks, we have Typescript Conversion parties --- a meeting to fix a specific type of tech debt by annotating JavaScript code with types --- run entirely on a volunteer basis and without any pressure on people to join. However, people who would voluntarily come to fix tech debt would be pampered with food, drinks, and an inspiring environment. Our parties continued for a year, and we managed to fix around 40 percent of tech debt in the targeted system.

Clear ownership

What we had to do next was to clarify ownership. We spent a lot of time drawing boundaries between the teams since it is much easier to solve tech debt once you contain it within a team. If there were no boundaries, teams wouldn’t know how much debt they own and thus wouldn’t know what they would have to solve. In general, having clear boundaries is a prerequisite for solving most problems, and as an organization grows, the evolution of boundaries becomes increasingly important. The boundaries should be aligned between the business, people, and system. Team boundaries are demarcated by an organization chart, while the system boundaries are embedded in code; to draw boundaries, we need to put the code into different slots and have impermeable boundaries around them that can’t be easily crossed. Rather than having people constantly looking at the boundaries, the process should be automated.

Most of what I described above is still an ongoing project in my organization. Tackling tech debt is a slow-moving process, and we expect it will take two or three years to be completed. Perhaps, we could have started the whole process earlier; the more engineers are working on the system, the harder it is to fix tech debt. The same way people think about their system security from day one, they should be thinking about tech debt from day one. Many startups tend to accumulate a lot of tech debt as they move very fast for the first couple of years, and only after a while do they start to think about tech debt. Probably the better approach would be to occasionally look at tech debt and see if something could be fixed along the way.

Lessons learned

• I believe that most technical problems are -- to some extent, at least -- people’s problems. While occasionally you can encounter a problem that is on a more profound level technical, some of its components are always about people. Failing to grasp the people aspect of the problem while focusing only on the technical side of it is like looking at a picture with one instead of two eyes.
• Communicate why fixing tech debt is essential. Use any opportunity to talk about it, from the Engineering All-Hands to Slack channels. Also, give public kudos to people fixing tech debt. I would send a public Thank you to whoever comes to biweekly TypeScript Conversion parties. Cultivating a culture around fixing tech debt is immensely important, and it will ensure a lasting sustainable solution.
• Ownership boundaries are critical, not only for solving tech debt but also for solving most of the engineering problems. Who owns what should be crystal clear to all the people on the team.