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.

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.

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.