Thanks for this, I'm going to use the sports analogy in the (near) future the next time I discuss this with anyone.
It's all politics. Estimation is a purely political game by EMs/TPMs/PMs to try and shirk responsibility for engineering outcomes.
Here's another neat tack to try in this conversation. Ask for individual examples of "good estimators," and ask for details about what makes them good estimators. You'll rarely (if ever) hear that someone was so accurate that it materially impacted a project in a positive way. What would that even look like? "I was sooo accurate that the client success people were able to say that our new product would be ready 6 months ago, and now didn't have to send a follow up email to update the timeline!!!" The only answers I've gotten are that people who are good at estimating are the ones where nobody ever really has to look at their schedule and there is no drama because they are always getting things done. This is highly contextual and rarely has to do with that person's individual estimating skill. It has to do with their project, team, EM, PM, experience relative to teammates, etc. Recently I was given an example of a client-side developer who is far more experienced than the back-end guy building his API, so he's always just sitting around waiting for the API to be finished to build his features. He almost always does 3/4 of his tasks ahead of time and then just waits for the API to be done and puts his ticket in as completed at that point. So he's not really estimating at all, and he's not accurate, it's just that the project is bottle-necked on the back-end dev speed regardless, so nobody ever cares about his estimates.
It all just seems so wishy-washy and bullshit. It's just about pushing people to work hard and get more done ("you need to hit your estimates, think of them like commitments!"). Framing this all as somehow single-handedly the engineer's problem is just a sign of someone who doesn't know how to operate a software development team effectively. Estimation is a team effort in scheduling, delegation, planning, and communication.
Why in the world (if not politics) would anyone invent a concept where it punishes someone who over-achieves and chooses to work harder for a short period of time? ("you should try to be more accurate about estimates, even if you have to slow down your work, and over working like this leads straight to burn out, be careful!) It's all just nonsense invented by MBAs who have no actual experience in anything except inane "policy" and "oversight."
Software project estimation is a real thing, but it has nothing to do with one person's ability to predict the future. It's an analytical data methodology far more than an individual, experiential skill.
It's all politics. Estimation is a purely political game by EMs/TPMs/PMs to try and shirk responsibility for engineering outcomes.
Here's another neat tack to try in this conversation. Ask for individual examples of "good estimators," and ask for details about what makes them good estimators. You'll rarely (if ever) hear that someone was so accurate that it materially impacted a project in a positive way. What would that even look like? "I was sooo accurate that the client success people were able to say that our new product would be ready 6 months ago, and now didn't have to send a follow up email to update the timeline!!!" The only answers I've gotten are that people who are good at estimating are the ones where nobody ever really has to look at their schedule and there is no drama because they are always getting things done. This is highly contextual and rarely has to do with that person's individual estimating skill. It has to do with their project, team, EM, PM, experience relative to teammates, etc. Recently I was given an example of a client-side developer who is far more experienced than the back-end guy building his API, so he's always just sitting around waiting for the API to be finished to build his features. He almost always does 3/4 of his tasks ahead of time and then just waits for the API to be done and puts his ticket in as completed at that point. So he's not really estimating at all, and he's not accurate, it's just that the project is bottle-necked on the back-end dev speed regardless, so nobody ever cares about his estimates.
It all just seems so wishy-washy and bullshit. It's just about pushing people to work hard and get more done ("you need to hit your estimates, think of them like commitments!"). Framing this all as somehow single-handedly the engineer's problem is just a sign of someone who doesn't know how to operate a software development team effectively. Estimation is a team effort in scheduling, delegation, planning, and communication.
Why in the world (if not politics) would anyone invent a concept where it punishes someone who over-achieves and chooses to work harder for a short period of time? ("you should try to be more accurate about estimates, even if you have to slow down your work, and over working like this leads straight to burn out, be careful!) It's all just nonsense invented by MBAs who have no actual experience in anything except inane "policy" and "oversight."
Software project estimation is a real thing, but it has nothing to do with one person's ability to predict the future. It's an analytical data methodology far more than an individual, experiential skill.