The Google career path, Part 3: Performance reviews and promotions
matt-welsh.blogspot.com
matt-welsh.blogspot.com
Support is just as important as innovation. There's no point in having great ideas if they aren't maintained. Google doesn't seem to get this...
I wasn't at that level but this was super true for L5-L6ish engineers or above. Yes they had to tackle bugs, but they weren't getting to L6 unless they led an effort for a big feature within a project, or L7 unless they launched a project with a solid impact.
Management made efforts to give more weight to refactoring, but it seemed like a token effort. Refactoring was thankless unless it was a truly gargantuan change.
Working at google was great, but the engineering incentive structure is far from perfect.
The same issues you flag are similar for PMs.
OTOH, this did subsequently simplify the system a lot, and enabled follow-on features that wouldn't have been feasible under the original design. Our original design defined an author as a clique of webpages that all linked to each other using rel=author|contributor backlinks; defining a primary key is challenging in this situation, because you have to carry along the identity of the clique throughout the system. Requiring G+ let us key everything to an author's Google login, which then opens up the possibility of other systems using that data easily. It let us display the author's profile picture (which was the primary "boon" to get authors to participate), and connect their works to their G+ profile so they could easily advertise everything they'd done. It helped in marketing and using the product, because basically nobody outside Google (and only like 4 people inside Google) actually understood the author-closure stuff.
Understand, also the historical context behind this. 2011 was the year of "Open systems lose." Android (the open-source operating system) was playing catch-up to iOS (the closed one), and arguably only caught up because they were willing to close off much of it. Facebook had used GMail's "download contacts" feature to populate their own social graph, and then systematically cut off every attempt to crawl their own, also disallowing users from exporting their friends list to Google. OpenSocial had been trying to gain adoption for 3-4 years and failed so badly that Google+ was necessary. OpenID was dead-on-arrival, and Facebook Connect was taking over the web. Google had just sunk two years into providing real-time search of Tweets, only to have Twitter pull the plug on the deal and sink the project.
So in hindsight, it's difficult for me to say that the execs made the wrong call. I was kinda ambivalent at the time - I wasn't pleased, but I could see the reasons behind it and agreed to help out with the implementation. A number of my teammates were furious and quit the project, moving to other departments.
It was even worse at British telecom where there might be only 20-25 MPG 4 (L4 or r 5 in google terms) slots every 18 months or so for all of Systems Engineering (a division with more employees that goggle has now) - competition to just get past the paper sift to an actual interview as brutal.
Its interesting my boss said well if you get an interview we think you can do the job its just deciding who gets a promotion or not
Or so I've been told anecdotally ... personally I have yet to be promoted or experience a bonus cycle where I hit exceeds...
And reducing the pay increase quanta by 1% is a lot in a large company.
EDIT: I'm not trying to be snarky. I literally work to pay for rent and food. Sorry if this bums you out.
You spend a third of your life working, if you're only doing it for the money then I feel you're quite literally wasting your life. It doesn't particularly "bum me out", but I do feel sorry for people like you.
1. The best-paid job you can get pays just barely enough to keep your family in decent conditions. So you take that job, for the money. It costs 1/3 of your life, but the benefit is that your spouse and children get not to starve or live in squalor. Wasted?
2. You give a substantial fraction of your income to charities that save the lives of desperately poor people in Africa. You take a well-paid job, for the money. It costs 1/3 of your life, but the benefit is that every year you're working one more poor African gets to live instead of dying.
3. You have a choice between a job you like pretty well, and a job that's merely OK but pays a lot more. You take the well-paid job, for the money. It costs 1/3 of your life (or, more precisely, 1/3 of your life is somewhat less satisfying than it could have been), but the benefit is that you retire at 50 instead of 60 and have an extra decade of (according to taste) leisure, or working for the public good rather than for money, or starting your own business with the security of knowing you won't starve if it fails, or whatever.
All of these involve working "for the money". The only one of these people I'd feel sorry for is the first -- and not (as in your remark) because s/he is making a tragic mistake, but because s/he is in a difficult situation where no course of action is satisfactory.
For myself - I've got projects I've helped as above. I'm not a maintenance/sustaining kind of guy, but many companies gamble on a "make it work now" scenario and then need help after the fact to bring it back to reality for long term support.
It's not sexy, I don't do it often, but if someone has an interesting challenge to get from X to sustaining, I'm happy to hear and maybe work something out biz wise.
HN has a VC/startup focus. Maintainable code means a lot less to a quickly growing (and possibly pivoting) startup because fast growth almost always outruns the maintenance burden.
On the other hand poorly written and maintained software can drown a normal business. These companies typically have 20-30% margins and so even doubling the cost of maintenance can remove any profit.
Possibly not coincidentally, this was also the beginning of Larry's "More wood behind fewer arrows" push.
IMHO impact is really what matters most. I think where some people go astray is they rewrite a block of code but fail to convince the committee that there was a real, tangible benefit to the company in doing so. I don't believe this is a problem with the promo process- I think you get better engineering outcomes when people can justify the impact of their work. (People like to rewrite things, even things that don't need to be rewritten!)
What's good for the customer isn't always what's good for Google as a company. Usually when Google has done things that piss off a lot of users they've been alerted by significant internal feedback that users will be pissed off, and done it anyways for other reasons. (The one exception I can think of was Buzz, which was beloved internally and reviled externally.)
This ties into the second big problem re: Apps administration and Google's product roadmap / release process: there is almost no correlation between feature requests Apps admins make and their mapping onto a product roadmap. Additionally, for features or new services that are kept secret as a business strategy, even Apps admins don't get any advance notice. The first we see them is when they are released to production. It is entirely unclear what the relationship is between Bill Hippenmeyer's team, the actual PM & Apps product engineering teams, and the Google Enterprise Connect team, and by all outward appearances there is almost no strong link whatsoever.
So, regardless of how Google handles things on the consumer side, those behaviors adversely affect paying customers ... and when you are paying millions of dollars per year (as an alternative to paying Microsoft or IBM millions of dollars per year) that's a big turn off. Google is far more opaque re: roadmap than traditional vendors.
(I'm not bashing all things Google, just this one thing. I'm still a huge fan. :) )
My current client see productisation and day to day running and ongoing maintenance as the hardest part of a project (as much to internal structural failings as anything else).
Surprise surprise, everyone avoids maintenance.
Genuine question: is that why you went in a completely different direction with Capn'proto than protobufs?
I actually primarily quit to do sandstorm.io, and did Cap'n Proto more on a lark, although it turns out to be really useful infrastructure on which to build Sandstorm.
Not at Google, but this is how I've always treated my career. Kind of a step beyond "dress for the job you want."
Job-hopping (done within reason) is entirely underrated. Your salary will rise at a dramatically faster rate than if you stuck around one place, your responsibilities too, and best of all you get to learn how things are done across the industry.
Aw.
Someone said exactly that to me when I was at Google. That's kinda how closed allocation works.
What I always tell people: If you want to get promoted, just start acting like someone at the next level up.
At any company, that's the quickest way to get fired. Getting into a turf war with someone with a much higher title? Not a good idea. To be honest, if I were to do Google again, I'd have kept my head down and said "Yes, sir". It can do a lot for your career to work there, but it's not a place where you can safely overperform.
However, there is a way to provide private feedback that can only be seen by your manager; in my experience this backchannel is rarely used.
"Yes, I realize that a murder count of 2,500 in a city of 1 million is horrifying. But look on the bright side. That means there were 997,500 people who were not murdered last year."
Managers take all of your reviews as input and determine a performance rating, which is a score in one of five buckets to indicate how well you're doing overall.
As of 2011, you actually get a score between 1.0 and 5.0. Almost everyone is between 3.0 and 4.0. The buckets are very large. "Meets Expectations" is everything from a 3.0 (acceptable for new hires, but damning if you've been there for a while) to 3.4 (slightly above average). If you're in this bucket, you don't know if you've been marked as a loser (and rendered unable to transfer) or are getting 65th-percentile ratings. You can literally waste 18 months on a loser project only to find you can't transfer because your boss gave you 3.0's.
These scores are also calibrated against other managers across the organization, to prevent managers from biasing their scores -- an individual manager can't game the system.
That's a nice way to present stack ranking. Each boss gets a finite number of calibration points and has to pick who does well and who doesn't. If he gets a crappy allotment and desperately needs to use all his points to promote the guy who'll do a startup unless bumped, you could get stuck with a (career-ending) 2.9.
----
The important thing to remember about Google's promotion process is that it's bicameral. Manager-assigned calibration scores are one component. Peer reviews are another. You need both to advance at Google. Google provides multiple paths to failure, not multiple paths to success. If your manager likes you and gives you 4.0+, you can still get dinged for lack of visibility. On the other hand, if your manager is giving you shit for calibration scores, all the peer review in the world won't get you out of the muck. I've known many Googlers to damage their careers by playing their manager but not the crowd, or vice versa. You need to play both games at the same time.
For a better analysis of Google's promotion/review system, read Piaw Na's essays, such as this one: http://piaw.blogspot.com/2010/04/promotion-systems.html
This is also worth reading: http://valleywag.gawker.com/eric-schmidt-personally-ruined-g...
An "occasionally misses" expectations is by no means career ending. It's just a warning sign. It's not by itself a fireable offense (as an aside, even being fired by Google won't ruin your career, a friend of mine with a bad manager at Google got fired. He ended up pre-IPO at Twitter, and he is definitely doing well). I had an occasionally misses as L4. For me, I took it as implicit permission to get more attention from my manager. I'd bring problems to him sooner and make sure to be less stuck, including burdening him with more mundane problems I was having, and giving him more status to make sure I was moving in the right direction. I quickly hit meets, and I eventually hit L5.
I told them "That is not how we do things at Google. If you believe what I'm working on is not useful, communicate what the priorities are for the project and I will pick something that is both interesting to me and helpful for you. If there is nothing on this project that fits into that category, I will find a new project."
In both cases, they looked abashed and backpedaled.
This is what an L5 would do. Try to work directly with the people involved to figure out a compromise solution, and if that fails, exercise other options. And sure enough, I was promoted fairly soon thereafter.
--This sounds really bad. Like a slave trying to move more bricks to show slave-owner that he is not being paid enough.
I'm joking, but not by much.
Is more often the case. It's interesting to see folks who act on that thought and find out they were mistaken. A manager of mine once quipped "The grass is always greener somewhere else, but sometimes that is because it's astroturf."
Google for the term velvet handcuffs or golden handcuffs.
At Google you were basically expected to make all the decisions you had good information on, and you had access to a lot more information than people did at most companies. I launched the [blink tag] easter egg by socializing my ideas around a few peers who said "Cool idea, go for it", implementing it in my spare time, getting a code review, and then e-mailing PR, legal, and Amit saying "Hey, I'm planning to launch this easter egg in a couple weeks, any objections?" I had approval powers for putting stuff up on google.com myself, so in theory I could've launched it with just one other person's code review, but if you launch without approval and things blow up you (and your peers) will never ever be able to do cool stuff again, so it's a nice courtesy to keep the execs in the loop. (Although this rule has been bent before - [do a barrel roll] was launched without any execs' knowledge.)
But Matt is writing primarily for Researchers who leave academia for industry. They are a special class of people who tend to be more.... experienced with pushing back against management to achieve their research goals. However, the same idea applies equally to motivated low-level engineers who want to get things done.
Why do you think having levels prevents junior people from discussing ideas with their managers? Everybody has the chance to discuss anything with their manager at the weekly one-on-one meetings which are being held with people of all levels. Also, like the post says, your level determines your compensation, but not the potential impact you may have on a project. Nobody's going to actively prevent you from working on something because you're "not senior enough".
Check out workplace on stack exchange a lot of the questions are about friction between juniors and seniors.
One of the first things I try to impress upon new managers is that their job is not about telling people what to do, rather their job is about getting the most done with the people they have on the most important parts of the problem. They have to take the whole set of possible things that could be worked on, and figure out the important ones to invest in. Sometimes the importance comes from being or staying competitive, sometimes the importance comes from keeping things alive long enough to get to the next milestone.