4 ms·
> Silos and fiefdoms allow small gelled teams who know and trust each other, have similar levels of competence, and sit physically near each other to put their
by dasil003 3y ago
> Silos and fiefdoms allow small gelled teams who know and trust each other, have similar levels of competence, and sit physically near each other to put their heads down and execute with extraordinary speed and quality.
...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.
- vineyardmike 3y agoAnd 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.
- Aeolun 3y agoI 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.
- closeparen 3y agoI 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).
- dasil003 3y agoAbsolutely. 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.
- closeparen 3y agoIC 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.
- dasil003 3y agoLeadership 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.
- closeparen 3y agoBut 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.
- dasil003 3y agoThat’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.