This is a very good comment and does reflect my experience. As engineers, we're the only people who can estimate something close enough, and it becomes our job to do that while taking into account the risks.

Our bad assumption is in thinking that only the final output matters, regardless of when and where it is delivered. Like saying that it only matters if the train arrives at the station, regardless of when it does.

The problem is anyone depending on us downstream will get impacted. And yes, estimation is tough, requires foresight, and maybe a lot more things, but that's what being a professional means.

Thank you! And yeah, I think a lot of software engineers miss the forest for the trees in assuming that estimates are "only estimates", in what is implicitly assumed by others (who may not have as much context) when eg communicating dates, and in the assumptions they make regarding constraints that may not actually be constrained (eg the ability to add more people to the project or partially release/launch it with reduced scope, with the remainder to be added later). It's like, people forget that a few weeks of one engineer's time costs their employer tens of thousands of dollars, and that multi-quarter/multi-person projects literally are $1mm-$10mm+ endeavors.

A lot of less experienced engineers also are just bad at estimating and don't do a good job clarifying blockers/risks/etc when participating in planning poker with a scrum master/manager, who may also not be very good at their jobs. Obviously a lot of what I wrote is overkill for "you said this was only one story point but it actually took you two days!" but I think this environment being most SWE's first/only exposure to estimation causes them to take the opposite lesson than what they should (that estimation is awful/bullshit, it doesn't matter if you blow past it/everybody always blows past it, you will be argued with if you estimate something as too high, you are incentivized to excessively overestimate to keep your workload low / prevent people getting angry). But that's really only a productive mindset to have when the stakes are low.

I do think leaders, from executives to managers/tech leads/"scrum masters", should be more in the habit of proving estimates/deadlines for risks and ranges than they are. A lot of the time these things become games of telephone were eg an engineer comes up with a plan with all the risks identified and detailed completion dates, and then their manager converts that into a single date given to the CEO as a reasonable deadline. That said, if you actively communication the current ETA and risks proactively throughout a project you also end up with a convenient paper trial and give people multiple opportunities to correct miscommunication.