I have a love/hate relationship with "technical debt". Having covered apps modernization, rationalization, and portfolio management at Forrester for more than a decade, I have a keen appreciation for the concept of technical debt – in all its permutations.

So I love the term for the sentiment it expresses about the need for change:

  • As we have modernized applications over the past 4 decades, we have "kicked the can" down the road far too many times – opting for expediant change over "refactoring to make it right"
  • Within any mature single app, technical debt spawned by years of compromise can accumulate to daunting levels
  • The debt eventually reaches the point of becoming a self-fulfilling prophecy – today's debt is too big to tackle, so we kick it down the road and watch it grow out of control
  • Across the entire apps portfolio, the accrued debt cripples firms by gobbling up huge percentages of the available business technology (BT) spend
  • As we rush to build out customer facing and mobile apps to address the age of the customer, the technical debt within the systems of record act like an anchor on change velocity – at both the app AND portfolio levels

And I hate the term because well-intentioned techies wield it like a bludgeon to pound business leaders with an urgency to act. But imagine for a moment how it sounds to business leaders, how they react to the term:

  • "If it's technical, then its your problem Mr App Dev leader, not mine – I'm a business leader"
  • "This debt you want to hand me … YOU created it, YOU made technology decisions – it's your problem, don't try to hand me a bill to clean up YOUR mess"

To borrow a line from the 1967 film Cool Hand Luke – "What we've got here is a failure to communicate." And the impasse is debilitating – both sides suffer from technical debt, we've simply come at the problem in the wrong way. In trying to convince business leaders of the need to act, we've led with "technology" and used terminology that is bereft of any indication of (perceived) business value / impact. Small wonder we get blank stares and outright rejection when we pitch proposals to slow down long enough to begin to shed the debt.

The problem isn't unique to the term "technical debt" – Agilistas repent!  You can either choose to speak to business leaders in their language OR teach them Japanese terms – "muda" for waste, "gemba" for walk-arounds, etc. You can explain that "fail fast" isn't REALLY a suicide pact between us and them, but actually means an experimental approach that really means "learn fast."

The solution to these issues isn't difficult – it comes down to avoiding jargon and talking to business leaders in a language they understand – I've addressed the "how" of it in two recent reports:

Fair warning – they sit behind the Forrester paywall. I hope they provide fresh insight about clear communication with business leaders, and solving the impasse that technical jargon often creates.