I don't have to get approval to take 20% time, and I work with a number of people on their 20% projects.
I can also confirm that many people don't take their 20% time. Whether it's culture change due to new hiring, lack of imagination, pressure to excel on their primary project, I'm not sure, but it is disappointing. Still, in engineering No permission is needed.
There is a reason the article talked to many ex-googlers because they are ones who, perhaps, left when there was a difference of opinion about their contribution to the company. And if that conversation attempted to use some of their 20% projects as a way of contributing to their contribution, and that was the disagreement, well it ends up with them leaving.
I left in 2010, which was the start of the lurch toward more managers, and those managers were being scored on what their team accomplished that was assigned to the manager, not on what their team accomplished on their 20% time. Some managers had taken that to mean that 20% time didn't count at all toward calibration, and if you were working only 80% of the time on their projects it counted against calibration. Hence the disconnect. That is why "120%" sort of works, even in the face of a manager trying to make their own number. Except the benefit sounds different if you say "And on Saturday you can work on any project you want." :-)
The policy of course is to not do that, but how would Google enforce that? If you spent 200% of your time on your primary project, you might get excellent reviews. Should you be calibrated 50% lower to normalize everyone? So yes, if you work 100% on your primary and +20% on your 20p, then you might get higher perf scores. Eh, if you have a good idea how to correct for that, go ahead, but it's a people problem and people are hard to deal with in these kinds of thing.
This is one reason why I actively encourage as many people to take their 20% time as possible. :)
My personal experience though is very positive regarding 20% time. My first project, I started, gathered a few contributors, built a prototype, pitched it and turned it into a full-fledged project. I got great reviews and promoted in large part because of that. In my second PA I work on open source projects. Less glamorous, and maybe less perf-impacting, but that's not my goal right now.
In general the people I've seen take 20% time in a focused way tend to be the higher-performers. They're more self-guided, more critical of problems that need to be solved, or use 20% time to teach themselves or move onto harder problems. Maybe as we've grown the percentage of employees like that has shrunk, maybe it takes a while to realize you have 20% time. Not sure, but I'd like to see it be used more, it's good for everyone.
I'm not being critical of your account, I'm glad it has worked for you, as the manager of the engineering effort here I want to take the "good" stuff and use it, and leave behind the "not so good" stuff. So that is my agenda in this discussion, nothing more, nothing less.
"In general the people I've seen take 20% time in a focused way tend to be the higher-performers."
That is my experience as well, and regardless of a company policy for or against 20% time, focussed, high performing engineers will spend 20% of their time do cool and innovative things. Whether they do it at home or at work doesn't really matter, and having them do it at work is good for the company.
So the interesting thing about the policy is to capture the next tier of engineers and help them to be more productive by encouraging them to develop habits of the aforementioned highly successful focussed engineers. And to weed out the folks who are abusing the program [1] or at least not being any more productive with it.
If nothing else people are different right? Facebook's response has been "hackathons" which carries with it some characteristics of high performers (who quickly prototype ideas to test their validity or get a handle on their challenges)
But in all those scenarios, if you have managers, you need to also train your management on what the program is trying to achieve and how it might be addressed. So you don't end up with some managers giving their people 1 day a week off, and some demanding they work on Saturday if they want to use that extra time.
If it is "You have this huge resource available, dare to use it." then you can manage to that without damaging either morale or perf scores. From the anecdotes in the OP article it sounds like they are still working on that part.
[1] Like the guy who said he was trying to capture the great ideas he dreamed about in his 20% time so he would spend several hours napping for an hour and then waking up and writing down what he dreamed about.
My previous experience is mostly in R&D startups, doing robotics and natural language processing. I was hired in 2010 and then found out I would be working on YouTube ads. I was disappointed, but decided to try to make the best of it. After three months I realized my lack of interest was going to be a problem, so I talked to my manager about trying to transfer. He discussed it with the site director, and the response was "we don't care" and I couldn't transfer until I'd been there 18 months.
I decided to stick around and see if I could work the system in some way, with the probably naive thought of trying to demonstrate my abilities and catch someone's attention that would help me transfer to a project I'd enjoy where I could make a real contribution.
During Innovation Week (a hackathon) I led a team of three other engineers working on an idea I came up with, and we won the "Most Innovative" award. The other engineers decided they all wanted to devote their 20% time to working on my idea.
My Tech Lead and my manager had no interest in my Innovation Week project, and I still had no way out of YouTube ads. Unsurprisingly my performance on my 100% project wasn't great and even if I made it to 18 months it seemed unlikely that I'd be able to transfer. I left after 17 months at Google.
I've mentioned this story before, and I hope I'm not just grinding an axe--I'm just telling my experience in the hope that it will inform engineers about possible outcomes of working for Google. I am fully responsible for my experience there, but I can say the priorities of the (large, heterogeneous) company were not what I (again, probably naively) expected.