Peter Bell wrote an interesting blog entry on Avoiding Innovation Debt. What he is calling Innovation Debt is the stagnation that follows long periods of failing to invest in the technical skills of engineers.
Innovation debt is the cost that companies incur when they don’t invest in their developers. It happens when the team is too busy putting out fires and finishing up features to keep up to date with advances in languages, frameworks, libraries, tools and processes.
I love the attention he direct to the issue, but I think there’s got to be a better name than Innovation Debt – perhaps Skills Gap, Skills Depreciation, Capability Debt or somesuch. Frameworks, libraries, tools and processes – these impact the ability to execute on innovation – but I immediately associated the term Innovation Debt with something else: the stagnation that occurs when companies are focused on executing on existing products, and are failing to feed the front end of the innovation pipeline.
On Innovation Debt (as I see it)
When a company doesn’t engage in lightweight product discovery early enough, the result is real innovation debt. The pipeline of innovation is stalled, because there’s not enough fresh air at the intake. This requires the company to invest in the early phases of innovation, namely product discovery or customer discovery.
Tragically, when a company finds itself with Innovation Debt and various stakeholders are calling for a detailed Product Roadmap, or the engineers finish up their current project, and there is a need to feed the beast, then there is a big risk that proper product management principles will be thrown out the window, and the highest-paid-person’s opinion (aka HIPPO) will determine the next product or features that are built. A recipe for failed products.
On Capability Debt
Peter Bell nicely describes some of the consequences of incurring capability debt in a technical team: missing out on productivity increases, decreased employee motivation and job satisfaction.
He also lists some excellent suggestions to make sure capability debt doesn’t build up: encourage lunch & learns, send developers to conferences, host hackathons, bring in consultants / experts, pair programming, etc.
I also couldn’t agree more with his conclusion:
[Capability Debt] is a real risk for any company that needs to hire and retain a software development team. Of course, there will always be times where you can’t justify the time to learn new technologies for a month or two, but realize that what you are doing in those periods is accruing innovation debt. Have a plan for paying down the debt in the following quarter and follow it, otherwise you’re likely to become an increasingly less attractive place to work with technology that is getting further and further behind that employed by your competition.