Recently, Jason, one of Sema's founders, posted a thought-provoking article on technical debt. As he points out, technical debt is analogous to financial debt and software accrues technical debt when teams decide to defer all those “little” non-functional things.

The Sema team has spent the last year interviewing software development leaders in organizations of all types: Fortune 500 companies with decades of legacy code; start-ups who accrued tech debt as they moved quickly to grow their business; private equity-owned companies that acquire multiple new tech properties a year; and outsourced development shops who track every line of code written.

I used to have a trick when I was job hunting. The interviewers would drill me on all the hot problems in coding, and clever new techniques in data science and machine learning. Then when my turn came, I’d ask targeted questions about how they’re employing these a specific system.  As soon as I saw smirks, sidewise glances, and the word “well…” forming on someone’s lips, I knew I was in. It was my specialty:  bug squashing, refactoring, modernizing, and just wiping out tech debt with feel-good newness.

Tech debt was shrouding their dreams.  

Imagine a world in which your software development teams could double the time and energy they spend on creating new code. Double.

Think about how rapidly technology has advanced in the past few decades. And then consider—developers spend an average of 55% of their time on legacy software maintenance instead of creating new code. What could technologists accomplish if they could apply more of their brainpower to innovating and solving new problems instead?

Any programmer can tell you that refactoring is huge headache, but despite thousands of hours collaborating with development teams, I used to spend little time thinking about technical debt.  

As a long-time product leader – with more than 15 years serving over a dozen institutions working on countless products – I should have known better.