[kyllo]

How about evaluating each engineer's job performance (based on sane productivity and code quality metrics) without forcing them to a curve, where even if your whole team is high-performing, someone will get a bad review and be marked for firing just because it's required that someone gets a bad review?

Jack Welch-style rank-and-yank is cruel and wildly inappropriate for software developers (or any human workers, I'd argue). It encourages political blame-shifting/scapegoating games that distract from the actual work. Just having the practice is also an implicit acknowledgement that your hiring process blows.

Performance curves are just a demented and sadistic way to manage people. They're also the epitome of b-school cargo culting.

[kvb]

The problem with this is that it enables weak-willed managers to claim that everyone on their team is great, serving as a kind of grade inflation that makes true high-performers seem less impressive. As I understand it, the curve is only enforced at something like the VP level, so it's not like a team of 10 great engineers is going to be forced to have 2 people scored as underperforming. Are there 200-person groups at Microsoft where everyone's better than average?

[kyllo]

I'm not convinced that "weak-willed managers claiming that everyone on their team is great" is an actual problem.

And what if they really are all doing great, on a given team? Then no sense in punishing someone just because you have to punish someone.

And if someone is underperforming? Their direct manager's job is to take care of it. If the manager isn't even doing their job of managing people, a grading curve isn't going to fix that.

Also, if it's only enforced at a higher level of hierarchy, then what happens is that it's the junior members of underperforming departments that get the shaft. They probably had the least to do with the team's underperformance, but they also have the least power and therefore the least ability to dodge blame. Shit rolls downhill.