Even impossible deadlines aren't the end of the world. "We need X Y and Z done in N weeks!" "...I'm not sure if we can get even one of those completed in N we

Even impossible deadlines aren't the end of the world. "We need X Y and Z done in N weeks!" "...I'm not sure if we can get even one of those completed in N weeks - and that's even before accounting for the fact that I'm an optimist among optimists. Since it's so obviously impossible, I'm not going to kill myself trying - instead, let's talk prioritization, so we can deliver as much value as reasonably possible within the deadline, if it's really an important one." What you want to avoid: 1) Pressuring devs into crunch/burnout/quitting/morale loss/checking out. Turnover will eventually cause brain drain when your best talent leaves for greener pastures, and makes hiring more expensive when your reputation sours. 2) Pressuring devs into sacrificing long term productivity for meaningless short term milestones. It's one thing to prioritize a feature or two for an important presentation to investors who will be making decisions about your financial future at the temporary expense of, say, test coverage. It's another to do so routinely that codebase stability suffers, developer velocity gets wasted on disturbingly routine debugging sessions, and build engineers disable code coverage metrics for being "just too gosh darn depressing to even look at."