Let's Talk About Technical Debt

I started my career as an outside plant engineer. We in IT seem to think that “technical debt” is a new phenomenon. The legacy code and unpatched servers we fight on a daily basis is not far away from a telephone central office featuring hundreds of busted pedestals, rotting cables full of water, and equipment cabinets full of failed batteries. I suspect that most industries feature some version of “technical debt”. As a young engineer, it was obvious and not entirely intuitive why some areas of the country featured relatively clean outside plant while other areas were a mess. Sure, some areas benefited from an upgrade program or some maintenance effort that drove their one-time improvement. But some very quiet and unappreciated areas of the country thrived. What I came to discover was that some areas of the country had a guardian angel. They benefit from the fact that someone cared. Someone (and usually a small team) made the effort and found the time and money to catch up and then keep up on maintenance. They didn’t have any different leadership demands. They didn’t have any less work – they maximized their resources and teams. They advocated for their area. They got a little bit of leeway from their leadership because they were passionate about their territory. We in IT can take a page from this playbook make the time and make the argument. Business partners and IT leadership need to give these efforts a little grace. 

I always found the best outside plant planning engineers to be amazing repositories of knowledge. With the best of them, I could come to them with a problem and before I finished asking my question they could reach into their drawer and pull out a plan, drawn years ago, as to how this issue should be resolved. They kept these plans – dreams unfulfilled - because they advocated for doing it right any chance they could find! They knew that a pit dug for some project on that cable was maybe a one-chance opportunity to make a broader improvement.    

So too, we can have our plan ready to “pull out of the drawer” as technologists. We can become advocates for our codebase. This requires skills that we should all be looking to hone. First, as technologies we need to be the expert in the system we support. If you ever find yourself saying – I don’t know that code, you are in a position to fix that. Take some time and get into your business. We may not have a current need – but an evening or a weekend of deep work and you’ll learn something you can put in the drawer with a guarantee it’s going to come up in the future!

Such advocacy also takes a skill that is sometimes in short supply in IT – storytelling. Often, we need to work with our business partners and leaders to tell the story of the future. A future we can build for a little bit of time to take some bits of the elephant. I’m super proud of our customer portal team at Brinks Home led by Jeff Lindsey and product owner Stephanie Griffin . About this time last year, we were declaring some major bets on the portal both in terms of an increase in functionality and an integration of functions into our app. Jeff was an excellent leader in the team’s effort. He proposed a plan to rebuild the portal first with the new features and then the legacy features moving away from our long-deprecated DXP. Did leadership think about the implications of going a bit slower to take on this risk – you bet. But Jeff’s passion and intention were persuasive! I’m pleased to report that not only did Brink Home have 66% growth in digital interactions but in January we shut down the legacy environment for good.

One final comment on this topic. Our business partners and IT leaders have a role to play. First, we need to open our ears to our teams. We very well might need to say, “I hear you but we just can’t right now”. But we should always be willing to listen. Sometimes we need to find a way to just say, “ok”. Some organizations have a policy that all work needs to be introduced to the PO from the business perspective. I challenge that method as contrary to best scrum practices. The PO needs to be open to intake for IT initiatives. There are no secrets on a scrum team, and everything gets prioritized in one list. Good leaders make room for the critical non-urgent things that we should all care to have in focus.

None of this is easy. At the team level, it’s easy to just focus on the orders and knock out the business ask. At the leadership level, well same. Sometimes it’s just easier to focus on the orders and knock out the business ask. But a tenacious focus on technical debt changes a team. It creates pride in a body of work that leads to continuous quality. It creates trust. Ultimately it creates velocity.

So what is your experience with technical debt? Do you have a story of technical debt eliminated?