7 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 he

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. Once silos are broken down and cross-team/cross-org collaboration becomes valorized, everything is strangers and Zoom meetings and time zones and Process and maybe if you’re lucky one person in your partner org or site who can be trusted to give a straight answer or get something done that wasn’t formally planned a year in advance. The best way to derail a project is to get the greatest number of engineers involved in it, especially engineers who don’t share priorities, timelines, conventions, geography, or language. This is coincidentally also the best way to get promoted at a large company that believes in breaking down silos.

ghaff 3y ago
Silos and fiefdoms are normally seen as negative things. And that's not entirely wrong. But they can also describe skunkworks/internal startup/etc. teams doing their own thing without a lot of interference or having to constantly coordinate with every other organization in the company. It can go both ways.
- esafak 3y ago
  Silos are also good for sheltering and nurturing high performing teams, especially when the broader organization is bad.
marklar423 3y ago
I feel like you're working with a different definition of "silo" than the parent. My understanding of a "silo" is "closed off teams that aren't allowed to work with outsiders" who have their own culture that may be at odds with the company. It seems like you're talking about team nimbleness and cohesiveness, which I want to say is orthogonal.
- closeparen 3y ago
  Building in silos is when you get something done by yourself or with your direct teammates. Cross team collaboration involves e.g. a weekly sync, coauthored design documents, code changes made in modules you’ve never seen before reviewed by people you don’t know, tasks that are critical blocking dependencies for you but totally irrelevant to the decision-makers of the teams that need to allocate time for them. The extent to which a company is siloed is the extent to which its engineers are talking to their desk neighbors and getting things done vs. navigating communication overhead and being blocked on people quite remote from them and their goals. It’s hard to believe you could have a nimble and cohesive team at the scale of a large corporation, because the number of communication edges gets silly. Dunbar’s number and all that. You can have team nimble and cohesive teams within large corporations. But having several distinct networks is otherwise known as being siloed.
  - Nimitz14 3y ago
    This is not at all what people mean when they talk about silos
    - Solvency 3y ago
      Ok how do you meaningfully define the difference and moreover how would you prevent his version of a "good" silo from devolving into a "bad" one in actuality?
      - whatshisface 3y ago
        "How does efficient compartmentalization become bad siloing?" Step one: build Aa and Bb with the A and a people together, and the B and b people together. Step two: realize you need AB and ab. Step three: keep the same organizational structure, and try to get the A team to work with the B team ten managers and five hundred miles away.
    - ninkendo 3y ago
      Data point of one, but it's precisely what I mean when I talk about silos.
yojo 3y ago
High process and high collaboration/coordination is not the only alternative to silos. Google in the mid aughts still had tightly aligned teams with clear priorities. But they were also transparent in what they were doing, and open to collaboration where it made sense. Teams felt empowered to reject requests that would trip them up, but also empowered to do small things to help another team (and got rewarded for doing so). The reality at a large org is you’re going to have dependencies. In my experience, highly-siloed orgs have tremendous coordination barriers to even the smallest request across teams. Your one-line API change didn’t make it onto your dependency’s roadmap this quarter? Too bad, try again in three months. And I’m not sure we have the same understanding of “fiefdom.” I’m talking about the pattern where middle managers try to grow their headcount as large as possible without a clear purpose other than building status within the org. This often manifests as disparate and disjoint teams aggregated under a leader who has little understanding or care as to what exactly it is they’re doing. It is hard to find value in this arrangement.
- lll-o-lll 3y ago
  > In my experience, highly-siloed orgs have tremendous coordination barriers to even the smallest request across teams. Isn’t this solved by having cross-team project managers who can perform this coordination? I certainly agree that the failure case you describe is possible, but it’s also solvable (in my experience).
- closeparen 3y ago
  > Your one-line API change didn’t make it onto your dependency’s roadmap this quarter? Too bad, try again in three months. This is one of the key problems of working across teams, and its impact is amplified by a culture that says you should turn everything into a cross-team project that you possibly can. The whole company grinds to a near halt on these sorts of blockages.
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 ago
  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.
  - Aeolun 3y ago
    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.
- closeparen 3y ago
  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).
JumpCrisscross 3y ago
It’s Coase’s theory of the firm [1] in synecdoche. Silos escape the political transaction costs around them at the expense of access to external resources. They can famously work, e.g. Skunkworks. But they also decay into fiefdoms. [1] https://en.m.wikipedia.org/wiki/Theory_of_the_firm https://en.m.wikipedia.org/wiki/Theory_of_the_firm
mk89 3y ago
Breaking down silos de-risks a company, despite some of the costs you mentioned. Especially after covid, companies capitalize on the flexibility of employees and lack of (physical) offices. Employees can be replaced like never before. But even without that in mind, breaking silos can also put the right people in the loop - for every successful silo you mentioned, I bet there is a successful company which was able to have a good mix of people from different teams. For me it always boils down to: what does the company want? Who they want to be in the next 3-5-10 years? Based on this you need to have proper management training. Without that, they simply throw engineers at the problem, which as you mentioned, can backfire. If you as an organization are able to scale well (even with some small and monitored silos) I don't see why it should be a problem. Reality is: companies want to be able to scale like Google for their pet projects, fire fast upon need, have a lot of teams all with the performance of 10x engineers, etc etc. That's the BS they write on their about page. Do they have agile coaches? Do they have people that help them organize work? Skilled people, not random guy that developed software all his life and now he/she wants to try something new, and he/she read a book over the weekend or listened to some podcasts.. People have high expectations by paying little. It takes effort to do things right. That's in my opinion the truth.
- logical42 3y ago
  Counterpoint: Apple has been quite successful despite their insistence in silos across teams and orgs.

ghaff 3y ago

Silos and fiefdoms are normally seen as negative things. And that's not entirely wrong. But they can also describe skunkworks/internal startup/etc. teams doing their own thing without a lot of interference or having to constantly coordinate with every other organization in the company. It can go both ways.

esafak 3y ago
Silos are also good for sheltering and nurturing high performing teams, especially when the broader organization is bad.

marklar423 3y ago

I feel like you're working with a different definition of "silo" than the parent. My understanding of a "silo" is "closed off teams that aren't allowed to work with outsiders" who have their own culture that may be at odds with the company. It seems like you're talking about team nimbleness and cohesiveness, which I want to say is orthogonal.

closeparen 3y ago
Building in silos is when you get something done by yourself or with your direct teammates. Cross team collaboration involves e.g. a weekly sync, coauthored design documents, code changes made in modules you’ve never seen before reviewed by people you don’t know, tasks that are critical blocking dependencies for you but totally irrelevant to the decision-makers of the teams that need to allocate time for them. The extent to which a company is siloed is the extent to which its engineers are talking to their desk neighbors and getting things done vs. navigating communication overhead and being blocked on people quite remote from them and their goals. It’s hard to believe you could have a nimble and cohesive team at the scale of a large corporation, because the number of communication edges gets silly. Dunbar’s number and all that. You can have team nimble and cohesive teams within large corporations. But having several distinct networks is otherwise known as being siloed.
- Nimitz14 3y ago
  This is not at all what people mean when they talk about silos
  - Solvency 3y ago
    Ok how do you meaningfully define the difference and moreover how would you prevent his version of a "good" silo from devolving into a "bad" one in actuality?
    - whatshisface 3y ago
      "How does efficient compartmentalization become bad siloing?" Step one: build Aa and Bb with the A and a people together, and the B and b people together. Step two: realize you need AB and ab. Step three: keep the same organizational structure, and try to get the A team to work with the B team ten managers and five hundred miles away.
  - ninkendo 3y ago
    Data point of one, but it's precisely what I mean when I talk about silos.

yojo 3y ago

High process and high collaboration/coordination is not the only alternative to silos. Google in the mid aughts still had tightly aligned teams with clear priorities. But they were also transparent in what they were doing, and open to collaboration where it made sense. Teams felt empowered to reject requests that would trip them up, but also empowered to do small things to help another team (and got rewarded for doing so). The reality at a large org is you’re going to have dependencies. In my experience, highly-siloed orgs have tremendous coordination barriers to even the smallest request across teams. Your one-line API change didn’t make it onto your dependency’s roadmap this quarter? Too bad, try again in three months. And I’m not sure we have the same understanding of “fiefdom.” I’m talking about the pattern where middle managers try to grow their headcount as large as possible without a clear purpose other than building status within the org. This often manifests as disparate and disjoint teams aggregated under a leader who has little understanding or care as to what exactly it is they’re doing. It is hard to find value in this arrangement.

lll-o-lll 3y ago
> In my experience, highly-siloed orgs have tremendous coordination barriers to even the smallest request across teams. Isn’t this solved by having cross-team project managers who can perform this coordination? I certainly agree that the failure case you describe is possible, but it’s also solvable (in my experience).
closeparen 3y ago
> Your one-line API change didn’t make it onto your dependency’s roadmap this quarter? Too bad, try again in three months. This is one of the key problems of working across teams, and its impact is amplified by a culture that says you should turn everything into a cross-team project that you possibly can. The whole company grinds to a near halt on these sorts of blockages.

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 ago
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.
- Aeolun 3y ago
  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.
closeparen 3y ago
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).

JumpCrisscross 3y ago

It’s Coase’s theory of the firm [1] in synecdoche. Silos escape the political transaction costs around them at the expense of access to external resources. They can famously work, e.g. Skunkworks. But they also decay into fiefdoms. [1] https://en.m.wikipedia.org/wiki/Theory_of_the_firm https://en.m.wikipedia.org/wiki/Theory_of_the_firm

mk89 3y ago

Breaking down silos de-risks a company, despite some of the costs you mentioned. Especially after covid, companies capitalize on the flexibility of employees and lack of (physical) offices. Employees can be replaced like never before. But even without that in mind, breaking silos can also put the right people in the loop - for every successful silo you mentioned, I bet there is a successful company which was able to have a good mix of people from different teams. For me it always boils down to: what does the company want? Who they want to be in the next 3-5-10 years? Based on this you need to have proper management training. Without that, they simply throw engineers at the problem, which as you mentioned, can backfire. If you as an organization are able to scale well (even with some small and monitored silos) I don't see why it should be a problem. Reality is: companies want to be able to scale like Google for their pet projects, fire fast upon need, have a lot of teams all with the performance of 10x engineers, etc etc. That's the BS they write on their about page. Do they have agile coaches? Do they have people that help them organize work? Skilled people, not random guy that developed software all his life and now he/she wants to try something new, and he/she read a book over the weekend or listened to some podcasts.. People have high expectations by paying little. It takes effort to do things right. That's in my opinion the truth.

logical42 3y ago
Counterpoint: Apple has been quite successful despite their insistence in silos across teams and orgs.