Some companies I worked at after Google were reluctant to discuss their promotion process in detail, because they saw what happens when people microoptimize for it.
Some companies I worked at after Google were reluctant to discuss their promotion process in detail, because they saw what happens when people microoptimize for it.
I steadily got in better shape as they kept cancelling the projects I worked on and I slowly lost and sort of will to care about my actual job. The quality of my work ended up suffering a lot as I realized just how pointless trying to work there was for me but the pay was too good to want to leave.
Edit: I was unlucky though. I knew some people with more stable projects. I went through 4 cancelled projects in close to 6 years
Write docs that slow things down, don't code/build projects, and do it all in the name of greed and the only justification is that it will get cancelled anyways (probably because no real work was being completed).
Edit: also if Google wanted me to really care about my job more than for self interest that relationship needed to be a two way street. The relationship of the devoted employee and disinterested company is common but to me comes across as a bit pathetic. I did a good job there purely because that's how I enjoy doing my job, if the company collapsed I wouldn't have shed a single tear (that's a lie, I miss the free food)
One of the things that had been problematic at Google is the creation of many more products than are really needed, leading to the infamous Google Graveyard. One of the reasons I have come to like writing design docs for my ideas is that a lot of the ideas turn out to be crap when they get written out. Quite a few are good enough that they have already been done, or close enough, which my colleagues can then inform me of. This is a very lightweight way of trimming out useless projects.
And no, Reader wasn't useless. Different story.
Google could still keep the boring, but profitable products. Just like Microsoft does (although they bundle them).
But it seems that in google promotions are not made for boring things that work.
If you want a team that lands stable customer-loved products, make THAT your performance review. Turns out that's hard to do objectively and consistently.
For example:
* Require features to be launched for a period of time rather than in development or shoved out the door a week before perf
* Have metrics for customer satisfaction and oncall pages be incorporated
Etc.
Have excited engineers, pay them well, have them work on something that is aligned with their career & deliver value to their customers, they don't really need much more than that. All the rest is simply trying to "processi-ze" what is a human
Never said that. I don’t have a solution. Well I have a partial solution, but not complete:
Reward all team members equally for the performance of the team, or even the company. For instance: the pie is divided into 3 pieces: company, team, and individual performance. Candy is given out based on performance of both.
It doesn’t fix the hackable metrics issue, but when people collaborate the side effects are better than when they think of their own promotions, and worse when they’re competing against their direct peers for a fixed bucket of candy per team. Such incentives are directly opposing collaboration between the very people that need to collaborate the most.
Senior engineers will:
* Design a significant project which lands with measurable customer impact
* Demonstrate expertise in at least one core skill outside of coding (test infrastructure, SRE, security, accessibility, etc.)
* Demonstrate leadership by either being a TL, owning and leading team pillar efforts (security review, etc.), etc.
* etc.
Mid-level engineers will:
* Own either a small feature end to end or a significant piece of a larger design
* Contribute to at least one non-coding pillar
* etc.
These generally have more areas and can be further granular such as "low-performing midlevel is X, satisfactory is Y, exceeding is Z"
Just proves the point, this person just cargo culted what makes google so famous in recent years. If you only metric is to launch new projects, you’re only gonna launch new projects. Who’s gonna get promoted for maintenance.
Again, not trying to debate what the specific bar should be, just giving examples of the kind of metrics you can use. What's your preferred alternative? Lines of code? Whenever your boss feels like it? Stuff like that is why no one believes a "senior staff superstar" from the hot startup of the week is any good and requires them to do whiteboarding.
Thus, there are rules, and they are written down. If they're not visible to normal employees, they guess the rules based on who they see get promoted (cargo cult) while the committee uses the true metrics.
It's not like becoming a manager is a secret cult where you're dropped in and you suddenly have carte blanche to do anything. At established companies there are rules and procedures, and while you will likely have access to more information than individual contributors, you won't just be promoting whoever you feel like without having to go through others.