However, I would agree that it is "as good as dead". What killed 20% time? Stack ranking.
Google's perf management is basically an elaborate game where using 20% time is a losing move. In my time there, this has become markedly more the case. I have done many engineering/coding 20% projects and other non-engineering projects, with probably 20-40% producing "real" results (which over 7 years I think has been more than worth it for the company). But these projects are generally not rewarded. Part of the problem is that you actually need 40% time now at Google -- 20% to do stuff, then 20% to tell everyone what you did (sell it).
I am a bit disappointed that relatively few of my peers will consciously make the tradeoff of accepting a slower promotion rate in return for learning new things. Promotion optimizes for depth and not breadth. Breadth -- connecting disparate ideas -- is almost invariably what's needed for groundbreaking innovation.
It's implicit because I'm not coding to a spec. I've got an area of responsibility and some general goals the people above me would like to see accomplished. If I have an idea, I try it out. I could see someone in a more spec-based, feature-driven role wanting to have time to work on their own features off the spec.
On the other hand, I personally don't want conventional 20% time. I don't really like working on two projects at once. One fills my head and all of my ideas relate to it and a second one gets in the way. I once again understand that some people can work on two things at once and enjoy it, but hey, I'm not one of them.
So I'm not sure there's an actual problem. If most of your engineers are like me, and are working with a great deal of independence on a project they find interesting, why would they want 20% time?
This is just a "They did WHAT?" moment for me. Like, wow. Stack ranking >_< Seriously?
It is a bit puzzling to me that Google was pretty innovative in a lot of areas, including HR policy, but the perf stuff is unimaginative and rote. Then again, I don't necessarily have a better solution for a company of its size.
From a personal perspective I think it's great to give up a level and 10-20% salary for increased time learning things. Google already pays at least 10-20% more than other places which DON'T have 20% time.
From the company perspective, I think it is sad that 20% time is becoming less and less relevant.
That's not what promotions are at Google. If you want to become a manager, that's called a ladder transfer, not a promotion. Promotions are basically for paying you more for making computers do more magical things. You are never asked to do anything other than software engineering, unless you want to do something other than software engineering.
(Note that software engineering is more than opening up an editor and typing in code, though.)
Google's higher engineering ladder rungs are defined more by scope of influence than the excellence or profusion of individual code. At higher levels, engineers will tend to spend more time communicating with and influencing other people.
Some people are happy to stop at level 4 or 5, where they can mostly do their own thing. They can do good work, they can feel they have time for 20% projects, and (to some extent?) they can keep getting raises and bonuses.
HR/MBA types value titles, buzzwords and other nonsense because most of them are incapable of actually parsing a technical resume. So, if you're going to look for a job, filling in your title as "developer" over a period of multiple years is a losing strategy.
By the same accord, without titles, buzzwords, etc as an engineer I won't be able to differentiate between resumes of a regular graduate level physics educator and one who is capable of nobel prize level research.
if you're in the position to make a hiring decision and can't make such differentiation - well, yep, that is what we have in software engineering. In physics the situation seems to be a bit (though not much) better, in part because of CVs, in part because the network is smaller.
First of all, I haven't seen any evidence of the "fire the lowest X% of the stack rank" attitude which I saw at IBM and which has been reported to happen at Microsoft. Because Google is so selective during the hiring process, I don't think it's as necessary at companies where dead wood accumulates and so the Jack Walsh/GE philosophy of there's always deadwood to be eliminated isn't as applicable. (Sure, there will be PIP plans for problem employees, but that's on a case by case basis, and not driven by statistics.)
Secondly, the stack ranking is just one of the inputs in your perf score, which in turn drives salary increases, bonuses, and equity refreshes. It is also just _one_ component in the promotion process, which is handled outside of the management chain, by committees of engineers that are typically level N+1 and N+2 of the people being considered for promotion. Speaking personally, as far as compensation is concerned, for which the perf score is the primary driver, of course money is important, but it's not my primary motivator, and I'm paid generously enough that whether I get an extra X% isn't going to force me to try to get that extra bump in my perf score. It certainly wouldn't cause me to try to sabotage my colleagues --- and by the way, the stack ranking is also done by your team members and merged into the results (it's not just a stack ranking done by the managers), so trying to get a higher perf score by not being helpful to your colleagues is not a winning strategy.
Finally, I've touched a bit about the promotion process, and certainly at the higher levels, promotion is done by your potential future peers, and is more about recognizing the fact that you are already performing at the level of a Staff Engineer, or a Senior Staff Engineer. Your manager will write a recommendation letter, but certainly at the higher levels, it will be your future peers across the entire company that will be judging whether the work you are doing has the impact and a wider scope which is the hallmark of the higher ranks of the engineering ladder. And of course, if your 20% project happens to have a high impact or affects teams across the company in a positive way, that is something that you can write up in your promotion package, and they will consider it at promotion time.
Also, once you get to Senior Software Engineer, there is no expectation that everyone has to keep on climbing the promotion ladder. There is no "up or out". If you want to do really great engineering work, but it's work that isn't something that fundamentally affects the company's bottom line, or isn't of broad scope, that's OK. You won't get promoted, but at the end of the day, how important is that? You can only buy so many toys, after all, and if you are doing work which is fulfilling and you have other things in your life which is giving you great satisfaction, who cares if you never make Distinguished Engineer or become a Fellow? And that's yet another reason why stack ranking may not be as important.
The bottom line is that "stack ranking" as done by Google is pretty different form what you might think of as "stack ranking" as practiced by other companies, so it's important to keep that in mind.