At some point, the cargo cult are the promo reviewers and then the two become the same thing.

The reviewers presumable have access to the true metrics.

What if I told you these are their "true metrics?"

If a company doesn't have consistent metrics for performance reviews uniformly across teams, get out of that company yesterday. That's just a hotbed of nepotism.

Please give an example of a metric for performance review for software engineering.

Conceptual examples (not looking to argue about the specific bar):

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"

Those are requirements, not metrics.

With sufficient granularity there is no difference. I can't give exact quotes without violating NDAs but variations on these have been the performance review standard at every major company I've worked at or known people who work at.

Agreed.

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.

>Conceptual examples (not looking to argue about the specific bar)

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.

What do you mean by "true metrics"?

The metrics which determine if someone gets promoted. Those decisions are being made by some group, presumably with guidelines. If the process for getting promoted is "this group does whatever they feel like" that company is a disaster and you need to get out.

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.

It’s a meh from me - either is bad. If you are in a highly complex and professional field (in the traditional sense of the word) single axis optimization hollows out the whole craft. Engineering is delicate and constant battling of tradeoffs, and decision consequences are often delayed by longer than average tenure, let alone a 6 month perf cycle. The more you McKinsey the process, the more mediocre and incoherent the results.

You get what you measure. You can't hire smart motivated people and then be surprised when they figure out to optimize for their rewards.

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.

> You can't hire smart motivated people and then be surprised when they figure out to optimize for their rewards.

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.

According to your other comment, then, a company that "lands stable customer-loved products" would be a "hotbed of nepotism" that people shouldn't work for.

Nonsense - you can have documented metrics which are known and tied to performance.

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.

Nonsense were a lot of your replies in my experience :), this "measure everything" is very much another cargo cult. Software engineering is complex, people are complex, thinking you can come with a true metric and who doesn't have it doesn't know what they're doing is the nonsense in my world view.

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

Either way -- 'twould seem that if such a level of microstrategizing is what monopolizes one's attention on a day-to-day basis -- then one is definitely in the wrong place.