More than just Technical Debt

I read @junedev post about resources for helping to address technical debt and it sparked a train of thought in my mind that I feel could be a useful way to frame the conversation around this topic.

For clarity, I’m coming more from the product owning, client facing, project managing perspective but as a caveat…the stereotypical interpretations of these roles is something I always feel can be challenged, and I feel it’s important to actively interrogate assumptions around the different role titles sitting within organisations.

I’ve not got a lot of actual blog posts/resources that address this issue directly, but perhaps I can relate your question to a similar issue I’ve personally experienced when working in other business contexts in the past.

One example I have and that I’ve seen close at hand, is from my dad’s work in HR over many years. His contention was that if you invest in getting the right team and culture as a core foundation, then the business would prosper (obviously this is a rather watered down version of things, but I think it scratches the itch adequately for now). And while many board rooms, team leads and general leadership will say this is true, the reality is that sticking to the process of developing a healthy team culture will often be the first thing to go out the window when things get challenging, and the business’ bottom line is threatened. Again, rather enormous generalisations being made…but I’m confident you can understand the sentiment.

Often, the short term gains (i.e. new contract, boost in sales, instant opportunity, reactive, stress-induced environment) will take precedence over the long term, values driven focus that I feel ultimately yields exponentially more fruit. The big caveat being, however, you have to be committed over the long term to establishing the foundation that will yield the fruit and this is where the rubber truly hits the road.

So what’s the way forward in a way that brings everyone along for the ride…

Here are a couple of ideas that might be of use and that I’ve witnessed have made an impact in making sure that an issue like “technical debt” is properly handled within the overall system…hopefully they help. I don’t think these are new ideas but hopefully they are nicely distilled and can serve as a frame of reference.

  • find ways to demonstrate the future impact of addressing the issue well. This is often gleaned by having multiple clear examples at hand where the issue was properly addressed, and the subsequent result of doing so. Working with actual examples of where addressing the technical debt saved time, money, effort might be useful. E.g. We spent 40 hours (at $50 per hour) fixing a codebase so that it was legible to anyone which meant that when the business needed a new developer, it only took them 10 hours to get familiar with the issue and saved us 3 weeks of money, time and stress. On the reverse side of that positive coin, an example might be…we ignored putting 40 hours of work into technical debt, and when we hired a new developer, they spent 120 hours (3 weeks!!) getting familiar with things before they could even look at the bug. You need to just spend a couple weeks mapping these scenarios within your actual system so that they have weight in the subsequent project meeting.

  • the leadership level is key. Aim for buy-in at the decision making level of the organisation. This is often very tough but that’s where the change needs to happen in order to stick. Having commitment across the whole team is so key and often under-rated. Clearly being able to articulate the impact of addressing technical debt as a core value is something that needs to be owned by the whole team. Not always that easy to do in our fast paced, get-it-done-at-all-costs level but having a champion for dealing with technical debt is essential!

  • be like super glue. Ever had superglue on your fingers and then everything you touch ends up getting stuck to your hand? Someone needs to maintain the over-arching commitment to the process of growing and developing in an area. It means consistently communicating, story-telling, exploring and re-enforcing the benefits of acting in a certain way. For change to be lasting, consistency in communicating and building a language that aligns with the values is so powerful.

  • set a framework at the start. I remember having a very fierce chemistry teacher when I was 11. He was scary! But, although he started out like a dragon, he was honest, gave clear boundaries and really cared. While I couldn’t see that he cared when I’d forgotten my homework one time, as time went on, his heart for us to learn increasingly shone through and he became my favourite teacher. You knew that his praise meant something. You could say he was ‘superficially’ a shock to the system, but inside, he was kind, genuine and caring. Even though he was the scariest thing on earth in our first introductory lesson (day one, new school year), by the end of the year, we’d learnt the most, had the most fun and as a class, pulled in the same direction and respected each other powerfully. Maybe the example is tenuous, but the principal is that you need to set the expectation very clearly, early on with how things are going to work. If that includes factoring in dealing with technical debt for a month within the team’s year. Set that expectation, and stick to it.

Hopefully that helps bring a wider lens to the issue of technical debt (and other big changes that take time to lock in)

Would love your thoughts and ideas around how we can clearly demonstrate that being driven by principal will always work out great in the long term!