People Deal with Technical Debt in Some Really Strange Ways

There are plenty of articles out there on how to handle and manage technical debt. It’s pretty common to acknowledge that it’s difficult to understand the value of resolving technical debt. 

There’s a pernicious perception that tech debt isn’t valuable to the business directly. This hasn’t gone away. And in my experience both business teams and technical teams are bad at understanding the tradeoffs and at comparing relative value. This has led to some really odd solutions.

Strange Solution #1: Hide or Bury Tech Debt in our Effort Estimations.

So… your engineers know a solution is non optimal - they think changes need to be made to support or sustain the system. Rather than trusting everyone with that knowledge and having a conversation, they’ve chosen to bury it in the effort estimations for other work. Perhaps they did this because these conversations weren’t respected in the past. Regardless, it’s an indication there’s a problem with trust and prioritization.

Strange Solution #2: Give Engineers Free Time and Let them deal with it.

Basically invest in your engineers solving tech debt in the time they are supposed to be doing personal development work. But because engineers are so keen on getting things right and perfect and what not, we simply expect them to keep optimizing the systems and they get to feel good about it. In this case, we’re ignoring the problem and appropriating an engineer’s stress response to non optimal solutions to get them to solve problems effectively after-hours. 

Strange Solution #3: Negotiated Allocations.

Either complete enablement sprints, or as a percentage of work within each sprint, some teams will dedicate time to tech debt repayment. Regardless of how valuable that tech debt is, we’re going to pay it down. These teams often track and measure some concept of technical debt - or even have tools that do it with terms like “code smells” and “code coverage” used to measure it. 

Strange Solution #4: Simply Negotiate.

Basically - come to the occasional casual agreement between business and tech to invest in tech debt repayment to keep Engineers Happy. You will find that Engineers are treated like children who may throw a tantrum at any time if they don’t get their way. So you’ll have to simply schedule some of their tasks into the backlog to keep them happy. Children! Ugh!

Let’s not do those

Each of those solutions has some serious flaws even when they seem like your best option. Sometimes you simply can’t get through the trust issues, sometimes you don’t deal with rational decision makers, and sometimes you simply misunderstand the purpose of the work sufficiently. 

Instead

Trust your business counterparts to discuss the relative tradeoffs of investing in technical improvements. 

Engineers should spend their personal development time actually getting better, so that investment can pay dividends later.

Teams should build a solution to the actual problem… and not the perfect, infallible solution to a problem they imagined was asked.

Teams should actually prioritize work, rather than assigning static allocations or negotiated concessions to keep engineers from revolting - or throwing a fit - or whatever condescending term you’ve read about.

Do: Trust your teammates.

Don’t: Build in systems of distrust.

Do: Have honest, thorough conversations about the value of technical debt.

Don’t: Try to brush it under the rug or set up systems to remain blissfully ignorant.