> A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer.

To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates.

A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.

That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.

I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team.

(edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)

Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed.

I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.

I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.