The Innovation Coin Principle – how to balance innovation and efficiency

Engineers like to build stuff. That’s what they were educated for, do and love! And most engineers love their new toys. New Languages, frameworks, new, new.

That’s great, because most engineers I’ve met in my career are curious by nature and that is very important! The whole tech industry moves at a very high pace. Boring tasks are more and more automated. So new – change – is the new normal!

Change is the new normal. This makes innovation increasingly important.

However, if you want to be innovative and build the future. You actually have to build it. The more you build, the faster the future is here. Unfortunately nobody is fast at doing things they don’t know and have to learn. You are fast and master a skill through repetition.

So the big question is: How do you balance innovation and efficiency?

My team and I were in the situation that our project was transitioned to another office within our group and we had to build up new infrastructure and services for our new projects, which were completely distinct from the prior one.

So we stood before a mountain of requirements and a complete empty greenfield. This is always a tempting and dangerous situation. No structure or frames means that everything is up for discussion. Discussing everything at once will freeze your ability to actually build something and progress.

The team started building, block after block and the amount of discussions, even for little things, wouldn’t stop. And you can’t blame the team, they wanted the best, but somehow we didn’t progress. We weren’t efficient. Once I identified this problem, I tried to join the discussion to steer them in a certain direction. Usually I don’t get involved that much, because they are doing a great job anyway. This approach worked somewhat, but actually I didn’t want to do this and discussions still needed time, the teams and in addition mine.

How can this be skaled? The anwser is not in orders or influencing discussions. There are so many little decisions an engineer does every day.  This wouldn’t work. So I decided to sit together with the team and define a principle for we want to work and achieve this necessary balance.

The Innovation Coin

We decided that for every new project, module, whatever there are 5 big decisions and we have 2 innovation coins. So of these 5 decisions we would make 3 decisions of things we already knew or have done. And for 2 decisions we would do something new. New library, new version, new style.

Suddenly the too long discussions ended quickly and we started building cool stuff effectively. And all, the team, the stakeholders and the customers were much happier.

Basically with this decision we said we want to be 40% innovative and 60% efficient. Of course how you distribute your innovation coins massively depends on your environment. Sometimes you want no innovation coin at all, Google X wants 5 of them.

Besides this balance of innovation and efficiency, the other important lesson is about values and principles. Don’t use commands, define principles and get buy-in from the team! That’s all it needs.

Dan McKinley argues in the same direction: Choose boring technologies. He has great content about this. As he would put it: Ship it!