The easy part first: there’s a technical red flag in your post: I shudder at your mention of “mistaken estimates” – it’s an estimate, it CANNOT BE MISTAKEN, that’s why it’s called an estimate. It can be off a little, it can be off a lot, that’s why it’s called an estimate. If you are taking estimates as gospel, that’s going to be one of the main problems that “your” developers are having with your style.
However, I 100% agree with you about the difficulty of communicating with developers. I had a revelation several years back, as a developer in a project management training. I saw several of my fellow developers absolutely railing against management after an open atmosphere of discussion was created (management was present here). Everything that was wrong was the fault of the managers in the eyes of the developers.
The kicker was that management had no idea about nearly all of the huge issues that were raised that day. Developers were assuming that it was all so obvious that management couldn’t possibly have missed it, and management was assuming that developers would tell them what they need.
Therefore, IMHO the first part of the answer must be to let your developers know that you are not psychic, and in fact probably downright stupid when it comes to the technical side. You are relying on, counting on and trusting them to come to you in a timely fashion. You are there to make their life easier, not harder.
And whatever you do, do NOT ask them questions you don’t actually want to know the answer to – referring to the “mistaken estimates” above ;-). That’s a developer’s kryptonite.