4 ms·

Don't they have product teams at Uber that should do most of that filtering?

weird-eye-issue 4y ago
Yeah these seem like product-level things. Seems like a bit of a mess if engineers are coming to their managers about working on things that weren't specced out. Shouldn't they be busy with things that were already specced out and estimated?
alistairSH 4y ago
I had the same thought. When some other team comes to me with a non-trivial request, one of the first things I do is check with the product team. Is it part of somebody's roadmap (it's not part of mine, or I'd know about it already)? If so, is it a current thing or a future thing? And do they agree that my team needs to drop our current work? If it's the product team coming to me, well, that's their job. I just explain what they'd be giving up by changing priorities. Of course, a PM that can clearly articulate a single #1 priority is a rarity, so sometimes this discussion gets a bit heated, but that's part of the job. And if some other team or product manager went directly to one of my engineers, I'll politely tell them that's not how things work.
hackitup7 4y ago
I get the sense that the author is referring to the combined product/engineering unit, as I usually see PMs fulfilling much of this type of filtering/pushback role. But I had a similar reaction – high quality PMs actually view it as their job to stand in the way of a lot of these requests because preserving engineering (and often design) focus is one of their top priorities.
- strgcmc 4y ago
  Speaking as an EM, from product partners, there is basically this switch that sometimes flips (depending on the PM, depending on their experience/career maturity, depending on the team/business context): - Either the eng team is a tragedy of the commons, a place to graze whatever sheep you care to send their way, and sure why not let your friends and neighbors also come graze here too? After all, it's not like YOU own it, it belongs to the EM, right? And it's the EM's job to figure out to sustain 100 sheep on a 10 sq ft plot of grass, right? After all, that sounds like some cool engineering whiz shit (to invent hyper-efficient grazing), doesn't it? - OR, the eng team is YOUR resource, and you don't want others to graze on your land for free... IMHO, I don't even know that I'd call it a "high quality" vs low quality thing; I think of it like, making a choice about what you want your product <-> eng relationship to be like - do you want your eng team to be thoughtful and do "deep work", or do you want them to optimize for context-switching and multi-tasking? I know it sounds like "deep work" is always the right answer, but it might not be, in all contexts (... okay it probably is right, in 90% of contexts).
  - kcexn 4y ago
    With most human endeavours people need to be able to do both. Having no context switching, and only deep work is going to lead to outcomes that are divorced from the reality of the business. These kinds of divisions were tried in the middle of the twentieth century when all big companies had dedicated research divisions: think Bell Labs. While the technology outcomes were often spectacular, very little money, if any, were made from these divisions. On the other hand, if all you do is context switching and busy work, then the organisation will never grow and move forward, forever bound by the whims of the market.

Yeah these seem like product-level things. Seems like a bit of a mess if engineers are coming to their managers about working on things that weren't specced out. Shouldn't they be busy with things that were already specced out and estimated?

alistairSH 4y ago

I had the same thought. When some other team comes to me with a non-trivial request, one of the first things I do is check with the product team. Is it part of somebody's roadmap (it's not part of mine, or I'd know about it already)? If so, is it a current thing or a future thing? And do they agree that my team needs to drop our current work? If it's the product team coming to me, well, that's their job. I just explain what they'd be giving up by changing priorities. Of course, a PM that can clearly articulate a single #1 priority is a rarity, so sometimes this discussion gets a bit heated, but that's part of the job. And if some other team or product manager went directly to one of my engineers, I'll politely tell them that's not how things work.

hackitup7 4y ago

I get the sense that the author is referring to the combined product/engineering unit, as I usually see PMs fulfilling much of this type of filtering/pushback role. But I had a similar reaction – high quality PMs actually view it as their job to stand in the way of a lot of these requests because preserving engineering (and often design) focus is one of their top priorities.

strgcmc 4y ago
Speaking as an EM, from product partners, there is basically this switch that sometimes flips (depending on the PM, depending on their experience/career maturity, depending on the team/business context): - Either the eng team is a tragedy of the commons, a place to graze whatever sheep you care to send their way, and sure why not let your friends and neighbors also come graze here too? After all, it's not like YOU own it, it belongs to the EM, right? And it's the EM's job to figure out to sustain 100 sheep on a 10 sq ft plot of grass, right? After all, that sounds like some cool engineering whiz shit (to invent hyper-efficient grazing), doesn't it? - OR, the eng team is YOUR resource, and you don't want others to graze on your land for free... IMHO, I don't even know that I'd call it a "high quality" vs low quality thing; I think of it like, making a choice about what you want your product <-> eng relationship to be like - do you want your eng team to be thoughtful and do "deep work", or do you want them to optimize for context-switching and multi-tasking? I know it sounds like "deep work" is always the right answer, but it might not be, in all contexts (... okay it probably is right, in 90% of contexts).
- kcexn 4y ago
  With most human endeavours people need to be able to do both. Having no context switching, and only deep work is going to lead to outcomes that are divorced from the reality of the business. These kinds of divisions were tried in the middle of the twentieth century when all big companies had dedicated research divisions: think Bell Labs. While the technology outcomes were often spectacular, very little money, if any, were made from these divisions. On the other hand, if all you do is context switching and busy work, then the organisation will never grow and move forward, forever bound by the whims of the market.