Peter Bell

Innovation debt

with 36 comments

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.


Written by peterbell

March 19, 2013 at 6:30 pm

Posted in Uncategorized

How to get an awesome startup job

with 6 comments

College can be a great experience, but to get your pick of the best startup jobs you have to actively take control of your education and fill in the gaps that your college doesn’t cover. I’m just completing a college tour for hackNY where I talked about the startup scene in New York, the hackNY program for connecting students to great local startups, and the skills that computer science students need to focus on to get their pick of the best startup jobs.

There’s a lot of diversity in the education that computer scientists are getting in college, but few of the colleges are providing all of the education they’ll need to get a great startup job. Here are some suggestions for broadening your education and ensuring you have the skills to get the best startup gigs. This is a short summary of some key points from the tour. Keep an eye out for more comprehensive posts in the spring.

1. Passion: If you don’t care about what you’re working on, you won’t fit in at a startup. Startups require a lot of passion, and if you don’t care about both the problem that the company is solving and the craft of software development, you won’t enjoy the experience.

2. Learn how to learn: It’s amazing to me that most students manage to get through college without taking a required class covering how learning works, learning strategies and patterns for finding out and optimizing for your learning style.

3. Learn some languages: It helps to know some Java or C# – if only to prove that you can learn it. You need some experience in a dynamically typed scripting language like Python or Ruby so you can quickly script solutions to problems, and it’s becoming increasingly important to have a solid understanding of a functional language. Clojure and Haskell are a couple of good starting points.

4. Engineering practices: Working on a team, you’ll need to understand and use version control, grok continuous integration/delivery and get “test infected” so you can write maintainable code with good test coverage when that makes sense. These engineering practices are usually the biggest weakness for students. Make sure to work on them while still at college.

5. Product focus: If you’re ever planning to start your own company or to work at a really early stage company, read “The Lean Startup” and “Running Lean”. It’ll substantially reduce the amount of time you waste writing software that nobody cares about.

6. General knowledge/trends: If you don’t already, read <a href=“”>Hacker News</a>. It’s the daily newspaper of the startup technology set. And make sure you know something about key trends like functional programming, single page apps, NoSQL data stores, mobile application development strategies, cloud hosting and Big Data.

7. Pick a (marketable) skill: Make sure you have depth in at least one skill that a startup could leverage immediately – whether it’s front end development, ruby, python or objective-C.

8. Make connections: The best jobs are never advertised, and it’s hard to become a great software developer without hanging around other great engineers. Look for meetups in your city and start to spend time with great developers. It’ll help to improve your skills – and your job prospects.

Most startups are desperate for passionate, skilled, well rounded engineers. Hopefully some of the advice above will help you to cut to the front of the line and get a range of interesting offers from some awesome startups.

Written by peterbell

February 16, 2013 at 5:41 pm

Posted in college student, hackNY

Back to blogging

leave a comment »

It’s been over two years since I blogged seriously. I started blogging in 2006 with my “application generation” blog that got over a million views in 2007 on the fairly narrow topics of domain specific modeling/code generation and ColdFusion programming.

In 2010 I started another blog “Getting Groovy” about Groovy, Grails and other interesting Groovy based technologies on the JVM.

Now I’m looking to blog about a wider range of topics. I will definitely have deeply technical content on a range of technologies from Neo4j to Ruby on Rails to Backbone.js, but I’ll also be blogging about entrepreneurship, startups, managing software development and how to build a great career in software development.

Written by peterbell

February 16, 2013 at 5:39 pm

Posted in misc