20% time isn't dead -- I have been using it at Google consistently for over 7 years, and it has immensely benefited me. You don't need any permission, at least in engineering.
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.
Eh, from my perspective 20% time is both implicit and unwanted.
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?
Well, actually Google has had stack ranking forever, since before I got there. I remember my first manager (as a new hire) was telling me about this weird ritual where managers got together in a room and talked about everyone and wrote stuff down.
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.
You may want to graduate to management or UML architect or be bogged down in valueless meetings, but that's not for me. I just want to make computers do magical things.
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.)
> engineering is more than writing code, and senior-levels of engineering even more so.
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.
Quite a lot has been accomplished by just that, opening an editor and typing in code. It's what it all comes down to, and it's why startups can take the lunch from big corps who lose competency in opening an editor and typing in good code.
Reviews affect salaries even without promotions, and salary ranges are often tied to titles. If you're at the top of the range for your grade, even a good review might get you nothing. Anything that affects reviews - such as stack ranking - is therefore going to affect salaries, and I hardly think it's unreasonable to "give a shit" about salaries.
>I don't understand why engineers who don't want to be managers give a shit about corporate promotions or corporate ladders.
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.
>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.
Promotions and titles play a huge part in a lot of people's self-image, even at Google. While I was there, I heard more than a few engineers describe their near future goals as "Achieve level n by next year" instead of "build this thing" or "Improve this technology" etc. We liked to think we were better than "traditional" software companies like Microsoft or IBM but it was all the same. Corporatism and careerism as far as the eye can see.
It's going to be up to individuals and to a lesser extent, teams, about how much stack ranking really is an important consideration.
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.
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.