"No, it's less effort than that"

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

> "rarely able to actually engage"

I've always hated this sort of talk. The myth that some people are inherently creative, or inherently logic brained, or inherently buisness brained, or whatever, and never the twain shall meet.

I've seen a spectrum in most dev teams I've worked in. Those with good communication, those without. However, I've also spoken to sales, HR, etc people who paint the whole team with one brush and are afraid to come and speak to the scary code people. This, I'm afraid to say, is often because those people were also bad communicators.

I agree there needs to be more awareness of the buisness realities among developers (personally I think it leads to more fulfilled and happy developers, among other things), but I think that can't be placed entirely on developer's heads. They can't know how the sales team's meeting in morocco next week's call might affect things if they have no idea that the meeting is happening, who the client is, what that client means in terms of the industry, the likely things that client might value. They are adults. A couple of onboarding meetings, occasional cross-training does wonders.

And if they did know that? They might be able to quickly throw something together that has a good chance of really impressing that client. Or provide certain insight into what the company's solution actually does for the client.