7 ms·

How to build silos and decrease collaboration on purpose

111 points by labwire 5y ago

bostonsre 5y ago
It sounds reasonable, but I think a key requirement of operating like this would be to have solid leaders that will guide the organization in the correct way. This is similar to the best blog post I've ever read on organizations by coda hale [1]. His perspective of viewing an organization like a distributed computing system is enlightening and highly pragmatic. Scaling organizations is hard. To scale well, you need to avoid contention on shared resources and continually work on force multiplier type projects. [1] https://codahale.com/work-is-work/ https://codahale.com/work-is-work/
- spdionis 5y ago
  Quite cool to see my conclusions on viewing organizations as distributed systems echoed by other people, and, in particular, explained in such beautiful form. Definitely recommend reading parent's quoted article.
- jadeforrest 5y ago
  Thank you so much for introducing me to that article. It's fantastic! I've made this comparison forever, and used a lot of the same arguments -- I wish I had written this!
ineedasername 5y ago
Collaboration is when people work together to produce an outcome. When teams are collaborating, it means they’re working with other teams to achieve outcomes together. That’s often a sign the team isn’t set up well. Ideally, it should have what it needs to do what it needs without dependencies on other teams. I think you'd need to be very careful about how you implement that philosophy. It has the potential to be a recipe for every team rolling their own solutions to the same problems over & over again with very little individual knowledge making its way to become institutional knowledge. Making every team self sufficient, if not done carefully, also has the potential to be wasteful when it comes to skillsets that the team doesn't need on a full-time basis when a few teams could share the same staffer for whatever that skillset happens to be.
- Jare 5y ago
  This describes exactly what I have seen happen, with the exception of > if not done carefully I don't think you can really do it carefully and succeed. It can only work if the teams are naturally independent, i.e. with no overlap in workspace, projectspace and headspace. If you force that independence and separation you break stuff you need.
- closeparen 5y ago
  An under-appreciated element of teams rolling their own solutions is that teams vary in competence and solutions vary in quality. Preference for consistency at the expense of mediocrity is at least as serious a cultural disease in a large organization as the existence of “silos.”
skmurphy 5y ago
In this model communication has to go up to go across the silo. The "white space" in the organization is filled with poison gas (or strong cultural taboos against "breaking the chain of command"). Before you talk to someone you need to talk to their manager (or your manager must talk to their manager). It's an interesting thought experiment for organizational design. If you had enough information you could partition the challenges an organization faces into a set of mutually exclusive collectively exhaustive set and assign one team to each challenge. Of course the world does not stand still and your perfect decomposition of teams to problems starts to go obsolete as soon as you announce it. In "organize for Complexity" (https://www.amazon.com/gp/product/B010CL1X66/ https://www.amazon.com/gp/product/B010CL1X66/) Niels Pfaegling suggests every organization has three kinds of networks: 1. Formal Reporting Hierarchy: manages formal budget and compliance with laws and regulations. 2. Informal Networks: hold social capital and operate in the “white space.” 3. Expertise Networks: hold intellectual capital and procedural knowledge that enables value creation. This model remove the second and third category of networks as options. I suspect that an organization with only a formal hierarchy would be neither robust or resilient in the face of changes in the outside world (e.g new competitors, new opportunities, changes in customer needs, etc..). Christopher Alexander wrote about the value of multiple overlapping networks and a messy but lively organization in "A City is not a Tree" (See https://www.patternlanguage.com/archive/cityisnotatree.html https://www.patternlanguage.com/archive/cityisnotatree.html ). I think his insights also apply to organizations. I blogged about Pflaeging's insights in https://www.skmurphy.com/blog/2018/10/24/7-sets-of-insights-from-organize-for-complexity-by-niels-pflaeging/ https://www.skmurphy.com/blog/2018/10/24/7-sets-of-insights-...
- baxtr 5y ago
  Isn't Apple organized in strict silos and at the same the time the highest valued tech company of all time?
  - baud147258 5y ago
    perhaps the silos are big enough (like an iphone silo, a macbook silo...) that they don't need to communicate so much between them? Or they got silos, but also effective communication channels?
xsquared2 5y ago
“Otherwise, the communication burden on teams will grow at an exponential rate” Actually just quadratic.
- ivalm 5y ago
  This assumes pair-wise communication, but if you need to set up n-team cross channels then this can go up factorially (realistically it won’t, but definitely larger exponent than 2). To put it another way, thinking of teams as nodes and communication channels as edges doesn’t capture the possible complexity. It’s also not uncommon, I’ve had to work in cross-team environments where getting multiple teams aligned wasn’t just a series of pair interactions.
  - jhgb 5y ago
    > but if you need to set up n-team cross channels then this can go up factorially (realistically it won’t, but definitely larger exponent than 2) Isn't this a power set thing? The cardinality of a power set doesn't increase factorially.
    - jadeforrest 5y ago
      This thread of discussion is making my day. The Coda Hale article above gets into some of the math, but this is a great critique!
    - ivalm 5y ago
      Not necessarily, Alice, Bob and Charlie talking together might not be representable through a set of <AB>, <AC>, <BC> interactions, sometimes you really need all three to be talking/listening together. Then the interaction is <ABC>. This problem also appears in some physical materials where there are strong electron-electron correlations and so you can’t rely just on pair correlations for your calculations.
polote 5y ago
This is a ckickbait title for an article that fails to communicate what it is really about. OP seems to work in an company that give too much freedom to employees and as a result this is impossible to manage them. This has not a lot to do with collaboration. I feel like what OP is trying to describe is "highly aligned, loosely coupled"
- theptip 5y ago
  Yeah, Kniberg has written extensively on this, and has some good video summaries from his time at Spotify: https://www.youtube.com/watch?v=vOt4BbWLWQw https://www.youtube.com/watch?v=vOt4BbWLWQw
alecco 5y ago
AFAIR, the original idea of having silos came from Sloan/GM. Originally the groups were organized by function to reduce costs and streamline production. Say motors, wheels, windshields, etc. But this created problems because the end product lines didn't have much power over these groups. Some of these groups even became defiant as they were in high demand so they played the different product lines against each other. The solution was to integrate vertically from the end product lines. So each of Chevrolet/Pontiac/Cadillac/Buick would have its dedicated teams for all it's neededs. No more delays and innovation was much faster. This turned GM from a mess to beating Ford. The problem is this was seen as the ultimate organizational structure and Business Schools love magic recipes. But I've seen the same problems in IT companies with massive Dev, QA, Production teams who end up antagonizing. Prom passive aggression (e.g. delaying approvals) to the occasional openly sabotaging (e.g. approving faulty releases). From experience, QA drifts into being the most political, Dev drifts into carelessness, and Production/Ops ends up over-reacting. This can be solved by integrating vertically. But there is no silver bullet in organizational structures. There are many factors like culture, what's the product/service, the size of the organization, the geographical distribution of the teams and organization, and what kind of company it is (e.g. lean vs. moonshot).
- afarrell 5y ago
  > passive aggression (e.g. delaying approvals) How do you tell the difference between malice and having a high task load?
  - kqr 5y ago
    By measuring the task load? Edit: to be clear, I'm not saying any delay that isn't caused by high utilisation is attributable to malice. Just saying that if you've narrowed it down to those two, you've done the hard work. Those to are very easy to tell apart.
  - alecco 5y ago
    Say QA dumps a badly tested release which causes a lot of weekend drama for Prod and QA does not own up to management or apologize to Prod (e.g. they did it under pressure from Business or Marketing). In retaliation Prod doesn't approve releases after Wednesdays. I've seen much worse than this.
jerome-jh 5y ago
Companies are like good software: there should be well defined interfaces. Without them, communication as says the article is "many to many". This leaves a lot of leeway for those who use information for their own profit. And this includes management: "are you telling me you are not aware [you should have done this | we work like that | of this email from customer]?"
- analog31 5y ago
  To complete the software analogy, nobody really knows how to manage a company either.
mpweiher 5y ago
"The expected benefits of modular programming fall into three classes: (1) managerial -- development time could be shortened because separate groups would work on each module with little need for communication (and little regret afterward that there had not been more communication);" -- D. L. Parnas, ON THE CRITERIA TO BE USED IN DECOMPOSING SYSTEMS INTO MODULES, 1971, https://prl.ccs.neu.edu/img/p-tr-1971.pdf https://prl.ccs.neu.edu/img/p-tr-1971.pdf
ilyash 5y ago
> A little collaboration is fine, .... Bezos structured Amazon so that teams were as independent as possible. Maybe too much independent? It looks like AWS had roughly zero collaboration between teams. I wonder how they even get IAM to work with all the services. * Basic things like how you call pagination fields is f%cked up. https://gist.github.com/ilyash/f845d050df5c7c0805183790b28ac3f3 https://gist.github.com/ilyash/f845d050df5c7c0805183790b28ac... . That precludes straightforward implementation of wrappers and what not. * Code being published of quality which says (99% sure) it was never reviewed (at least not by someone proficient in programming and the language). * CloudFormation lags supporting new features of other services.
- Terretta 5y ago
  > I wonder how they even get IAM to work with all the services. They don’t “get it to work”. Whether it works is up to the teams, and the teams are allowed to have different views on priorities. This makes secure adoption difficult for a client trying to build a thing from multiple teams’ products. That IAM works at all is indication of sufficient values alignment across teams for prioritization of IAM to be good enough that most use cases are 80/20 met.

111 points by labwire 5y ago

It sounds reasonable, but I think a key requirement of operating like this would be to have solid leaders that will guide the organization in the correct way. This is similar to the best blog post I've ever read on organizations by coda hale [1]. His perspective of viewing an organization like a distributed computing system is enlightening and highly pragmatic. Scaling organizations is hard. To scale well, you need to avoid contention on shared resources and continually work on force multiplier type projects. [1] https://codahale.com/work-is-work/ https://codahale.com/work-is-work/

spdionis 5y ago
Quite cool to see my conclusions on viewing organizations as distributed systems echoed by other people, and, in particular, explained in such beautiful form. Definitely recommend reading parent's quoted article.
jadeforrest 5y ago
Thank you so much for introducing me to that article. It's fantastic! I've made this comparison forever, and used a lot of the same arguments -- I wish I had written this!

ineedasername 5y ago

Collaboration is when people work together to produce an outcome. When teams are collaborating, it means they’re working with other teams to achieve outcomes together. That’s often a sign the team isn’t set up well. Ideally, it should have what it needs to do what it needs without dependencies on other teams. I think you'd need to be very careful about how you implement that philosophy. It has the potential to be a recipe for every team rolling their own solutions to the same problems over & over again with very little individual knowledge making its way to become institutional knowledge. Making every team self sufficient, if not done carefully, also has the potential to be wasteful when it comes to skillsets that the team doesn't need on a full-time basis when a few teams could share the same staffer for whatever that skillset happens to be.

Jare 5y ago
This describes exactly what I have seen happen, with the exception of > if not done carefully I don't think you can really do it carefully and succeed. It can only work if the teams are naturally independent, i.e. with no overlap in workspace, projectspace and headspace. If you force that independence and separation you break stuff you need.
closeparen 5y ago
An under-appreciated element of teams rolling their own solutions is that teams vary in competence and solutions vary in quality. Preference for consistency at the expense of mediocrity is at least as serious a cultural disease in a large organization as the existence of “silos.”

skmurphy 5y ago

In this model communication has to go up to go across the silo. The "white space" in the organization is filled with poison gas (or strong cultural taboos against "breaking the chain of command"). Before you talk to someone you need to talk to their manager (or your manager must talk to their manager). It's an interesting thought experiment for organizational design. If you had enough information you could partition the challenges an organization faces into a set of mutually exclusive collectively exhaustive set and assign one team to each challenge. Of course the world does not stand still and your perfect decomposition of teams to problems starts to go obsolete as soon as you announce it. In "organize for Complexity" (https://www.amazon.com/gp/product/B010CL1X66/ https://www.amazon.com/gp/product/B010CL1X66/) Niels Pfaegling suggests every organization has three kinds of networks: 1. Formal Reporting Hierarchy: manages formal budget and compliance with laws and regulations. 2. Informal Networks: hold social capital and operate in the “white space.” 3. Expertise Networks: hold intellectual capital and procedural knowledge that enables value creation. This model remove the second and third category of networks as options. I suspect that an organization with only a formal hierarchy would be neither robust or resilient in the face of changes in the outside world (e.g new competitors, new opportunities, changes in customer needs, etc..). Christopher Alexander wrote about the value of multiple overlapping networks and a messy but lively organization in "A City is not a Tree" (See https://www.patternlanguage.com/archive/cityisnotatree.html https://www.patternlanguage.com/archive/cityisnotatree.html ). I think his insights also apply to organizations. I blogged about Pflaeging's insights in https://www.skmurphy.com/blog/2018/10/24/7-sets-of-insights-from-organize-for-complexity-by-niels-pflaeging/ https://www.skmurphy.com/blog/2018/10/24/7-sets-of-insights-...

baxtr 5y ago
Isn't Apple organized in strict silos and at the same the time the highest valued tech company of all time?
- baud147258 5y ago
  perhaps the silos are big enough (like an iphone silo, a macbook silo...) that they don't need to communicate so much between them? Or they got silos, but also effective communication channels?

xsquared2 5y ago

“Otherwise, the communication burden on teams will grow at an exponential rate” Actually just quadratic.

ivalm 5y ago
This assumes pair-wise communication, but if you need to set up n-team cross channels then this can go up factorially (realistically it won’t, but definitely larger exponent than 2). To put it another way, thinking of teams as nodes and communication channels as edges doesn’t capture the possible complexity. It’s also not uncommon, I’ve had to work in cross-team environments where getting multiple teams aligned wasn’t just a series of pair interactions.
- jhgb 5y ago
  > but if you need to set up n-team cross channels then this can go up factorially (realistically it won’t, but definitely larger exponent than 2) Isn't this a power set thing? The cardinality of a power set doesn't increase factorially.
  - jadeforrest 5y ago
    This thread of discussion is making my day. The Coda Hale article above gets into some of the math, but this is a great critique!
  - ivalm 5y ago
    Not necessarily, Alice, Bob and Charlie talking together might not be representable through a set of <AB>, <AC>, <BC> interactions, sometimes you really need all three to be talking/listening together. Then the interaction is <ABC>. This problem also appears in some physical materials where there are strong electron-electron correlations and so you can’t rely just on pair correlations for your calculations.

polote 5y ago

This is a ckickbait title for an article that fails to communicate what it is really about. OP seems to work in an company that give too much freedom to employees and as a result this is impossible to manage them. This has not a lot to do with collaboration. I feel like what OP is trying to describe is "highly aligned, loosely coupled"

theptip 5y ago
Yeah, Kniberg has written extensively on this, and has some good video summaries from his time at Spotify: https://www.youtube.com/watch?v=vOt4BbWLWQw https://www.youtube.com/watch?v=vOt4BbWLWQw

alecco 5y ago

AFAIR, the original idea of having silos came from Sloan/GM. Originally the groups were organized by function to reduce costs and streamline production. Say motors, wheels, windshields, etc. But this created problems because the end product lines didn't have much power over these groups. Some of these groups even became defiant as they were in high demand so they played the different product lines against each other. The solution was to integrate vertically from the end product lines. So each of Chevrolet/Pontiac/Cadillac/Buick would have its dedicated teams for all it's neededs. No more delays and innovation was much faster. This turned GM from a mess to beating Ford. The problem is this was seen as the ultimate organizational structure and Business Schools love magic recipes. But I've seen the same problems in IT companies with massive Dev, QA, Production teams who end up antagonizing. Prom passive aggression (e.g. delaying approvals) to the occasional openly sabotaging (e.g. approving faulty releases). From experience, QA drifts into being the most political, Dev drifts into carelessness, and Production/Ops ends up over-reacting. This can be solved by integrating vertically. But there is no silver bullet in organizational structures. There are many factors like culture, what's the product/service, the size of the organization, the geographical distribution of the teams and organization, and what kind of company it is (e.g. lean vs. moonshot).

afarrell 5y ago
> passive aggression (e.g. delaying approvals) How do you tell the difference between malice and having a high task load?
- kqr 5y ago
  By measuring the task load? Edit: to be clear, I'm not saying any delay that isn't caused by high utilisation is attributable to malice. Just saying that if you've narrowed it down to those two, you've done the hard work. Those to are very easy to tell apart.
- alecco 5y ago
  Say QA dumps a badly tested release which causes a lot of weekend drama for Prod and QA does not own up to management or apologize to Prod (e.g. they did it under pressure from Business or Marketing). In retaliation Prod doesn't approve releases after Wednesdays. I've seen much worse than this.

jerome-jh 5y ago

Companies are like good software: there should be well defined interfaces. Without them, communication as says the article is "many to many". This leaves a lot of leeway for those who use information for their own profit. And this includes management: "are you telling me you are not aware [you should have done this | we work like that | of this email from customer]?"

analog31 5y ago
To complete the software analogy, nobody really knows how to manage a company either.

mpweiher 5y ago

"The expected benefits of modular programming fall into three classes: (1) managerial -- development time could be shortened because separate groups would work on each module with little need for communication (and little regret afterward that there had not been more communication);" -- D. L. Parnas, ON THE CRITERIA TO BE USED IN DECOMPOSING SYSTEMS INTO MODULES, 1971, https://prl.ccs.neu.edu/img/p-tr-1971.pdf https://prl.ccs.neu.edu/img/p-tr-1971.pdf

ilyash 5y ago

> A little collaboration is fine, .... Bezos structured Amazon so that teams were as independent as possible. Maybe too much independent? It looks like AWS had roughly zero collaboration between teams. I wonder how they even get IAM to work with all the services. * Basic things like how you call pagination fields is f%cked up. https://gist.github.com/ilyash/f845d050df5c7c0805183790b28ac3f3 https://gist.github.com/ilyash/f845d050df5c7c0805183790b28ac... . That precludes straightforward implementation of wrappers and what not. * Code being published of quality which says (99% sure) it was never reviewed (at least not by someone proficient in programming and the language). * CloudFormation lags supporting new features of other services.

Terretta 5y ago
> I wonder how they even get IAM to work with all the services. They don’t “get it to work”. Whether it works is up to the teams, and the teams are allowed to have different views on priorities. This makes secure adoption difficult for a client trying to build a thing from multiple teams’ products. That IAM works at all is indication of sufficient values alignment across teams for prioritization of IAM to be good enough that most use cases are 80/20 met.