Avoiding Innovation Debt

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

Wait! Before you go…

Peter Bell is an evangelist/hacker at hackNY, trainer for Github and co-founder of CTO school. He presents regularly at conferences like DLD Conf, QCon, Ruby Nation, UberConf, and the No Fluff Just Stuff enterprise Java tour. He’s been published in IEEE software, Dr Dobbs and Information Week and is writing a book on managing software development for Pearson publishing. He tweets at @PeterBell and blogs at https://blog.pbell.com.

No comments

Great understanding Peter. But the same can be said about all western economies where they do not invest enough by far into creative thinking and the infrastructures that are needed to underpin new ideas. I have travelled the world on quite a wide scale and advised governments on developing their economies, mostly in the East. But every time, you come up against a senior bureaucrat (usually equivalent to a permanent government secretary) that has not a clue what innovation or creativity is all about and where they are usually a pen pusher working from 9>5. You try and explain to them what innovation can do and they nod their heads, but in reality they have not a clue what you are telling them. The same goes for industrial leaders as well I have found who have not a clue although they will say that they do. Once the door is closed they forget everything you have advised them, because again they simply do not in truth understand.

Therefore I have found that the greatest stumbling block for nations and corporations being successful in the ‘main’ is that they have the wrong people running the show. But how do we change all this is the big problem as usually those running the show are in positions that their fathers held and therefore no change happens generation after generation. This I have found is in the majority of cases but where I know that there are few politico or corporate leaders that do understand that innovation and creativity are the golden keys to all future success. Unfortunately based on my knowledge, western nations and corporations are only run by people who are really in the know in the ratio of 1 in 350 based upon statistical analysis at the most. I say this as most who say that they understand do not as time determines this after the advice has been given. But I have to say that this does not just go for me but also for other advisers (some very senior external industrial/technological advisers) that I know from the EU et al and where they tell me the very same and come across the same old stumbling block that those who are in charge just basically do not understand, but possibly in many ways don’t want to know – the mentality of the ‘steady state’ and do not rock the boat philosophy. But how do we change this situation as nothing ever happens thereafter?

I love the points you make about the costs of incurring this debt, and the ways to avoid it. As I commented on my blog in response to your post (https://brendansterne.tumblr.com/post/46175740465/avoiding-innovation-debt) I would suggest a different name for this than Innovation Debt (perhaps Capability Debt), because the term Innovation Debt, to me, means something distinct and also important to address.

It seems to me that two related but distinct but different problems and their solutions are bing lumped into one: not investing in your product and not investing in your people. Yes, you can only improve your product by getting your people to implement new tools. But maybe the way you do that is to ask people to investigate what new tools they might implement. Perhaps they’ll decide they need a conference, and a lunch and learn or perhaps they’ll just do some googling. In any case, improvements to the product will be made here and there and people will learn things. Whereas if you’re putting in place a policy of conferences and lunch and learns, your product may benefit, or it may not.