My company is considering implementing a “side projects” policy in a similar vein as Google’s 20% time, and I’ve been asked to develop it.
The goal is to give our developers the time and freedom to do creative and innovative (read “cool” and “fun”) things outside of their main, billable project work. We recognized that many of the key technologies that are a part of our current infrastructure and process originated from a developer experimenting and working with things on the side initially, and then putting more focus on them once they were deemed useful and worthy. For example, our use of unit tests, continuous integration, and the development of our automated build system started this way.
We want to encourage these kinds of activities and foster a culture where this happens because they bring value to the company and make it a more enjoyable workplace.
It feels intuitive to me, as a developer, that side projects are a natural and healthy pursuit. I’m curious and creative, and often, my everyday work becomes monotonous. Side projects can fix this boredom and prevent burnout. It’s been easy to find people boasting the merits of having such a policy. Many people will think of Google’s 20% policy, which has famously given way to Gmail, Google News, Google Talk, and more. Clearly, they were not the first – this article reviews an early implementation of a side projects policy at 3M that resulted in the ubiquitous Post-it Note.
But can it work at a smaller company? Alex Payne acknowledges the importance and benefits of side-projects, but admitted having no room for them while starting off at his small company. Ironically, Twitter started off as a side project.
We want to give our developers real freedom, but also need to have some sort of oversight. What’s the right amount? What should people use this time for? Do they need to get approval? What if they don’t want to, or can’t think of anything to work on?
This question on Programmers StackExchange captures a lot of the initial thoughts I’ve had. One of the observations from that discussion is that “it’s a culture – it’s unlikely to work if introduced by some kind of policy, and isn’t something that can be installed by developers.” Well, that can’t be true, but I guess the point is that making this happen is much more than instituting some guidelines and rules. It’s people.