Peter Bell

By now, most people have heard of Technical Debt; the cost of messy code that grows over time, like interest on an overdue loan. For the last couple of years I’ve been talking at No Fluff Just Stuff conferences about the concept of “Innovation Debt”. I’ve been planning to blog about this for a while. Thanks to Aaron Frost for persuading me to finally write up the post.

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. Just as technical debt can kill a code base by turning a green field project into a big ball of mud, innovation debt can kill an engineering team – moving them from a cutting edge crew to a group that’s barely competent to maintain a legacy app. In this post I’ll summarize some of the potential cost of innovation debt and some of the simple steps you can take to ensure your development team doesn’t incur an unsustainable amount.

The costs of innovation debt

• You’ll lose your best developers – If, over a period of months, you don’t create any slack for your development team, they’re not going to have the time to learn anything new. The best developers are going to see this and leave. The worst are going to hang around because they don’t really care that much about learning and might be worried that they couldn’t get a better job elsewhere. Because of this, over the course of a year or two, the average quality of your dev team is going to drop. And because great developers are mainly attracted by the chance to work with other great developers, if you’re not careful this alone will create a death spiral where the quality of your team keeps edging downwards until no great developer would consider joining the team.
• Recruiting will get harder – With top developers leaving and with a lack of “shiny” things to play with, it’s going to become increasingly hard to hire great new developers for your team.
• Productivity won’t improve – Many new technologies are designed specifically to make developers more productive. If your team aren’t learning any of the new technologies, they won’t be bringing the productivity gains to your business.
• Your software will get stale – Over time, users expectations increase. Whether it’s integrating OAuth into enterprise software to authorize via LinkedIn, using a responsive/mobile first design for your web applications or delivering a mobile application for your users, unless your team is experimenting with new technologies, they won’t have the skills you need to keep your software competitive with the rest of the industry. 

While innovation debt is incurred incrementally, teams will sometimes hit a wall with a particular project where the cost of the innovation debt can potentially cause a project to fail. I remember a “bet the company” project I was involved with a number of years ago. The dev team hadn’t had time to learn new technologies for a number of years and the new project required them to learn a new version control system, build system, test framework, project management tool, and web application development framework. Any one of those changes might have been manageable, but unsurprisingly with so many new technologies to learn, the project took much longer than expected and nearly put the company out of business.

Avoiding innovation debt

Lots of companies talk about a “culture of learning”. There are plenty of ways of actually creating one. Some ideas include:

• Lunch and learns – Ask one team member every month to take a morning and hack on something interesting (maybe a new javascript library or to try out a new version control system) and ask them to give a presentation to the rest of the team (or write a blog post if they don’t like to present). It’ll give everyone a chance to hack on something new every few months and will create a sense of shared learning within the team.
• Conferences – Make sure all developers hit one local conference a year and ideally send them to at least one conference a year that’s out of town. It’s a great way to learn about new technologies, but it’s an even better way to build a network with other developers who might be able to help with technical issues in the future.
• Hackathons – Take a couple of days once or twice a year to allow your teams to hack on passion projects that support the company’s goals. Encourage them to create mockups using new technologies so they can get some hands on experience with technologies that might become important to the company over time.
• Continuous consulting – Most teams I’ve met would be well served by putting aside 3-5% of their annual budget aside for ongoing consulting. Bring in a consultant for a few days once a quarter to help your dev team to learn something new on a regular basis.
• Pair programming – Pairing can be a great way to increase the sharing of knowledge within your dev team, but you do still need to invest in other activities to make sure your team are still learning from external sources and have new ideas to share.
• Allow failure – The goal of trying a new technology is not to use the technology. It’s to learn whether the technology might be worth using. If you never try a technology that ends up not being worth using for your projects, you’re probably not trying new technologies aggressively enough.

Another approach that I’ve found very successful is to use new technologies that have the capacity to improve your core business but to test them on low risk projects. If you think that your core matching algorithm might work better in Clojure but don’t want to bet your entire company on a technology you’ve never deployed, rebuild your email delivery system or write a bug tracker in the language. Then once you have in-house experience with developing and running it in production, you can decide whether or not to rewrite a more critical part of your infrastructure using the technology.

Innovation 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.