TL;DR: 20% time is awesome and you should get your company to do it.
Caveat Emptor: The Google employee handbook defines the company's official policies concerning 20% time. This blog post is my own personal interpretation.
Back when I was interviewing, I was very suspicious about Google's 20% time. I've heard rumors about products like GMail coming from 20% time. Marissa Mayer even quipped that to half of Google's launches in 2005 came from 20% time efforts.
Seriously!?! If a company spends one-fifth of its time futzing around how can it get anything done?
The truth is that while every Googler has the opportunity to take 20% time to work on whatever they wish, it isn't carte blanche to take Fridays off and play X-Box. Having a 20% project doesn't mean you are responsible for 80% of your job; more like you are volunteering to put in 120% the effort.
At Google performance is measured by impact: benefit to Google and its customers. If an engineer is able to have a big impact, then spending some cycles on a 20% project is no big deal. However, if someone was having difficultly meeting expectations as-is, then contributing to a 20% project would be a poor decision.
In short, the attitude at Google is: "We trust you to do what you think is important with your time."
20% Projects in Practice
Not everybody takes on a 20% project, but those that do usually fall into a few board categories:
In short, the attitude at Google is: "We trust you to do what you think is important with your time."
20% Projects in Practice
Not everybody takes on a 20% project, but those that do usually fall into a few board categories:
"I have something interesting to do"
Some people use 20% projects to pursue their passions. For example, there are Googlers who teach classes at high schools and colleges. Some have desks, go to PTA/faculty meetings, the whole bit.
Other people spend time organizing projects such as GoogleServe or facilitating classes internally. (I, for example, am proctoring a course titled Having Difficult Conversations tomorrow to help Googlers, well, have difficult conversations.)
Other people spend time organizing projects such as GoogleServe or facilitating classes internally. (I, for example, am proctoring a course titled Having Difficult Conversations tomorrow to help Googlers, well, have difficult conversations.)
This has negligible impact as far as engineering efforts are concerned, so it's unlikely that teaching Introduction to Algorithms is going to get someone a promotion. But the people engaged in these types of projects are likely happier and likely more engaged in their work.
"We could use help" or "Team dating"
Other times, 20% projects are used to describe temporary within the company.
Imagine GMail and Google News and a hypothetical feature. The GMail guys have a great idea -- delivering a daily newspaper to your inbox. That way as soon as you log in you could see the highlights of the past 24 hours.
The Google News folks might be excited to add this feature, but are likely already working on other big projects for the quarter.
Rather than GMail simply waiting the weeks or months it takes for Google News to get to that feature, some GMail engineers might start working on Google News in a 20% capacity to add the changes necessary to support the daily digest scenario.
Of course large teams are more likely to work with one another, but the point is that if you have a good feature to contribute then just add it! 20% contributors are welcome to add features and address low-hanging fruit.
Also, volunteering to work for another team in a 20% capacity is a low-cost way of doing transfers. Rather than interviewing to change groups, an engineer can simply try working with them and see if its a good fit first.
"I have an itch to scratch"
Occasionally there are problems, sometimes endemic, that nobody has the time or authority to fix. The classic example is the origin of GMail. A lot of Googlers were unhappy with the email software and figured they could do better. Rather than waiting for a VP to staff a team and issue a mandate, a few engineers just banded together and started writing code.
A few years later GMail was released publicly and used by millions worldwide.
A few years later GMail was released publicly and used by millions worldwide.
This is the basis for that "Half of Google's launches in 2005" reference. If you see a problem, 20% time gives you the freedom to be proactive and just solve it.
Personal Experiences with 20% Time
As nice as 20% time sounds, does it really work? Since I've been at Google, I've take advantage of 20% time on a few occasions. Here are my experiences; your mileage may vary.
Project A - Dating an engineering team
Project A - Dating an engineering team
Shortly after I started I wasn't super-excited about the project I was working on, and was really intrigued by Project A. So I met with their tech lead and signed up to do deliver low-hanging fruit that quarter. (Bug fixes, a few independent features, etc.)
The next quarter, I transferred to the other project as my full time responsibility and stuck around on my old project as a 20% project as a transition / finish up remaining work.
Project B - Gathering hard data
About a year ago, a lot of people were talking about "creating a death star" and how easy it would be able to implement one using "lightsaber crystals". Such a project would be amazingly successful if we added killer features like a "trash compactor inhabited by a Dianoga".
Sick of informal meetings, cloud-talk, and brainstorming I started writing code. About two full weeks working full time on my prototype I had a demo. As it turns out "trash compactor inhabited by a Dianoga" wasn't as exciting as we hoped and this projects "hypermatter reactor core" was kind of a deal-breaker. So alas, Google's plans for "creating a death star" had to be scrapped.
The project didn't have any impact, so it didn't necessarily advance my career any. But the experienced enabled me to learn some new technologies and provide some concrete data points for future experiments.
The project didn't have any impact, so it didn't necessarily advance my career any. But the experienced enabled me to learn some new technologies and provide some concrete data points for future experiments.
Project C - Trying to seize an opportunity
When WebGL was checked into Chrome's experimental branch, I knew that a slick, 3D, social game on Google+ would be a hit. So I figured I had a few months to come up with a project and cause a big splash when WebGL was finally generally available.
I met with some friends and we started working on the project. We got pretty far on creating a 3D engine, asset management, and so on. But unfortunately we weren't making progress fast enough. In the few months it took us to get a semi-playable demo there already were a glut of existing games ported to WebGL. (Example 1, example 2, example 3, etc.)
With our small window of opportunity gone -- and the crushing reality of how much of an investment modern games are -- we decided to kill the project.
But again, it was a great learning experience and now there is a game design and prototype there, perhaps only in need of a pivot to be revived! And, had this minor risk had panned out there could have been a huge upside to Google. (Specifically, thousands of man-hours wasted in pursuit of "points".)
So there you have it. In my experiences 20% time hasn't been about zoning out of work, but rather staying engaged and having the freedom to take advantage of opportunities. At Google there is a strong sense of trust between the company and its engineers, and 20% time really exemplifies that phenomenon.
With our small window of opportunity gone -- and the crushing reality of how much of an investment modern games are -- we decided to kill the project.
But again, it was a great learning experience and now there is a game design and prototype there, perhaps only in need of a pivot to be revived! And, had this minor risk had panned out there could have been a huge upside to Google. (Specifically, thousands of man-hours wasted in pursuit of "points".)
So there you have it. In my experiences 20% time hasn't been about zoning out of work, but rather staying engaged and having the freedom to take advantage of opportunities. At Google there is a strong sense of trust between the company and its engineers, and 20% time really exemplifies that phenomenon.
The cynic in me reads this as google saying: "If you want to do additional work outside of your normal job, we're happy to support you in that." It's great that you have that policy and I can believe that other employers wouldn't be so forth coming (e.g. I don't know that I could team shop at MSFT and maybe it's hard for me to get the source code to Word to hack on it during the weekends) but it seems a little heavy handed to sell the fact that the offices aren't closed on the weekend as a benefit of employment.
ReplyDeletePut another way, if it was called 120% time, would the actual implementation be any different? Is that actually a better way to give an outsider a view of the world?
Still trying to write a game? Reminds me of the good ol' days at Trinity. :-) I was reading through our game design doc the other day. I still thing Lego RPG is an awesome idea. Hilarious that Minecraft allows you to do some of the awesomeness we had in mind, without the explicit story.
ReplyDeleteThings haven't changed much... games are still a lot of work though!
mge: At Relevance (http://thinkrelevance.com) we also have 20% time, and it's definitely NOT 120% time. It's actually a day of the week (Fridays) and the effects are similar to what Chris mentions.