To be fair, bad managers (and there are a lot of them out there) often get really angry if you give a reasonable worst case scenario time estimate for a task, even if you can back it up.
I've constantly been on projects where someone said, "This will only be a month of work for maybe 3 engineers." That project quickly becomes 5 engineers over a year because of empty promises.
That said, some of these projects frequently time a very long time because there's dishonesty in time estimates. If they were honest with estimates, you wouldn't have to cut corners. They try to cut corners to push a project through quickly - but it backfires constantly... Which leads to more work rather than doing the more effective and reliable part of lots of non-visible work before seeing visible results.
But when you 1) don't have an constructive relationship between CIO/CTO and business leaders, and 2) offshore everything not to follow-the-sun but purely to save money (and then pay bottom of the barrel even in lower cost regions -- that company still only pays engineers 10-12 lakh in south India), you're going to get an inefficient org creating crap quality software.
> the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently
Interestingly, I worked at a company where teams of engineers were given wide latitude to design, implement, and deliver their features in isolation. The theory was that engineers could be more productive if they were left alone to make the decisions.
I'd say it worked about 1 in 4 times. The other 3 out of 4 times, engineers created their own labyrinth of over-engineering, spent too much time building things as reusable frameworks instead of simply getting the job done, and over complicating the system with unnecessary "Wouldn't be cool if..." type features.
This had the benefits of ignoring the usual variations of software planning. Any development task could take 1 week or 4 weeks (if it goes well or not). This stops being an issue when the planning is quarterly because few weeks of jitter doesn't matter.
The question is then, do we have time to do this task next quarter, as well as the other 3 tasks we scheduled there? otherwise we'll plan it for the quarter afterward.
I (engineer) have experienced exactly the opposite. On Thursday I say "It will most likely take me a week; I cannot possibly have it done in less than three days; if X is true -- which I can't know yet -- it will be more like two weeks". And that becomes a commitment to have the code on master by next Wednesday.
Perhaps I've just been unfortunate, but most of the time when I have given qualified or worst-case scenarios, I have been pressed to assume the best, and that's what gets written down.
Very few people involved understand how difficult it is to estimate work for some/most projects. If you haven't explored the problem space pretty well, you can and will run into problems that are unique and very troublesome. And you can't know that ahead of time, except in a very hand-wavy way.
The post was more of a metaphor than a concrete example.
However, as a manager I can’t count how many times my team has declared that they can do something in under a day only to have it become a part-time job for someone to maintain indefinitely, or a multi-week rabbit hole as they debug some unexpected behavior, or technical debt as they neglect to document their solution, or a productivity bottleneck as everyone else must now either learn Terraform or wait for the Terraform guy to be available to help and so on.
When I transitioned from IC engineer to engineering manager, I quickly learned that engineers frequently assume the best-case scenario for their time estimates, while managers end up planning for the worst-case scenario. The catch is that it’s difficult to tell an engineer that their time estimate could be an order of magnitude or more short of a realistic estimate without implicitly insulting their abilities in the process. ICs also quickly forget that many of us managers were once over-optimistic IC engineers as well.