Would the goal be to promote everyone? Who's going to do the work they all used to do?
Several years back, you had to also eventually get to L5. This was more affected by promo culture, but was also largely unenforced, which is why they get rid of the formal requirement to get to L5.
I'm unsarcastically glad that you had a different experience at Google than me. This was not my experience, nor the experience of anyone else on my immediate team.
Ideally this gets people fired, not promoted. Google explicitly calls out "solutions to hard problems are easy to maintain" on its ladder, for example. People can fail to identify these cases, but the intention is to promote based on hard problems rather than complex solutions.
However, if you give a reason for building the 2 new services (eg. more extensibility, enables a new flow, easier to use for other teams) then all of a sudden the complexity is justified and you'll appear to have solved a hard problem. No one is going to look super deeply and ask if those reasons are valid and if you even need the extra extensibility or if other teams will use the service.
I've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.
No.
> Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?
No. Grungy work has to get done, but it also won't build a promo case. If a leader isn't finding ways to make sure that the grungy stuff is being completed then they are a failing leader.
If that's "below your pay grade" _and_ you're still capable of doing it, well that's kind of the problem then, isn't it.
Why should I spend a week learning a different domain when someone with experience in that code can possibly fix the bug in an hour? Passing the buck to the right person is the correct answer when you are not an expert and someone else is. Passing the buck too many times happens very rarely, most of the time it is the correct answer, so long as you pass it to the right person.
I can go into anyone's code and fix a misspelling. However if the problem is less obvious someone with experience can take a few days off my time just because they don't have to figure out how the code is supposed to work before figuring out why it doesn't do that.
Two of these are a signal that perhaps you shouldn't be promoted. The third is a signal that you should leave.
In a less generic sense, I think that there are almost always ways to improve incentive structures and encourage people to focus on specific problems that don't directly involve SVPs. Your manager has some control over your rating. If you can argue that "customer happiness" should be a priority and as part of that, end to end bug triage time will impact ratings, you have successfully created an incentive structure that will reward that, without involving anyone who can modify compensation structure.
Is the issue that Google, as a company, is not addressing user happiness enough? Or is the issue that some organization is letting bugs languish? The first is a much harder problem than the second. You don't need to solve the first to fix the second. I stand by my claim that it is feasible to address the first as an L5, that could reasonably get someone promo'd to 6, and you wouldn't need to involve anyone above a director to do it. Of course, doing so would involve writing very little code, because so much of this is procedural and political, so the engineer who just wants to be rewarded for fixing bugs wouldn't take the initiative to solve this problem. But alas.
As a result we ended up doing two things a lot:
1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)
2) de-prioritizing important things that were small in order to ensure everyone had a big project every quarter.
We ended up having to hire contractors to work on the small stuff because it was piling up and causing problems.