> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

This is but a different kind of a rat-race?

Code quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up.

Is that something that should've been caught in integration tests? Why did it pass review then?

As long as it's not a pattern, it's not a problem.

If something super severe happens - that's an organization-wide problem...

That sounds like a horrible place to work!

> If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts.

Which assumptions are behind that statement?

Does the team have uniform experience working in a single product? That statement feels more applicable here.

Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.

The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.

We usually start by discussing the outliers on both sides.

This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).

Yes, that's exactly what I meant to describe.