The rumours of the death of Google’s 20% projects have been greatly exaggerated. Except if you misunderstand what a 20% project is. In the case of Google, the impression seems to be that everybody in the company can work on something else 20% of the time. Indeed, Google itself has claimed that most of its major products (Android, Chrome, Gmail…) originally started as a 20% project.

However, the 20% is not a rigid system. I’ve seen companies struggle implementing a 20%-like system. First, which day of the week will you not do your actual work? Second, what ideas will you work on? In this worst-case implementation, a co-worker is forced to work fixed hours on vague ideas.

At Google, anybody can work vague hours on fixed ideas. When an idea is mature and circumstances at your “regular” position are good, you can start taking up time to work on your project. If necessary and possible, you can work for 10 weeks in a row. You will end up with a convincing prototype. This is a good base when deciding to continue or to stop the project.

There are many good reasons why 20% projects are a very good idea:

• It’s better to fail 10 times small than to fail one time big. A small project is less risky than a project for an official product. This is good for innovation.
• It’s better to have two people working on the same thing than to have none. No way that you will start two competing “official” projects. But for 20% projects, why not? Both project owners will try their hardest to build the best prototype they can. Best of all, the final product can take up ideas from two teams of bright people.
• There’s no better way to motivate people than to let them work on their own product.

When you start 20% projects, you need to change a number of aspects of your organisation. First, it doesn’t make sense to set objectives and evaluate them yearly. When somebody picks up a 20% project halfway through the year, long-term objectives don’t work. This is yet another reason to stop your annual reviews.

Second, you need to follow up closely on those projects. A project that fails causes no harm when you spot it early. So discuss the projects openly and show your worries, doubts as well as your positive impressions. Insist that the project leader keeps an open view as well: when he gets dragged in too deeply, his opinion may become clouded.