Innovation Debt

If you work with software engineers you likely hear the phrase “technical debt” regularly.* This is a painful reality for active projects, but just as painful is something you won’t hear discussed: Innovation Debt. We incur this debt from failing to innovate and renovate ourselves and our products. While the pain from this kind of debt isn’t felt as quickly, when the bill comes due it may be more expensive than a firm can bear.

In most companies only the executives think or talk about the need for innovation, while those with the most potential to innovate are pushed to do the job as quickly as possible and then to move on to the next challenge (and complete that as quickly as possible too). Without room to try new things and to at least occasionally to fail while doing so, people will only implement what is safe. In the short run this will lead to successful projects which are on-time and deliver as expected. Even in the medium-term all will appear to be working smoothly on the surface. Unfortunately if your firm is only doing what it has done before, your competitors are surpassing you and any leadership you may have had in the field is being eroded. Also, when you try to shake off the cobwebs and innovate you will find your team has a reduced ability from lack of practice.

In order to maintain an innovative edge, you cannot simple declare a couple random days ‘innovation days’ or tell people to use 20% of their time on their own projects (while the 80% takes overtime just to complete) – you must make your environment one where on a daily basis people are encouraged to challenge the status quo, where new ideas are rewarded, and where failure isn’t fatal. Failure to prioritize innovation will lead to a slow stagnation, loss of any leadership position, and eventually a need to completely revitalize your entire product line and possibly your image in the marketplace as well – not an easy proposition.


* Technical debt is a nice term to describe decisions made in the past which were known to have future costs and which could have been avoided, but weren’t – leading to reworking those things in the future. Note I didn’t say mistakes made in the past. To qualify as technical debt, we had to have made the decision consciously – not realized later it was a bad idea.

Leave a Comment

Filed under Management, Revolution, Software Development, Strategy

Leave a Reply

Your email address will not be published. Required fields are marked *