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.

The same issues you flag are similar for PMs.

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).

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+.

Honest question, did that integration benefit your project?

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...

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.

This was true and a very big problem for a while. I started seeing improvement around 2011/2012, when promo committees started valuing grungy maintenance & refactoring tasks more. It is still harder to get promoted doing maintenance work than high-profile launches, but the gap has narrowed significantly.

Possibly not coincidentally, this was also the beginning of Larry's "More wood behind fewer arrows" push.

In my experience it helps if you can demonstrate the impact of your maintenance work. "Cleaned up the configuration" is worth something. "Improved the configuration to make a certain class of misconfiguration, which has caused several outages in the past, impossible" is worth much more.

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!)

It would be fantastic if customer reviews were included in the peer review process, because there have been a number of times where things were launched for Google Apps customers that became a major cluster, or which actively strove to remove heavily used features, or which otherwise broke many companies' processes & use cases.

This would be challenging to do fairly. Visual redesigns are almost always received negatively because they force users to learn a new UI, but they are very necessary because otherwise your product starts looking very dated compared to competitors, which prevents non-consumers from adopting it. On the other side, niche features are usually received very positively because it's easy to make a product that suits every user's needs when you only have a few users. (This is behind YC's advice to "do things that don't scale" when you're small.) Internal refactorings and cost/performance improvements aren't user-visible at all.

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.)

Here's a specific example from last week. Last week, Google royally f'd up the release of the new Login Challenges interstitial, which wasn't supposed to be presented to SSO domains but was. This caused much consternation, especially since because this was primarily a consumer-focused feature, there was no advance notice given to Apps domain admins.

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. :) )

This problem isn't limited to Google. Everyone remembers the creator, nobody cares about the maintainer. There's a reason why software developers in general earn more than QA.

A lot of mgmt philosophies used in the corporate world attempt to recognize this structurally. But it rarely reflects in the pay packet. Banks for instance are an exception and maintenance and BAU staff are generally paid the same as developers.

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).

Is there any company where churning through a list of bugs and maintenance projects will get you further in the long term than launching new things? Hacker News generally praises "ship it" culture, where experimentation and measurement is prioritized as the way to succeed. This is considered a good thing in most places and the incentives are not unique to Google.

Facebook. See http://www.quora.com/For-top-technology-companies-what-of-th...

Consulting. Not a longterm in the company thing, but there is money in coming in and cleaning up others messes and get them on a path that can be maintained.

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.

"Hacker News generally praises "ship it" culture, where experimentation and measurement is prioritized as the way to succeed."

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.

It is general problem, many companies do the same mistake. Programmer willing to do those needed useful maintenance things is penalized by a.) having less exciting buzzwords on cv, b.) having lower salary, c.) having less interesting work.

Surprise surprise, everyone avoids maintenance.

This is why the supposed meritocracy, promotions, and market economy of effort is a sham at corporations. In the real marketplace, support makes income happen. If a person is the owner of the company and does the necessary support, they reap the profits. But employees are not owners and corporations are not fair. The idealized marketplace is where everyone is their own corporation and the real marketplace determines exactly how rewards are allocated. In the real marketplace seemingly dumb ideas and banal work are both rewarded greatly if they have true value. In the corporate environment that will get you stuck in a career-ending dead-end job.

Totally agree with you Plus the game is further rigged in favor of the corporation >If you want to get promoted, just start acting like someone at the next level up. Imagine 5 people working their ass off to go to the next level only 1 gets promoted But company gets more throughput for free

FWIW, the entrepreneurial market is the same. Just s/company/customer/. You have lots of firms all competing for the customer's business, but only one will get the contract.

But no one holds you at that job though, right?

Just the need not to be homeless.

EDIT: I'm not trying to be snarky. I literally work to pay for rent and food. Sorry if this bums you out.

Please consider the following scenarios, all of which are things that really happen.

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.

Cool, maybe you can share your trust fund with me. Maybe if my startup fails I can go live with your family members since I will have lost my life savings.