Re:Reflecting on 18 Years at Google
by closeparen on Wednesday November 22, 2023 @04:19PM
(#38385264)
I don’t disagree. But I have also seen situations where middle managers are highly attuned to and proud of cross-team projects, and basically don’t pay any attention or give any weight to value delivered for end-users within teams, so everyone is encouraged to structure their projects to maximize communication overhead (even line managers, since doing so gives them the opportunity to grow their directs).
Absolutely. There are a lot of failure modes. This is why true IC leadership with teeth is needed. The whole point of staff+ engineer roles (outside of specialist research) is to navigate the right technical decisions that span across teams.
Re:Reflecting on 18 Years at Google
by closeparen on Thursday November 23, 2023 @09:40AM
(#38393221)
IC leadership positions are earned by leading cross-team projects, so the senior engineers who want them (and the managers who want to grow IC leaders) are encouraged to turn everything into one.
Leadership positions should be granted not just on “projects”, but demonstrated technical ability and judgement. This often includes influence of what NOT to do just as much as it involves driving projects. Obviously any rubric is only as good as the people who apply it, and if you hire tens of thousands of smart engineers with only one really profitable product and not much in the way of vision it’s going to be a fucking mess.
Re:Reflecting on 18 Years at Google
by closeparen on Thursday November 23, 2023 @10:31AM
(#38393811)
But because of the stigmatization of silos and valorization of cross-team efforts, making a project cross-team when it doesn't need to be is considered an example of demonstrating the company's values rather than example of bad technical judgement.
That’s a false dichotomy and bad leadership judgement. I don’t doubt these arguments are made and sometimes won (especially in dysfunctional or apathetic orgs), but context matters, there’s no value system that supersedes critical thinking in context. One of the questions I ask in staff+ promo committee is what did this person prevent from being built.
Re:Reflecting on 18 Years at Google
by cutemonster on Thursday November 23, 2023 @05:40PM
(#38398466)
Good question :-) Could make sense on a senior developer level?
At the same time, seems possibly easy to game? If two friends make unnecessary suggestions, and stop each other's suggestions.
If it becomes well known that this question is being asked?
Not much work required to pretend one stopped sth from getting built
Re:Reflecting on 18 Years at Google
by vineyardmike on Wednesday November 22, 2023 @03:04PM
(#38384392)
And this is another reason why managers growing their fiefdom to make big teams is bad for the organization.
Most of the most successful projects and incredible feats of engineering happen by tiny teams full of very talented people NOT a 4-layer management pyramid of people who are here for a nice stable 9-5. Not to say you can’t be successful with WLB but you need a certain fire in your gut and a hunger to execute as a small and efficient team.
I think there’s nothing incompatible between fire and WLB. Execute with a much greater degree of efficiency between 9 and 5.
Too often do people just throw more time and/or bodies at a problem to make it go away.
...for things that align with that silo structure. If you try to build new things that necessitate conceptual integrity across org boundaries, then teams that think this way will first debate ownership and responsibility breakdown before it's even clear how the thing should work at a high level. I've seen too many examples of horrible engineering done by silo'ed teams, where they build down blind alleys that turn out to be unmaintainable and net-negative producing over time because they approached it based on what services they could touch rather than what made sense from an overall system and UX perspective.
Obviously "breaking down silos" involves greater coordination and communication overhead, and thus is harder to pull of successfully, so it's a tradeoff that should be weighed carefully in the context of business needs.