I recently had the opportunity to speak at the Chicago CTO Summit on building a new product innovation team and I wanted to share the first few tools I’ve begun to formulate for the Innovator’s Tool Belt.

First, for those who prefer, here’s the 20 minute presentation on this topic.

What Toolbelt?

For those who prefer to read, first, let me explain what I mean by the Innovators Tool Belt. I’ve often used the tool belt analogy with engineers on my team. For example, when explaining some of the ways we build software I have referenced how carpenters will select their hammer and nails for some types of work. Or, alternatively, their screwdriver and screws for other types of fastening. We have talked about how there are established industry patterns for how walls, floors, stairs and more are built.

Similarly, software teams have similar concepts. Hash Maps, Linked Lists, Tries are the hammer, saw, and screwdriver of Software Engineering. Design Patterns and Microservices Architecture for instance, are established industry best practices for solving real world software problems.

But the truth is that most people aren’t carpenters, and I have no idea if wood shop is still class offered in schools. I know most people have not raised a barn, so maybe these analogies aren’t useful. So, I’ve decided it’s time to innovate on the tool belt analogy as well as the tool belt itself.

Thus the Innovator’s Tool Belt, the Swiss Army Knife of gadgets, lifting heavily from the Batman canon in the presentation above. What is the batarang of Innovation? The shark-repellent of rapid software development?

The Innovation System Works If You Work The Innovation System.

A bit about the innovation program we built. While we launched about six months before “The Startup Way” by Eric Ries was released, our program has a lot of similarities. His book was a great validation that we were onto something. A few components of the program we built which helped shape innovation:

Incremental Investment – Our projects only received increased investment when they had proven they had “legs.” Constraint breeds innovation. Constraining on time and budget helps us stay lean and sets a clear deadline to show progress on business alignment or other key metrics.

Radically cross-functional teams – UX, Marketing, Product, Engineering, Program and more all acting as owners. Sitting together. Brainstorming. Everyone having a say in the product direction and when a feature could be simplified.

Innovation Economics – Being ruthlessly honest about what the costs of innovation have been and investing in innovation with a portfolio mindset. Thinking of the Three Horizons of Innovation: we can’t have 100% of projects in horizon one (incremental innovation of current products,) and horizon two (disruptive innovation of current products). That’s just playing it safe. Even though the big bets are out in horizon three (disruptive innovation of the company/industry) and we should be swinging for the fences, putting 100% of our efforts here would be overly risky.

Scaffolding – Having a tried and true framework for how we build applications has given us flexibility in staffing and a rapid innovation stack for every application. The quick start of a new Django application coupled with some custom built components makes learning how a new product would be adopted in less than three months possible.

Mistakes Were Made.

First, the bad news. We made mistakes building the new product innovation team we refer to as the Incubator and had to learn and move on But, then again, that is the theme of this blog. Here’s a few key mistakes and what we learned from them:

Hiring – We had to learn how to hire for Innovation. Flexibility. Passion. Ownership. Most importantly, a strong desire to deliver business value. These are some of the keys to an innovation team that works. Finding the leaders who possess these qualities is hard and takes time.

Globalization – We also expanded to too many sites and too many teams too quickly with too little leadership. In retrospect, we should have worked to constrain the locations and time-zones we took on in the first year (or two) in order to really pressure test the process before trying to replicate it.

Over-constraint – Finally, we used our new found process of innovation to restrict successful teams. We had great successes on our hands and ran them with teams of two engineers. Learning when and how to grow successful teams was a key differentiator in our success.

Tools That Work.

Now for the good news. There are some tools that we tried that worked and made the team even more effective at innovating.

Exits – Expect the project to fail. Work to learn as much as possible until it does. While it can lead to a nihilistic outlook at times, reminding ourselves that we’re searching for new business value often counters that attitude. Thinking with the end in mind helps keep perspective on technical debt.

Culture – An innovation team isn’t a counter-cultural team, it’s a sub-cultural team. Influence the rest of the organization. Inspire them. Take the company culture and evolve it. We emphasized parts of the broader team’s culture where it helped us, and redefined other parts to suit us better. This way our team was a partner with the broader organization, not a cancer.

Double-down – When something is working, don’t just keep funding at the same level. Invest more. More time. More money. If reasonable amounts of money can make a problem go away, do it.

The Innovation Tool Belt.

This is just the first set of tools we’ve discovered and the first attempt to publish them. There are more tools and it’s my goal this year to share even more of the tips and tricks of building a great innovation team.