If you ask developer A how long it will take, the best outcome for them is that they AND EVERYONE ELSE go high. So they should go high.
BUT if everyone else goes low, but they go high, then they look bad. So they're forced to go lower. But then not too low, or they won't be able to deliver in time.
So perhaps this settles on an estimate that's "as low as possible but no lower"?
But it's really not. The best outcome for them is that they are 100% accurate.
Now, I understand that that's generally not feasible, but assuming that you need to pad everything by a huge amount is part of the problem.
As a general rule, I've found that the kind of answer that gets the best response is on the order of "about X time to complete development, Y to get through testing, Z if you need any documentation, release notes or user instructions, I think A, B & C are risk items that could delay completion. If Sally and Jared aren't around for us to ask questions, that will also delay things so we need timely responses from them."
Give good answers and you'll find people take you a lot more seriously.
I've successfully talked stubborn execs out of bad ideas by framing things in terms they understand (risk, costs, reputation). And by doing so earned more respect which I can further leverage in the future.