I'm very sympathetic to this, because I've been on both sides. I've been a developer under pressure to estimate things that I don't yet understand, and I've be

I'm very sympathetic to this, because I've been on both sides. I've been a developer under pressure to estimate things that I don't yet understand, and I've been a lead dev responsible for overall project management who needs some sense of how long a task is likely to take, even if is just an educated guess. What you've said is true - time-to-project-completion simply can't be ignored. So far, my strategy goes like this: rather than pressuring a developer to give me a more optimistic timeline, I instead do the opposite, I encourage them to really consider things that may go wrong. I'll sit down and try to talk about the potential overlooked risk. I try to understand the assumptions they're making, to help them become aware of the assumptions they're making. Are they assuming the data feeds they're counting on are available and easy to integrate? Are they assuming a certain amount of support from other departments will be available when they need it? Are they assuming they'll be able to understand and work with an existing code base before they fully immersed themselves in it? This doesn't just improve your odds of getting a more accurate estimate of time-to-project-completion, I find it reassures the developers that you really do understand the difficulty of understanding and estimating a complex task.