I get your general point, but it also depends on the scope of X and the scale of the organization. If X is big, say, "build a new data mart (over the next 6 mo

I get your general point, but it also depends on the scope of X and the scale of the organization. If X is big, say, "build a new data mart (over the next 6 months)," then your considerations are very relevant. That should have a plan and buy-in from all of the relevant stakeholders; it's a legitimate project and needs the organizational ceremony involved in such. If X is small, say, "make this internal API return an additional integer field from a datastore it's already using," then that sounds like bureaucracy and politics needlessly impeding development. This is a minor enhancement. I guess the trouble is that even a small change like my example could be substantial in a large enough organization. Maybe adding the integer field means a new version of the API has to be published, or maybe adding the integer field means DB indexes or caching strategies have to be updated. Even so, the API team should have established processes for solving these issues. So instead of a simple change taking a few hours, it takes a few days, still not a huge divergence of resources. From the parent using the example "Fine I'll do it for you, I need it now," I'm assuming they're talking about very small scope problems, which would not substantially affect the schedule for Y. And remember, Y is already being affected, because it requires X to get completed. So it's not really a matter of working on X when you should be working on Y; it's that progress on Y has halted due to a missing X dependency. What can we do to get Y moving forward again?