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