"No, it's less effort than that"

If you need a stable software released by Christmas, you go to your developers and say "people, we need to release a stable version of this by Christmas".

You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Depending on the economic climate and the situation of the company in the marketplace this may be accurate.

If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.

I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.

Correct. If management told our team that our performance was based on getting 2-3 planned features out this quarter, and we've been minmaxed to fill our schedules, and there's a hiring freeze and one team member just left - then we have no room for some "30 minute" (which is much more than 30 minutes for us) request. Also, management has told us that our performance reviews are based on whether we got these 2-3 planned features done within a very aggressive schedule, not your "30 minute" request - so it is management who has said this is of minimal importance, not us.

I think that it might even be worse than asking a meteorologist for sunshine. Because asking a meteorologist for sunshine has no conceivable influence on the weather, but putting a thumb on the estimation process can absolutely alter the design of the system. And that, in turn, can alter the overall effort and delivery date.

Whether the influence is positive or negative seems to depend a lot on the details of how you do it. I think, though, that the Extreme Programming community was on to something when they suggested that demanding more meticulous up-front technical design invites overengineering and ultimately makes things take longer. Unfortunately, that's often what happens when managers directly push back on estimates.

I would advocate for something more like a feedback cycle: at the end of every milestone or iteration, the team should compare how long work actually took to their estimates, and discuss the factors that may (or may not!) have contributed to any severe under- or overestimate. That process should improve the quality of estimates over time, and help the team to get better at focusing on the important factors in producing a quality estimate. And it will improve trust, too - I've noticed that it's common for teams that don't do something like this to bicker over estimates rather than collaborating on them.

And then, with all that established, it finally becomes possible for the team to reliably focus attention on the only way to actually reduce development costs without cutting corners: scope management and negotiation.

I dislike the framing here, it disempowers the team and sets up a hostile lens towards stakeholders.

As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give a customer demo, maybe a moving skeleton prototype, or at least delivering an iteration without all the integration tests would be appropriate (quality). Or maybe you can chop the deliverable into two milestones and ship the features they urgently need sooner (scope).

I acknowledge that in some cases there is just an asshole who doesn’t know what they are talking about, trying to inject urgency. But in many cases, if you actually empathize with the stakeholder and try to figure out what they are really communicating, you can find the underlying issue and modify your deliverables accordingly. This is what it looks like to be a high-performing team.

The idea that the timeline is out of your control is asinine, and will make stakeholders distrustful, since the idea is obviously nonsense (or if it’s true, the team is adrift). I strongly advise you to never use this language or philosophy in your stakeholder interactions.