We talk a lot about technical debt – the idea that a software team will slap together some brittle code in order to shorten their time-to-market.

Software professionals are largely split on the value of technical debt and how to approach it. I've heard everything from:

➡️ "It's never OK to take on technical debt."

➡️ "Technical debt doesn't exist. Any code you write is in service of the business, so it can never count as a bad thing."

➡️ "It's fine so long as you 'pay down' that debt by later going back to replace the brittle code with something more robust and supportable."

➡️ "It would be OK except that I know that the CEO will never give me the chance to pay it down. Because of that, it's never OK."

What if we were to instead call it technical leverage ?

In trading, leverage is money you borrow in order to amplify the payoff from an idea. If you think your latest trading strategy will go gangbusters, you "lever up" in order to multiply your gains if you're right.

The catch? Leverage will also multiply your losses if you are wrong. So you first do your homework to make sure that the trade is worth it. Sometimes there's just too much risk and you skip the leverage.

This is when you'll point out that leverage is another form of debt. Indeed it is! Leverage is debt with a specific, calculated, researched gain in mind.

If you frame your next matter of technical debt as technical leverage, you're in a better frame of mind to think about the payoff:

"Do we expect that this move will drive revenue (or impress investors, or …)? Or is this being pushed by someone who is in a hurry, and they're not thinking about the longer term?" And you can act accordingly.

(Big thanks to John Riccardi for this one. We were talking about technical debt when the term "technical leverage" came to me. He suggested I write this down and share the idea …)