I read a post on Eric Nelon's blog regarding Developers vs the "others". Eric is justifiably annoyed that various levels of managers expect:
-developers to do the managers' job as well as his/her own
-developers have to understand the end goal just as well as the managers
-developers have to agree with what the manager says, even if the developer's argument is backed up by facts
-developers have to accept that their needs are unimportant (course, books etc.), whereas managers go on whatever courses, conferences that are necessary

I think that the meeting of minds here should be achieved by defining requirements:
-agree requirements. This will involve both development team and management agreeing the end result. Not something vague - you need concrete bulet points, even if this is Agile development
-map the project plan to these requirements, breaking it down to individual work tasks

This will mean that both sides know what to expect. If the manager wishes to alter the requirements, then the developer can easily track which tasks need to be altered, and give a justified, detailed estimation of how much more time/resources will be needed. So often, I've seen unprepared developers bullied into accepting ridiculous timelines because they're not giving the full picture.

Unfortunately, there's just too little management of requirements in many projects. I've even heard people say "we don't define requirements, because we do Agile development". This is wrong - agile is all about defining requirements. See this post.

This is particularly relevant to security. If you define security requirements early (for instance, the roles/access matrix for the app), then this becomes a milestone on your project plan that the team works towards. If you engage with the security team late, then there's no management buy-in to that requirement. When you try to introduce it, you are seen as a blocker.