Speaking from experience, I see everyone from the team leader to the interns tackling bugs on my team at Google. Furthermore, the engineer with the highest level on my team has done a tremendous amount of refactoring and maintenance work over the course of the past year. Clearly this is just anecdotal, but from what I've seen an engineer who took the initiative to improve performance/stability or significantly refactor old code would have just as good a chance of promotion as an engineer churning out new features.
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.
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.
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.
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+.
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.
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
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...
