[lumpypua]

Former employee here. I had a very opposite experience. New features were key for promotion. Performance/stability tweaks or bug fixes would only add to your promotion chances if they had a demonstrably large impact.

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.

[niketdesai]

I'm a PM and feel this is the case as well. I've seen massive migrations as one type of 'maintenance' wrapped as a launch that led to promotions, but generally the best way to go about it was join a rapidly growing project (G+) with user-facing impact.

The same issues you flag are similar for PMs.

[kbart]

That explains. I guess the key to the promotion this year is to integrate your project with G+ (bonus points if user face no choice).

[gwillen]

I see you're getting downvoted for this, but the only thing that's wrong with it is that you're a bit late on the schedule. If you go back to the 2011 era it was absolutely true.

[nostrademons]

I wanted to say "As someone who got promoted in 2011, I can concur", but technically I got promoted about 3 months before I integrated my project with G+.

[ProAm]

Honest question, did that integration benefit your project?

[nostrademons]

Perhaps - it's hard to say. (The project was Google's Authorship program.) The product would've been a very different one without it. We had designed a federated system that worked at the level of the Web and let any website serve as an identity provider. In theory, this was going to change how the web worked, and that change would also be accessible to other search engines and spiders. We didn't accomplish that. The request to make it only work with G+ basically involved restricting that system so that one of the URLs must be "plus.google.com".

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.

[walshemj]

The stack ranking element is also open to abuse and capture by outsiders i.e. only so many L3 to L4 slots available in any cycle as some hr been counter is getting a bonus for reducing the pay quanta.

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

[skj]

Regarding the bean counters, keeping promos down doesn't help their budgets as much as you might think. The bonus you get for "exceeds expectations" brings you approximately to the "meets expectations" total compensation of the next level up.

Or so I've been told anecdotally ... personally I have yet to be promoted or experience a bonus cycle where I hit exceeds...

[walshemj]

Tell that to HR and bonuses can be taken away a lot easier than pay.

And reducing the pay increase quanta by 1% is a lot in a large company.