Innovation debt
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.
Peter Bell 
Great post! It’s almost as if you were working with me at a former employer…
Ben Burton (@bjburton)
March 19, 2013 at 6:39 pm
Uh! I keep discussing in these lines with my colleagues over coffee. Good to find a structured thinking around it. As an option to avoid debt, what do you think impact of platform when it comes to experimentation. I feel experimentation on same platform again and again hardly pays any dividends. Frustration creeps in when it is only yielding incremental innovation. Such experimentation leads to drop in motivation levels.
Sriharsha Vardhan (@sriharshav)
March 19, 2013 at 9:46 pm
Peter, as always, very insightful. I don’t often think about things like this. Typically, my thought process is, “I love programming… but do I love it TODAY?” And, if the answer is “No” a little too often, I know something is wrong. But, it’s hard for me to hone in on what may be wrong, specifically. A lot of what you say here hits home.
Ben Nadel
March 20, 2013 at 9:00 am
I think you nailed it. That’s a part of why I left my last job: two years stuck on the same product, which had a big technical debt already, on technology going more and more outdated, no rewrite planned, no training. Was the same for other product/devops teams.
They finally lost several engineers at once because of that (and some other issues, but things are linked).
fennnaten
March 20, 2013 at 10:24 am
Finally someone put this “on paper” so I can forward it to our managers.
While reading first half I was like “OMG, this is my project and team he’s describing!”.
Luckily, second half removed possible suicidal ideas. So overall great balance, good definitions and great suggestions.
Zarko Susnjar (@zarkosusnjar)
March 21, 2013 at 4:56 am
Unfortunately your description of innovation debt is not correct although it is a description of something else. Innovation debt has already been coined by James Gardner who wrote “Sidestep and Twist” which describes innovation debt. See his article on this from two years ago: http://innovatorinside.com/2011/08/09/the-technical-innovation-debt/
What you describe is another form of technical debt. Innovatiion debt is the price you pay for innovating and blazing new trails. Those that follow don’t have to pay that price.
Steven Olson
March 21, 2013 at 11:22 am
Hi Steve, Thanks for highlighting the link to James’ work. I was unfamiliar with it, and have been talking about this for a couple of years, so I guess for the moment we just have semantic conflict on the term. No doubt the market will clear up that in due time.
peterbell
March 21, 2013 at 11:54 am
I like your article, but what you are describing is part of technical debt. You are describing the debt incurred by not keeping up with technology. Staying on Java Servlets when you should have moved on to another technology such as Spring MVC or Angular. That is not innovating. That is keeping up.
The ones who are innovating are doing new things that are experimental.
Innovation debt has already been coined, and written about. It is the debt incurred when you are trying a new technology.
See James Gardners blog about it from 2 years ago: http://innovatorinside.com/2011/08/09/the-technical-innovation-debt/#comment-11074
See the book on this subject published 2011:http://www.amazon.com/Sidestep-Twist-create-products-services/dp/9814351105/ref=sr_1_1?ie=UTF8&qid=1363883414&sr=8-1&keywords=sidestep+and+twist
In summary, good article; wrong title.
steveolyo
March 21, 2013 at 11:31 am
I addressed the semantic conflict above. Glad you like the article, sorry two of us have used the same term in different ways, but I think the English language can stand that confusion for a while. I don’t see that as technical debt, however.
It’s perfectly possible to have a clean, maintainable code base in COBOL. I’d argue that in that case there is innovation debt, but no technical debt. Also, I don’t see how not using a new IDE, version control system or (more dubiously) new build system is really technical debt. It does, however, fit nicely under this definition of innovation debt.
peterbell
March 21, 2013 at 11:56 am
You make a good argument with the COBOL example. But the flaw is in the word innovate. Innovation is not following a trend or moving to a new language. That is keeping current. Keeping up with best practices is not innovating. Innovation comes with forging new pathways. Researching new ways to do things, not following an existing path, which is what you are describing.
Releasing a new technology such as Angular, that’s innovating. Learning angular, that’s keeping current.
A resume that has COBOL on it and nothing else, that shows lack of initiative. A resume that has several patents on it, that shows innovation. A resume that has Angular, JavaScript, Node, Backbone, Mongo, and other new technologies, that shows initiative. If there is something that shows new ways to use those technologies, that shows innovation.
Not investing in your developers? That is poor resource management and increases the risk of turnover.
I think you are on to something, but can we call it something else? It should be called something else. Yes english can handle overloading, but overloading is weak. It leads to confusion.
Maybe Resource Development Debt, Developer Debt, Tooling Debt, etc.
The scenario you describe about the “bet the company” project sounds like technology debt. Considering the development team had not paid the price of learning the new technology. That’s not innovation, because they were not innovating anything. They were learning a set of technologies new to them not to the industry.
Thanks for listening. You have a great blog. I’m trying to add to a less confusing vernacular, not trying to aggravate you for the sake of it.:) Sorry about the previous double post. I thought the text had been lost.
steveolyo
March 21, 2013 at 6:09 pm
Stevo, I think that we are dealing with an issue of semantics. Innovation can have different meanings, I think. There is the trailblazing, cutting edge, innovation. Then there are the innovations that aren’t trailblazers and cliffhangers. Inviting new/newer standards into an environment where they don’t currently exist can be considered innovations.
In that context you could both be right. Personally, I think that Peter’s definition is more relevant. While a handful of companies will face the definition that you refer to, most companies will face the type of innovation that peter is referring to.
Aaron Frost (@js_dev)
March 22, 2013 at 1:07 am
Thanks Aaron.
Definitely an issue of semantics. I would like to see more innovation in this subject. Rather than redefine an existing term, I am suggesting that Peter innovate and come up with a new term, rather than overload the definition that James Gardner has defined in the past.
Let’s examine the logic:
Consider that when you borrow money to purchase a car, you incur debt, automobile debt. Likewise when you purchase real estate, you have real estate debt. When you borrow time and/or money to innovate, you have innovation debt.
If you don’t borrow money to buy a car, you don’t have automobile debt. If you don’t borrow money to buy real estate, you don’t incur real estate debt. Likewise, if you don’t innovate, you don’t have innovation debt, you may have an innovation deficit, but not innovation debt.
A lack of something is not a debt. A lack of something is a deficit
What Peter describes could be called Technical Stagnation, Technology Deficit or Technology Stagnation, not innovation debt.
Thank you for discussing this. I appreciate the debate.
steveolyo
March 23, 2013 at 10:58 pm
[…] Keep Your Codebase Maintainable – Introducing Inline Comments in Merge Requests (Assembla) Innovation Debt (Peter Bill) Backbone.js 1.0 released (ashkenas.com) Responsive Web Design With Physical Units […]
Darker Nemesis’ Weekly Reading (#13) | Darker Nemesis
March 22, 2013 at 10:07 am
Love the concept Peter – interested in republishing it on the world’s most popular innovation web site – http://innovationexcellence.com ?
Braden Kelley
March 23, 2013 at 8:34 am
Sure – as long as you link back to my blog somewhere. If you want any additional content, an interview, etc just let me know!
peterbell
March 23, 2013 at 9:25 am
This is a fine observation. The problem is it has nothing to do with innovation in any reasonable definition of the word. What you have effectively captured is the bad habit for managers to manage for the short term and your recommendations provide good advice for long term investments in employees.
As worthy a goal as it might be to aid employees in keeping up with the latest methods and ideas, keeping up with trends is hardly an innovation. To use the word innovation in this context would be to encourage staff to develop new methods and ideas themselves, but even then to label it ‘innovation’ by decree rather than result is at best a hubristic inflation.
Scott Berkun (@berkun)
March 24, 2013 at 1:37 am
Agree with you on much of the post, Peter, and it doesn’t just apply to software engineers. Like other commenters, I too struggle with the word “innovation” here, as it is a big term tied to new product development and disruption (etc), while you are referring to the important but different tasks of investing in your people and simultaneously modernizing your stack in a gradual way.
giffc
March 24, 2013 at 6:59 am
I wonder if re-examining the context that this comes from will help with comments re: “innovation debt” being a misnomer.
I understand that it’s possible to read innovation debt as “a lack of innovation”, but that is not the way in which I’m using the term. The antecedent that this is coming from is the idea of technology debt – and in a programming context that certainly doesn’t mean a lack of technology. So innovation debt (in this context) should not mean a lack of innovation.
Technology debt is the debt incurred when a dev team doesn’t invest in “doing things right”. It comes from not investing properly in the code base – often because the team is too busy with adding new features or bug fixes as quickly as possible. So the core concept underlying technology debt in the context of programming is that you’re not investing in the code base and eventually that lack of investment will cost you more than it saves.
So when I look at innovation debt, I’m describing the debt that teams take on by not taking the time to invest in adopting innovations that would allow them as a team to become more effective in the long run and am drawing parallels between what happens to a code base if you don’t invest in paying down technical debt and what happens to a team when you don’t invest in continuing to adopt appropriate new innovations to keep current and productive.
peterbell
March 24, 2013 at 9:31 am
I understand precisely what you meant, it’s just the label I have issue with. My point is if adoption is lacking, than adoption debt is the term you want. If investing is lacking, it’s investing debt.
Also Hubspot refers to something similar as culture debt (slide 5):
http://www.slideshare.net/HubSpot/the-hubspot-culture-code-creating-a-company-we-love
Scott Berkun
March 24, 2013 at 2:06 pm
It’s tough, because I agree there are potential issues with the name, but I don’t quite buy this line of argument. If it were true, surely technical debt would be a lack of technology, and that’s absolutely not the meaning of the term. Hmmm…
peterbell
March 24, 2013 at 2:17 pm
A lack of something is a deficit not a debt. A debt is something that must be repaid upon borrowing something. Technical debt is incurred when time is borrowed by not refactoring or spending time retooling. The real debt in technical debt is time. Technical debt is not a lack of technology. That would be a technology deficit.
steveolyo
March 24, 2013 at 6:20 pm
[…] sich “Schulden” in der Innovatinosfähigkeit eines Unternehmens gestalten können. https://blog.pbell.com/2013/03/19/innovation-debt/ […]
Gelesene Blogs und Artikel KW 12 | Christoph Gockel
March 24, 2013 at 11:19 am
Peter, love the article. I saw it on the Innovation Excellence website and captured my reflections on my blog (http://brendansterne.tumblr.com/post/46175740465/avoiding-innovation-debt).
After posting that I found your page here. Like the other commentators, I struggle with your use of the term “Innovation Debt” – I would have used something like “Capabilities Debt”. I agree with you that what you’re talking about is distinct from technical debt. No matter what term is used, the problem is real and the solutions you propose are good ones.
Thanks for sharing.
brendansterne
March 24, 2013 at 1:18 pm
[…] Peter Bell takes a look at the concept of ‘innovation debt’. […]
Weekly bits of interest – 25 March 2013 | Public Sector Innovation Toolkit
March 24, 2013 at 7:26 pm
[…] Innovation debt: 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”. – https://blog.pbell.com/2013/03/19/innovation-debt/ […]
April Pocket link collection with 32 links | Cato's Place
April 1, 2013 at 3:02 am
[…] We are probably all aware of the concept of technical debt. Here Peter Bell tells us about the dangers of innovation debt. […]
Perspectives on Testing » The Seapine View
April 8, 2013 at 4:59 am
This is why I just quit my current job.
The employees / management have to WANT this.
I worked with a great group of people. I did several lunch and learns, I rolled out 1-2 new projects using the latest tech and demoed those for everyone showing the benefits of updated code. We sent people to NCDevCon.
But at the end of the day most people did their 9-5 and left.
No code was improved, no one ever came to ask me how they might integrate the framework we talked about in lunch and learn into their project. Management didn’t seem to care either.
Jim Priest
April 11, 2013 at 8:43 am
Hi Jim, Good to hear from you. Know what you mean about the company. It’s why (I think it was Martin Fowler) said “you have to change your company – or change your company”. Sometimes you can change the culture, sometimes it’s better to just find a culture that’s a better fit. Hope all goes well with next steps . . .
peterbell
April 11, 2013 at 8:47 am
[…] debt is the cost that companies incur when they don’t invest in their developers,” Peter Bell writes in his personal blog. “It happens when the team is too busy putting out fires and finishing up features to keep up […]
Fast Company Asks; Is Your Company Going Into Innovation Debt?
April 11, 2013 at 10:08 am
FWIW, I’ll be doing a @GA livestream on innovation debt Thursday May 16th 2pm EDT http://www.eventbrite.com/event/6140367003
peterbell
April 11, 2013 at 3:07 pm
[…] —Innovation debt is the cost that companies incur when the team is too busy putting out fires and finishing up features to keep up to date with advances — Peter Bell […]
The Only1List Cheat Sheets | Creativity & Innovation
April 25, 2013 at 3:40 pm
Reblogged this on Paul goes skiing and commented:
Great post concerning how to keep your development team sharp
pugilation
June 26, 2013 at 11:20 am
Great article. Attending technical conferences and seminars is great – but wonder how many companies would sponsor their employees to attend such events.
Srinath
June 26, 2013 at 10:59 pm
In my experience, most decent companies will sponsor their devs to do at least one conference a year. I know many startups, mid sized companies and enterprises that do so (if they didn’t there probably wouldn’t be very many tech conferences, as only so many developers are willing to pay their own way). I would certainly never work for or with a company that wasn’t willing to invest in keeping their devs up to speed.
peterbell
June 27, 2013 at 6:59 am
The biggest hurdle I have found to this is corporate companies that are slow / hesitant to move to new software versions once the current ones are running. This is almost like give a kid candy and then saying he cannot eat it yet.
Dave
January 14, 2014 at 9:57 am
[…] Accumulating innovation debt: […]
# 4 Side notes JAX London 2016 – Automation Journal
December 19, 2016 at 6:33 am