Agreed. The situation you describe is one where constraints do not exist, which is cultural. You assume input, say 40 hours (input is not productivity) and keep

Agreed. The situation you describe is one where constraints do not exist, which is cultural. You assume input, say 40 hours (input is not productivity) and keep piling on work, responsibilities and unrealistic deadlines where workers feel forced to put in as much as 60 hours. Which is again input, not output. Where I work, we work output-based. We work in sprints where the amount of work that can be done in a sprint is fixed, expressed as velocity. This capacity is a hard constraint and immutable (unless you hire additional people). The business is free to spent that velocity as they please, but they have no say over velocity itself. They also have no say over input (hours) or estimates (they're not qualified to do so). These hard constraints are a thing of beauty, it forces serious prioritization. Call me old and cynical, but in my 25 years in IT, I'd say at least 80% of what gets build is bullshit. Untested brain farts from higher-ups that have no tangible benefit to any customer or user. Hence I fail to be impressed by almost any "priority" or "deadline", exceptions aside.