Tech Debt Is a People Problem
18 March, 2021
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.
There are two things that could be done to fix tech debt:
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.
Director of Engineering at Motorway
Tejas Kokje, Senior Software Engineer at Netflix, Inc., highlights how long-term thinking, planning, and organizing can reduce technical debt in a product organization.
Senior Software Engineer at Netflix, Inc
For Today’s Q&A, we have Ron Pragides. Ron is currently the VP of Engineering at Trustly. Previously he was an engineering lead at Carta, AppDirect, BigCommerce, Twitter, and Salesforce, as well as an advisor to many startups. Welcome!
SVP Engineering at Trustly Group AB
Mary Fisher, Software Engineering Manager at DrChrono, shares how diligently she worked with teams within her organization to retain customers.
Software Engineering Manager at Curative
Ben Picolo, Engineering Manager at PolicyGenius Inc., shares how together with his team, they gamified the whole technical debt solving process.
null at PolicyGenius Inc.