Thanks, I'm very curious about this aspect of Google's culture.
Sometimes greenfield projects or rewrites also permit lots of 20% time, because you've got existing implementations, so you can have some people maintain the old one and some people go work on the new rewrite using new tech.
I'm one of the unlucky ones with very little free time at the moment. :)
Twenty percent projects were a real thing, but less than five percent of engineers participated. As far as I could tell, side projects were not the way to get ahead. The people who advanced were the ones who did what their bosses told them, full stop. For all that Google makes a big deal about having an egalitarian peer-based culture, the end result was remarkably strict and top down. That Japanese proverb about nails fits Google to a T.
You don't get in trouble for not working enough hours. A six-hour day is more than enough effort to keep you employed. As in most corporate jobs, you could probably get away with 2-4 (spending the other hours at your desk, but learning skills for the next job) if it's not obvious.
You get in trouble for 20%T (being "distracted") if it pisses your manager off, if it looks like you're trying to engineer a transfer off an undesirable project, or if you appear to be putting 50% of your time into the project.
The reason 20%T usually fails (on employee-initiated side projects) is that it's really hard to launch at Google without a full-time launch. The standards are really high. You have to cover a lot of bases that you wouldn't be expected to worry about in a startup, and you'll need to get enough SRE (reliability engineer) support to cover 24 hours. It's not unreasonable that Google is that way, because they have an understandable brand concern when it comes to reliability in new services.
Most successful uses of 20%T are to engineer a transfer, but managers are wise to that and not supportive. That game is actually a bad thing, because it means that to get a transfer requires auditioning, dividing your efforts, and putting your standing on your main project at risk. It's actually a lot harder to transfer to a good project within Google than to get a job at Google. This also means that you can 20%T for the purpose of transferring, only to get screwed on "headcount" and have put your standing on your main team at risk for nothing.
I don't think that your typical, run-of-the-mill manager is going to punish you for 20%T alone, but if the Perf gods decide that he has to stick someone with a "2.9" (bad Perf) this cycle, then having one foot out the door puts you at risk of being the one thrown under the bus. And once you get a 2.9 it's impossible to transfer.
-- Googler saying.