Defining your tech debt is the first step to escaping it
Every company has its own ways of communicating, problem sorting and getting people together. It’s even different from department to department.
At 11:FS, we run an all-engineers meeting every two weeks. Voluntary attendance, cosy and yes, sometimes chatty.
Tech is too important to sort by yourself. So we sometimes use this slot in the calendar to whine about our hurdles and hope that collective experience will sort it out.
All of my mates in this meeting are familiar with the term ‘tech debt’ and how we got here. Nick Funnell has written about it extensively. The topic comes up often. We’re guilty of trying to find solutions, and as we apply them we learn more and we want to improve a little more.
Any company with a tech component - are there any left without one? - is the unproud owner of tech debt. It’s one of those phrases that gets thrown around a lot. It’s everywhere I go. It’s also one that can mean anything.
When companies and teams are asked what their tech debt is, they often struggle to articulate it. It means different things for different people because it’s a catch-all phrase. It includes every library not updated on time, every incomplete feature and every design inconsistency.
When companies and teams are asked what their tech debt is, they often struggle to articulate it.
Are they all tech debts? There are many types out there but the important thing is to define your debt, not to categorise it. For a team to be able to commit to a certain roadmap, they need to know what needs to be resolved and when. These debts are like financial debt. You need to know your current and future outgoings in order to properly plan and ensure your financial stability.
Captain Obvious says the best way to deal with debt is to prevent it as much as possible. We all tried different things for this and some were successful. Howard approached this by deleting any task not tackled in a few months. Not on an automatic schedule, but after a ‘purge’ session where tasks are assessed.
Captain Even More Obvious says that most companies are already past the point of prevention and at the point where they need to play it down. The 11:FS Foundry approach to a small backlog is a good option, because it leaves fewer tasks to be negotiated with delivery in terms of time. As Martin calls it, the success of a tech team hinges on the tech lead articulating that these tasks need to be done in front of product and delivery, to get the buy-in. While leads don’t have to be pushy about it, they need to make the decision to invest time in something.
And while we’re at it, calling it tech debt does no one any favours. As Lee pointed out, calling it quality of services is transformational. It doesn’t suggest a developer cut a corner and that’s why we are where we are. It turns a negative feeling into a positive outlook on things. It makes it easier to get buy-in from the product and delivery team.
The thing is, you can’t avoid the debt and nor should you. If you always do what you need to when you need to and are never late, it means you’re not stretching yourself. And that is a sad life.
The thing is, you can’t avoid the debt and nor should you.
On the other hand you don’t want to let it loose. According to Stripe, developers spend over 17 hours a week on this subject. This wastes companies worldwide nearly $300bn in lost productivity every year. That’s a big number!
Tech debt needs to be known, defined and rigorously actioned upon by all team members and stakeholders, in a way that best fits that team. You can take inspiration from here and there, but it’s your responsibility to mash it into something that works for you.
