It makes sense to always communicate the best case, not the most likely expected case. If you allow worse-than-best-case to become the plan/expectation, you'll fill the time and often exceed it.
As an engineer, this feels strange, because you might expect to be trying to be as close to correct as possible when you give a date. But that's not the goal. The goal is to create a narrative and sense of purpose that gets you there as quickly as possible.
Finishing something 6 months behind schedule in 18 months is still better than doing it "only" 1 month behind schedule in 19 months. Of course, you also need a risk analysis of the worst case, and to understand the financials and be able to survive a reasonable range of potential delays.
Gotta say you're completely ignoring the negative toll this takes on morale. I hate unrealistic timelines, and I've been on almost every side of the table (engineer, engineering manager, product manager, program manager, even CEO for a tiny startup). Internally, only the most junior engineers tend to believe the timelines for these ambitious R&D projects. And it leads to senior engineers just getting tired of endless politicking around hype instead of actually focusing on building the thing and being honest about when it will be ready. To be a little less professional - the timelines are usually fucking bullshit.
I've quit before because of this very reason. You're allowed to disagree with me obviously, but I don't want to work with you if you honestly believe this is a good policy.
There’s also the effect where engineer A says “two years” and has a solid plan to hit that date, but engineer B says “6 months” without actually having a plan.
In my experience, engineer B usually gets to take charge of the project, and inevitably takes 3-4 years before the project ends, having failed to deliver anything that works.
Bonus points if the project is then declared a success by the pointy haired boss that bet on engineer B.
If you hand out ownership/status/power/money based on unsubstantiated project estimates, I’m not sure you can ever expect very good or happy results.
It’d be much better if all of the characters in that example sat down and decided what the most realistic best case with a solid plan looks like, and took responsibility for communicating it together, and you find a different way to decide who gets to own it.
The negative toll comes when timelines become deadlines or there’s too much pressure to hit them. Those are not good ways to manage or motivate a team.
It is essential to create teams that are aware of and talk about the most optimistic timelines, but where everyone knows the people on the front lines doing the work are in control and set the pace.
This is very achievable if the starting point is empowering people, removing roadblocks, and increasing the team’s capabilities and leverage, rather than trying to impose timelines.
As an engineer, this feels strange, because you might expect to be trying to be as close to correct as possible when you give a date. But that's not the goal. The goal is to create a narrative and sense of purpose that gets you there as quickly as possible.
Finishing something 6 months behind schedule in 18 months is still better than doing it "only" 1 month behind schedule in 19 months. Of course, you also need a risk analysis of the worst case, and to understand the financials and be able to survive a reasonable range of potential delays.