4 ms·

Right but there's a mirror image problem, which is that you're working on Y, people need Y, your team is resourced for Y. So if you go off and do X, then why ar

by slivym 9y ago

Right but there's a mirror image problem, which is that you're working on Y, people need Y, your team is resourced for Y. So if you go off and do X, then why are they paying you to do Y? Let's cut the headcount on Y, and invest in the team working on X. 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.

vanderZwan 9y ago
> So if you go off and do X, then why are they paying you to do Y? 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!
- candiodari 9y ago
  Good luck getting your current manager to agree to this ! Are there any organisations that allow this ? 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.
  - mic47 9y ago
    I have expectation of any reasonable manager to agree to some form of this; at least to work on that feature you need and support it so that you get unblocked. This is at least practice at Facebook.
    - candiodari 9y ago
      In my experience, while they will do it as a last resort, what's much more likely to happen is that they will continuously "compensate" for lack of features by overloading their current employees, then have them complain about lack of headcount. This is especially true where it comes to things like reports. Reports don't have variance ? Why not have someone copy everything over into a spreadsheet and manually calculate whatever statistics other managers want to see ? 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.
Tenhundfeld 9y ago
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?
ChuckMcM 9y ago
These two are a very common form of dysfunction in large companies. The team trying to do feature Y needs feature X, the team responsible for feature X is behind because feature W is taking longer than expected. Sometimes a person can see that feature W is hung up waiting on feature Y, and you discover an structural form of deadlock. 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)

by slivym 9y ago

vanderZwan 9y ago

> So if you go off and do X, then why are they paying you to do Y? 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!

candiodari 9y ago
Good luck getting your current manager to agree to this ! Are there any organisations that allow this ? 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.
- mic47 9y ago
  I have expectation of any reasonable manager to agree to some form of this; at least to work on that feature you need and support it so that you get unblocked. This is at least practice at Facebook.
  - candiodari 9y ago
    In my experience, while they will do it as a last resort, what's much more likely to happen is that they will continuously "compensate" for lack of features by overloading their current employees, then have them complain about lack of headcount. This is especially true where it comes to things like reports. Reports don't have variance ? Why not have someone copy everything over into a spreadsheet and manually calculate whatever statistics other managers want to see ? 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.

Tenhundfeld 9y ago

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?

ChuckMcM 9y ago

These two are a very common form of dysfunction in large companies. The team trying to do feature Y needs feature X, the team responsible for feature X is behind because feature W is taking longer than expected. Sometimes a person can see that feature W is hung up waiting on feature Y, and you discover an structural form of deadlock. 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)