When the opportunity for more resources is on the table for X, no one is available to work on X. When they're looking to cut head count, everyone is working on X. Where X is some poorly defined but essential feature.
At the ground level engineers are frustrated because if they could just get "those idiots" to do the one thing they needed they could make progress. Without ever realizing that they were the "those idiots" in someone else's dependency tree.
If you are a senior technical leader (or want to be one) it is always worthwhile to follow these threads to figure out what is going on, even though it might seem like a distraction. The larger the organization the more challenging this can be but most people will tell you what they are working on and why its important (which is to say what will be fixed/improved/made possible by its delivery)
What you describe kind of suggests upholding strict divisions per team like that is one of the main causes of the problem.
Wouldn't being more flexible of temporarily joining another team as a guest work? I imagine that for a number of situations this could work:
- I want to do x, my team needs it
- But we're responsible for X, and x falls under that
- When can you do it?
- We're understaffed, so years from now
- Fine I'll do it for you, I need it now
- Didn't you hear we are responsible for X? If x is not done right we are the ones who get in trouble for that.
- So make me a temporary guest member of your group, vet my work to make sure it's ok, and share the credit for x.
- Ok, that actually sounds like a good return on investment for us, welcome to the team!
I mean in theory Google's 20% time allows for this, but all traces of that (like the calendar and gmail labs) have systematically vanished from their products. And that happened years ago, it's not like that was yesterday.
They will actually fight having an "export to google sheets" feature, because it would cost them a lot of headcount.
And of course, demanding that managers learn a bit of basic (and I do mean basic) programming ("querying" would be a more apt description) to, for instance, do SQL queries on the database so they'd include those statistical measures ... that's just so out of the question it's not funny. There seems to be this need for managers to be the dumbest, most idiotic (but agreeable) people that just do whatever their boss asks of them, mostly by subtly threatening whoever is below them. "Good" companies leave 1 level above the rank and file that actually gets promoted from the rank and file to prevent the worst of the inevitable backlash. And yes, Facebook also definitely works like this, from what I've seen during an extended interview.
I can think of 10 examples of this I've seen where I work in the last year.
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?