Implementing 20% Time
By now, I assume you've heard of Google's fabled 20% time. They've changed it recently, but the original idea was simple: give every engineer at Google 20% of their time to work on something THEY thougth would be both interesting and ultimately profitable to Google. The focus was on building a container for experimentation. These projects did not have to be approved by a manager. They did not have to connect (directly, anyway) to Goolge's core business. After all, these employees were spending 80% of their time on the Google core business. But in this one day per week, they could develop something new. Although it appears inefficient, the end result was positive for Google. Things like Gmail, which now generates a significant amount of profit for Google, were developed during 20% time, as an email interface simply did not connect to Google's core business back then. By creating the space for experimentation, they allowed their people to change things in a way that unlocked new value (my definition of innovation).
It is important to remember, however, that making this work requires more than just the cool idea of x% time (not everyone who does this uses 20%). I'm working with a client on implementing a version of this at their organization, and we're getting into the nitty gritty of things like:
- How will the learning from x% time projects be shared?
- Who gives feedback on the projects, and how frequently?
- What strategic purpose should x% time projects be tied to?
- Do these projects need to be approved?
- How do they transition from being experimental to being integrated into operations?
- Can we find ways to protect people's x% time so it doesn't get swallowed by the latest crisis?
There aren't simple, "right" answers to these questions. It will vary depending on the organization and the context. But you need answers. Never settle for the really cool idea you hear about in the business books. Think through the implementation details before you pitch it to management or try to sell it to staff. You don't need all the answers, but lay out the key questions so people can see why and how it makes sense to YOUR organization.