"No, it's less effort than that"

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

Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.

So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.

And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations.

The best case is to:

- line up the work in order of priority, taking into account prerequisites

- have sufficient stories in a ready for dev state

- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)

- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog

- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)

- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars

- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)

- be very careful that you don't make this approach the standard way of working