6 ms·

How to build silos and decrease collaboration on purpose

144 points by gpi 1y ago

softwaredoug 1y ago
Silos make sense if the product can cleanly be broken down into neat compartments. And those won't get disrupted easily. The business model is stable. Teams can have a clean, well defined, mandate. Silos don't make sense if the existence of product area might go away every 6 month. Everything is fluid, and you'll need to regularly tear apart and reform teams. The business model is not stable. Or step-change growth is sought after by investing in new markets (and foreclosing old ones). I've seen companies build structures like they're in the first category. As if things are stable. Then they need to grow or are themselves disrupted, they need to act more collaboratively across groups, or even dissolve groups. But they can't because the intentional silos have become overspecialized fiefdoms. The cost of un-siloing is high. I much prefer companies with strong cultures beyond one fiefdom. They can quickly unform or form teams as needed without a lot of nonsense. And to do that, I think you need a lot of organizational muscle about un-siloing a lot.
Xcelerate 1y ago
Hmm... I agree with parts of this and disagree with other parts. In my experience "cross-functional collaboration" splits into two distinct components: leadership and information. Anecdotal, but when leadership is split into too many people at the same level who are each in charge of a domain (that requires heavy interaction with the other domains), nothing gets accomplished—analysis paralysis and politics takes over. You absolutely need one specific person as the final decision maker. They should carefully consider all input from various sources and then make a final decision in a timely fashion. If it turns out to be the wrong path, that's fine, just reverse course quickly as well. On the other hand, information silos are absolutely horrible. The most effective companies I've worked at have always had tons of information freely available to all employees. Unless there are privacy, cybersecurity, antitrust, or similar risks involved, every employee should have access to all information across all teams. It should be easily searchable as well. There are certainly exceptions—Apple seems to function well despite all the secrecy. But most companies aren't Apple, and I don't think it's generally a good strategy.
yesfitz 1y ago
Previous discussion: https://news.ycombinator.com/item?id=28411712 https://news.ycombinator.com/item?id=28411712 I was originally critical of this piece because I work in a highly regulated industry (and silos can lead to compliance issues), but after a little more consideration, I realized I see re-siloing happening organically due to lines of business competing for scarce resources. For example: Because everyone needs Team X to complete their projects, Team X's leadership has to decide how to allocate their time. This rarely makes the lines of business feel like their needs are fulfilled. So different lines of business start building back channels to members of Team X, in a bid to get an advocate for their projects. Eventually, a line of business might hire a Business Analyst just to deal with Team X. I guess an alternative would be to embed a member of Team X with the line of business. They're dedicated, but could also be reassigned as needed.
- braza 1y ago
  I had some different sort of issue but in the same lines: when you have distinct goals between upstream team X and the downstream team Y. Most of my experience working in un-siloed team Y communicating only via interfaces (e.g., APIs or database views) was that most of the time we could move very fast, even in Big Co. The problem started when we had a goal, e.g. saving _n_ amount in the Snowflake account, and at the same time the upstream team X started to push so much data that it not only offset our savings but also sometimes used to make things more expensive. Since upstream X has all the upper management visibility, they could operate in a more loose way towards the downstream team, and we're basically at the whims of someone to be sensible and attend to some of our requests to ask them to stop duplicating data in our database. We only had the problem solved when this upstream team X used to share the same goal (even as a partner) in terms of savings.
- strgcmc 1y ago
  In such scenarios (data engineering / DS / analytics is my personal background), I have learned not to underestimate the value of, explicitly declaring within Team X, that person X1 is dedicated to line L1, person X2 is dedicated to line L2, etc. (aka similar to your last line about embedding a person with that line of business). In theory, it doesn't actually "change" anything, because Team X is still stuck supporting exactly the same number of dependencies + the same volume and types of requests. But the benefit of explicit >>> implicit, the clarity/certainty of knowing who-to-go-to-for-what, the avoidance of context switching + the ability to develop expertise/comfort in a particular domain (as opposed to the team trying to uphold a fantasy of fungibility or that anyone can take up any piece of work at any time...), and also the specificity by which you can eventually say, "hey I need to hire more people on Team X, because you need my team for 4 projects but I only have 3 people..." -- all of that has turned out to be surprisingly valuable. Another way to say it is -- for Team X to be stretched like that initial state, is probably dysfunctional, and in a terminally-fatal sense, but it's a slow kind of decay/death. Rather than pretending it can work, pretending you can virtualize the work across people (as if people were hyper-threads in a CPU core, effortlessly switching tasks)... instead by making it discrete/concrete/explicit, by nominating who-is-going-to-work-on-what-for-who, I have learned that this is actually a form of escalation, of forcing the dysfunction to the surface, and forcing the organization to confront a sink-or-swim moment sooner than it otherwise would have (vs if you just kept limping on, kept trying to pretend you can stay on top of the muddled mess of requests that keep coming in, and you're just stuck treading water and drowning slowly). --- Of course, taking an accelerationist stance is itself risky, and those risks need to be managed. But for example, if the reaction to such a plan is something like, "okay, you've created clarity, but what happens if person X1 goes on vacation/gets-hit-by-bus, then L1 will get no support, right?"... That is the entire purpose/benefit of escalating/accelerating! In other words, Team X always had problems, but they were hidden beneath a layer of obfuscation due to the way work was being spread around implicitly... it's actually a huge improvement, if you've transformed a murky/unnameable problem into something as crispy and quantifiable as a bus-factor=1 problem (which almost everyone understands more easily/intuitively). --- Maybe someday Team X could turn itself into a self-service platform, or a "X-as-a-service" offering, where the dependent teams do not need to have you work with or for them, but rather just consume your outputs, your service(s)/product(s), etc. at arms-length. So you probably don't always want to stay in this embedded or explicit "allocation" model.
golem14 1y ago
I'd be extremely interested if someone has managed to do this with platform-wide product features. For example, take all login procedures across Microsoft products. In my experience, this is super difficult to pull off. Individual teams don't know enough to make the right decisions, as login, recovery etc is really complex under the hood, so you need a central team handling that (even and especially the UI - you may want to have a login button appear in the same place regardless of which product you use). Having a platform-wide team controlling (part of) the OKRs of a large number of other teams does not work great, because to those teams, enforcing company wide mandates feels like a priority inversion, and is often countered with passive-aggressive behavior. I'm not too familiar with Apple product internals, but the apple ecosystem feels overall coherent. Maybe they managed?
alexpotato 1y ago
For several years I worked at a place where the median tenure was about 18 months firmwide and only 9 months on the infra (e.g. networkings, k8s, DBA etc). This is despite being a 30 year old company that paid REALLY well. The high turnover led to some interesting downstream effects: - entire teams could be let go - so you tried to remove as many dependencies on other teams as possible - e.g. "application teams" did everything from development to project mgmt to infra work (you were given VM hosts and then the rest was up to you) - this meant that app managers could focus on building their apps - the downside was whenever the overall "pipeline" had to be fixed. e.g. data enters app A then goes to B and so on. B/c everyone was so siloed, problems injected in A could flow down to D,E,F but no one was really incentivized to fix them - it also meant that changes in individual apps were REALLY fast b/c you only had to convince one person (app mgr) to change them. On the flip side, large projects took FOREVER as everyone was doing something different.
- hinkley 1y ago
  Motorola used to be described as 19 companies with the same name. And then they went bankrupt.
nyeah 1y ago
2010: Silos have a function. Closely integrated teams have a function. Functions are good. Use them both wisely to reduce complexity so you can actually get the right work done. 2025: You can choose either silos or integrated teams. From now on, you must behave as if that choice is always right and the other choice is always wrong.
- Atlas667 1y ago
  It's the era of consulting and corporate gurus. How else would you sell something? Just capitalism and its flaws.
braza 1y ago
It sounds like the same thing that Steve Yegge placed in his rant in 2011 [1] where teams should collaborate via interfaces. [1] - https://gist.github.com/chitchcock/1281611 https://gist.github.com/chitchcock/1281611
ElijahLynn 1y ago
I like parts of this. The one part that I would add is that the inter-team communication should all be made available in publicly accessible, observable ways. This way other team members can find results in their own search scope. Effectively open source when possible, inner source as a fall back. But not every team is their own private channel, restricting knowledge to that team only.
- starkparker 1y ago
  It's always striking how much easier cross-team work is when teams are both open and transparent. If a team actively shares its completed work _and_ each team reports its week-to-week work openly within the company in a system shared with other teams, it doesn't matter if there's a silo or a commune or whatever. Meanwhile, every time I get dragged into a private group DM at work for something that doesn't need privacy, I want to quit.
  - ElijahLynn 1y ago
    Same!
thelastgallon 1y ago
> “We need to break down silos between departments and get people to collaborate better” — almost every leader everywhere. Almost all 'leaders' in corporate are completely clueless. There are gatekeepers who 'manage' access to the leaders. Nobody can meet with the leaders. Every meeting with the leader is controlled by these gatekeepers. They decide who will be allowed in a meeting. And what they will present. The powerpoints will be carefully crafted to make everything a success story, the numbers massaged to show some growth of something desirable, decline of something undesirable and wins and applauds all around. Every failure is a massive success. The small number of people who are allowed in these meetings are handpicked. The gatekeeping org is full of extremely incompetent loyal lackeys who call themselves experts at executive communications, budgeting, forecasting, data analytics, etc; grant themselves high titles, more pay than engineering roles. The gatekeepers keep exceptionally good relationships with other gatekeeping orgs. Even if there is something incredibly bad in the other org, they craft a narrative and make it sound like a success story and there is something on the roadmap to improve. It is critically important for gatekeepers to keep this 'success' story because gatekeepers hire each other. Nobody else can hire them. These gatekeepers also create endless bureaucracy, hire LOTS of extreme clueless people who don't understand anything, but make high level decisions on things they don't have any clue about. Think about a dog making decisions on whether to fund cancer research vs more dog treats or chasing cars. Also, they create a LOT of systems and broken process that require their approvals. Broken processes helps empire building and also keeps them in power. Anybody who needs anything done has to reach out to them directly and they escalate within the org to get it done. Then the person owes them a favor. A working process takes power away from them. The level of cluelessness of leaders is unbelievable. The gatekeepers constantly say we need to dumb things down. This is unfathomable, because the gatekeepers themselves are headless chickens. All the leaders want is pretty ppts (and eliminate trigger works, every leader has a list of trigger words or their own arcane vocabulary that they want to use), some like bento boxes, some like sankey charts and some leaders who have seen other people ppts ask the gatekeepers that they like that specific slide from that meeting, can we have a chart like that? Source: I am an engineer now working in a gatekeeping org (in a mega corp).
- thelastgallon 1y ago
  I suspect the gatekeeping orgs collude and orchestrate the hiring of 'leaders'[1]. The sacred duty of the gatekeeping orgs is to preserve the gatekeeping org. These people are extremely well connected throughout the company. In fact, the only thing they are known for is for their connections. You might have used their services in your org, if something needed to be escalated in another org. [1] Reminds me of Bene Gesserit(https://en.wikipedia.org/wiki/Bene_Gesserit https://en.wikipedia.org/wiki/Bene_Gesserit) who install the 'leaders' they want. Except the gatekeepers have no greater mission other than keeping the gatekeeping orgs.
hitekker 1y ago
Related, from https://prachititg.com/wp-content/uploads/2014/04/the-everything-store-jeff-bezos-and-the-age-of-amazon.pdf https://prachititg.com/wp-content/uploads/2014/04/the-everyt... > At a management offsite in the late 1990s, a team of well-intentioned junior executives stood up before the company’s top brass and gave a presentation on a problem indigenous to all large organizations: the difficulty of coordinating far-flung divisions. > The junior executives recommended a variety of different techniques to foster crossgroup dialogue and afterward seemed proud of their own ingenuity. Then Jeff Bezos, his face red and the blood vessel in his forehead pulsing, spoke up. “I understand what you’re saying, but you are completely wrong,” he said. “Communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.” > That confrontation was widely remembered. “Jeff has these aha moments,” says David Risher. “All the blood in his entire body goes to his face. He’s incredibly passionate. If he was a table pounder, he would be pounding the table." At that meeting and in public speeches afterward, Bezos vowed to run Amazon with an emphasis on decentralization and independent decision-making.
- LeifCarrotson 1y ago
  I'll have to share this next week at my tiny, 20-person shop. We have a machine shop and an engineering group. ISO9001/AS9100 have stringent requirements about CAD models and print lifecycles and document management, which frequently add friction. We've got engineers who are good with their hands and could build most of the designs themselves without committing anything to CAD, and machinists/fabricators who are smart and could probably design most of the things they're building without needing a print to work towards. It's only the formal communication layer in the print release process which forces us to have accurate drawings of the things we've made and have to think through the whole design before putting a piece of steel in the mill.
  - pixl97 1y ago
    I mean the problem with software is we dont do that. I've been in so many businesses where a piece of software is turned over with almost no documentation and a partial API spec. Like, thats like a quarter of a blueprint with "do the needful" written on one corner.
torton 1y ago
This is one of key points of _Team Topologies_ (https://teamtopologies.com https://teamtopologies.com, also a book). Close collaboration between teams saps resources from both and should be either time-limited (a shared project, and then step back) or scope-limited (this team will only do close collaboration with one other team at a time).
ChrisMarshallNY 1y ago
This is a sensible idea. It really just boils down to the K.I.S.S. Principle (Keep It Simple, Stupid). Remove as many branches and variables as possible. Increase focus.
mlmonkey 1y ago
> I observed an example of this at New Relic: So, sample size == 1. :-D
adev_ 1y ago
This is honestly a pretty terrible advise. Silos have very concrete negative consequences: - In large structures, you indubitably finishes with 4 teams doing the exact same thing in parallel and ignoring each other because communication did not pass through - Managers who tend to do that tend to concentrate all communications through them. This is disastrous for multiple reasons: - It creates communication bottleneck through them and slow down the entire organization - "Filtered" information tend to have reduced technical quality that lead to wrong technical decision - Soon or later, a dubious mid manager somewhere will leverage that to make his team follow *his* agenda and not the one of the company. - On long term, isolated teams indubitably loose touch with the current mission of the organization precisely because they can not see the big picture Most people I have seen following this ill practice are some maniac micro-managers that finishes burn out after few years when they do not make their entire team burn out. The initial 'problem' that silos try to solve is the fact many-many communication in large organization does not scale. And there is absolutely no need to create 'Silos' or similar non-sense to solve that. Creating a structure where people can peer-to-peer talk freely coupled with some more broad communication nodes (All hands, Retro, etc ...) is way more productive than any silo bullshit and way less toxic as a work environment.
talkingtab 1y ago
In complex situation you can often deal with parts of a problem to the detriment of the whole. There should be some expression "its the whole, stupid", because we all tend to do this. Long ago I worked at a significant corporation. We won't name names. They decide to completely rewrite their software because the original architecture was limiting. A good decision. So for one YEAR different groups went off - in silos - and worked on their area of the project. On the day, of the release they put all the pieces together only to find that NONE OF THE PIECES fit. The company was doomed. We talk about intellectual terms - like Agile, like Silos, like whatever. None of that matters. It is intellectual. Only one thing matters. Functionality. If you get better results from thinking in silos, then that is the best. If you get best results from 'agile' then great. But to a large extend arguing agile vs silos vs some other thing is just an indication you are not paying attention to the real thing. One strategy for all of this is just "hello world". Want to build a new, shiny software thingy? On day one, get it to say "hello world". Then every day forever after make sure it can say "hello world" AND can show some new feature. Like every day demo what it can do. That's it. If you can do that in a silo, great. If you can do that in agile, or waterfall, or whatever that is great. As long as you can *show* that the product can do more today than yesterday. "Decrease collaboration". Sigh.
starkparker 1y ago
This series has come up a few times, and as someone who's worked mostly on inherently cross-functional teams (support, docs, QA) it exemplifies the most dysfunctional places that I've worked at, because it presumes that the people gating connections between silos exist, are competent at it, are incentivized toward both openness and transparency, and are held accountable if they fail. Which, in practice, never all fucking happens at once. If your job is to both facilitate and limit unnecessary communication between teams, and you systematically build your org around centralized communications chokepoints to protect R&D from product/marketing/support, you need to field and triage all of the requests made to developers for everyone else to effectively do their own jobs. As the post notes: > You want local groups to be able to act independently and have what they need to be successful. You want centralized functions to set high level objectives and coordinate where necessary to produce the right outcomes. But nobody hires for this. C-suite sure as fuck doesn't want to do it. Their direct reports treat anything that _limits_ the visibility of their accomplishments like poison. So it ends up on the next level of project/product managers, or tech leads at orgs philosophically opposed to the concept of a PM; either way, that person already has too much work to do reporting to (or shielding the devs from) upper management. I've worked in exactly one place where the company siloed with a someone who was designated as responsible for the silo and also wasn't overloaded with tasks that compromised their ability to do that. So one of a few things happen: - The people supporting customers can't get the information they need, so they do a bad job. The company defends the PMs and devs, the customers blame the people in support for incompetence, the support teams get flushed, and nothing changes for anyone. The silo has done its job; the customer is unhappy, support is ineffective, docs are written blind, the PM and devs get pulled into customer escalations between increasingly rare moments of focus. - The support teams ignore all directives from upper management, dodge the PMs, and establish direct relationships with engineers. The silo has failed; the customer is supported better, but the devs are miserable from constant moments of small distractions, and product progress slows to a grind. - The company recognizes that the Platonic model of siloing described in OP doesn't work in an org led by glory hounds (so, all tech companies) with more stakeholders outside of R&D than in it (so, most B2B and especially B2C tech companies). It then restructures teams such that _some_ of the devs are outside of the silo to deal exclusively with those requests, which works only if you have enough unicorn devs who are both good at their job, social, can independently manage unrelated projects, and consistently document their own processes. The second post in the series suggests Amazon's single-threaded ownership for inherently cross-functional teams, which is where I gave up trying to give this the benefit of the doubt. Consolidating on a single point of failure as it recommends, instead of a fourth leg on the three-legged stool focused on cross-functional tasks and org awareness, will delight a team's engineers at the disproportional expense of every other person who's forced to deal with that owner.

144 points by gpi 1y ago

Silos make sense if the product can cleanly be broken down into neat compartments. And those won't get disrupted easily. The business model is stable. Teams can have a clean, well defined, mandate. Silos don't make sense if the existence of product area might go away every 6 month. Everything is fluid, and you'll need to regularly tear apart and reform teams. The business model is not stable. Or step-change growth is sought after by investing in new markets (and foreclosing old ones). I've seen companies build structures like they're in the first category. As if things are stable. Then they need to grow or are themselves disrupted, they need to act more collaboratively across groups, or even dissolve groups. But they can't because the intentional silos have become overspecialized fiefdoms. The cost of un-siloing is high. I much prefer companies with strong cultures beyond one fiefdom. They can quickly unform or form teams as needed without a lot of nonsense. And to do that, I think you need a lot of organizational muscle about un-siloing a lot.

Xcelerate 1y ago

Hmm... I agree with parts of this and disagree with other parts. In my experience "cross-functional collaboration" splits into two distinct components: leadership and information. Anecdotal, but when leadership is split into too many people at the same level who are each in charge of a domain (that requires heavy interaction with the other domains), nothing gets accomplished—analysis paralysis and politics takes over. You absolutely need one specific person as the final decision maker. They should carefully consider all input from various sources and then make a final decision in a timely fashion. If it turns out to be the wrong path, that's fine, just reverse course quickly as well. On the other hand, information silos are absolutely horrible. The most effective companies I've worked at have always had tons of information freely available to all employees. Unless there are privacy, cybersecurity, antitrust, or similar risks involved, every employee should have access to all information across all teams. It should be easily searchable as well. There are certainly exceptions—Apple seems to function well despite all the secrecy. But most companies aren't Apple, and I don't think it's generally a good strategy.

yesfitz 1y ago

Previous discussion: https://news.ycombinator.com/item?id=28411712 https://news.ycombinator.com/item?id=28411712 I was originally critical of this piece because I work in a highly regulated industry (and silos can lead to compliance issues), but after a little more consideration, I realized I see re-siloing happening organically due to lines of business competing for scarce resources. For example: Because everyone needs Team X to complete their projects, Team X's leadership has to decide how to allocate their time. This rarely makes the lines of business feel like their needs are fulfilled. So different lines of business start building back channels to members of Team X, in a bid to get an advocate for their projects. Eventually, a line of business might hire a Business Analyst just to deal with Team X. I guess an alternative would be to embed a member of Team X with the line of business. They're dedicated, but could also be reassigned as needed.

braza 1y ago
I had some different sort of issue but in the same lines: when you have distinct goals between upstream team X and the downstream team Y. Most of my experience working in un-siloed team Y communicating only via interfaces (e.g., APIs or database views) was that most of the time we could move very fast, even in Big Co. The problem started when we had a goal, e.g. saving _n_ amount in the Snowflake account, and at the same time the upstream team X started to push so much data that it not only offset our savings but also sometimes used to make things more expensive. Since upstream X has all the upper management visibility, they could operate in a more loose way towards the downstream team, and we're basically at the whims of someone to be sensible and attend to some of our requests to ask them to stop duplicating data in our database. We only had the problem solved when this upstream team X used to share the same goal (even as a partner) in terms of savings.
strgcmc 1y ago
In such scenarios (data engineering / DS / analytics is my personal background), I have learned not to underestimate the value of, explicitly declaring within Team X, that person X1 is dedicated to line L1, person X2 is dedicated to line L2, etc. (aka similar to your last line about embedding a person with that line of business). In theory, it doesn't actually "change" anything, because Team X is still stuck supporting exactly the same number of dependencies + the same volume and types of requests. But the benefit of explicit >>> implicit, the clarity/certainty of knowing who-to-go-to-for-what, the avoidance of context switching + the ability to develop expertise/comfort in a particular domain (as opposed to the team trying to uphold a fantasy of fungibility or that anyone can take up any piece of work at any time...), and also the specificity by which you can eventually say, "hey I need to hire more people on Team X, because you need my team for 4 projects but I only have 3 people..." -- all of that has turned out to be surprisingly valuable. Another way to say it is -- for Team X to be stretched like that initial state, is probably dysfunctional, and in a terminally-fatal sense, but it's a slow kind of decay/death. Rather than pretending it can work, pretending you can virtualize the work across people (as if people were hyper-threads in a CPU core, effortlessly switching tasks)... instead by making it discrete/concrete/explicit, by nominating who-is-going-to-work-on-what-for-who, I have learned that this is actually a form of escalation, of forcing the dysfunction to the surface, and forcing the organization to confront a sink-or-swim moment sooner than it otherwise would have (vs if you just kept limping on, kept trying to pretend you can stay on top of the muddled mess of requests that keep coming in, and you're just stuck treading water and drowning slowly). --- Of course, taking an accelerationist stance is itself risky, and those risks need to be managed. But for example, if the reaction to such a plan is something like, "okay, you've created clarity, but what happens if person X1 goes on vacation/gets-hit-by-bus, then L1 will get no support, right?"... That is the entire purpose/benefit of escalating/accelerating! In other words, Team X always had problems, but they were hidden beneath a layer of obfuscation due to the way work was being spread around implicitly... it's actually a huge improvement, if you've transformed a murky/unnameable problem into something as crispy and quantifiable as a bus-factor=1 problem (which almost everyone understands more easily/intuitively). --- Maybe someday Team X could turn itself into a self-service platform, or a "X-as-a-service" offering, where the dependent teams do not need to have you work with or for them, but rather just consume your outputs, your service(s)/product(s), etc. at arms-length. So you probably don't always want to stay in this embedded or explicit "allocation" model.

golem14 1y ago

I'd be extremely interested if someone has managed to do this with platform-wide product features. For example, take all login procedures across Microsoft products. In my experience, this is super difficult to pull off. Individual teams don't know enough to make the right decisions, as login, recovery etc is really complex under the hood, so you need a central team handling that (even and especially the UI - you may want to have a login button appear in the same place regardless of which product you use). Having a platform-wide team controlling (part of) the OKRs of a large number of other teams does not work great, because to those teams, enforcing company wide mandates feels like a priority inversion, and is often countered with passive-aggressive behavior. I'm not too familiar with Apple product internals, but the apple ecosystem feels overall coherent. Maybe they managed?

alexpotato 1y ago

For several years I worked at a place where the median tenure was about 18 months firmwide and only 9 months on the infra (e.g. networkings, k8s, DBA etc). This is despite being a 30 year old company that paid REALLY well. The high turnover led to some interesting downstream effects: - entire teams could be let go - so you tried to remove as many dependencies on other teams as possible - e.g. "application teams" did everything from development to project mgmt to infra work (you were given VM hosts and then the rest was up to you) - this meant that app managers could focus on building their apps - the downside was whenever the overall "pipeline" had to be fixed. e.g. data enters app A then goes to B and so on. B/c everyone was so siloed, problems injected in A could flow down to D,E,F but no one was really incentivized to fix them - it also meant that changes in individual apps were REALLY fast b/c you only had to convince one person (app mgr) to change them. On the flip side, large projects took FOREVER as everyone was doing something different.

hinkley 1y ago
Motorola used to be described as 19 companies with the same name. And then they went bankrupt.

nyeah 1y ago

2010: Silos have a function. Closely integrated teams have a function. Functions are good. Use them both wisely to reduce complexity so you can actually get the right work done. 2025: You can choose either silos or integrated teams. From now on, you must behave as if that choice is always right and the other choice is always wrong.

Atlas667 1y ago
It's the era of consulting and corporate gurus. How else would you sell something? Just capitalism and its flaws.

braza 1y ago

It sounds like the same thing that Steve Yegge placed in his rant in 2011 [1] where teams should collaborate via interfaces. [1] - https://gist.github.com/chitchcock/1281611 https://gist.github.com/chitchcock/1281611

ElijahLynn 1y ago

I like parts of this. The one part that I would add is that the inter-team communication should all be made available in publicly accessible, observable ways. This way other team members can find results in their own search scope. Effectively open source when possible, inner source as a fall back. But not every team is their own private channel, restricting knowledge to that team only.

starkparker 1y ago
It's always striking how much easier cross-team work is when teams are both open and transparent. If a team actively shares its completed work _and_ each team reports its week-to-week work openly within the company in a system shared with other teams, it doesn't matter if there's a silo or a commune or whatever. Meanwhile, every time I get dragged into a private group DM at work for something that doesn't need privacy, I want to quit.
- ElijahLynn 1y ago
  Same!

thelastgallon 1y ago

> “We need to break down silos between departments and get people to collaborate better” — almost every leader everywhere. Almost all 'leaders' in corporate are completely clueless. There are gatekeepers who 'manage' access to the leaders. Nobody can meet with the leaders. Every meeting with the leader is controlled by these gatekeepers. They decide who will be allowed in a meeting. And what they will present. The powerpoints will be carefully crafted to make everything a success story, the numbers massaged to show some growth of something desirable, decline of something undesirable and wins and applauds all around. Every failure is a massive success. The small number of people who are allowed in these meetings are handpicked. The gatekeeping org is full of extremely incompetent loyal lackeys who call themselves experts at executive communications, budgeting, forecasting, data analytics, etc; grant themselves high titles, more pay than engineering roles. The gatekeepers keep exceptionally good relationships with other gatekeeping orgs. Even if there is something incredibly bad in the other org, they craft a narrative and make it sound like a success story and there is something on the roadmap to improve. It is critically important for gatekeepers to keep this 'success' story because gatekeepers hire each other. Nobody else can hire them. These gatekeepers also create endless bureaucracy, hire LOTS of extreme clueless people who don't understand anything, but make high level decisions on things they don't have any clue about. Think about a dog making decisions on whether to fund cancer research vs more dog treats or chasing cars. Also, they create a LOT of systems and broken process that require their approvals. Broken processes helps empire building and also keeps them in power. Anybody who needs anything done has to reach out to them directly and they escalate within the org to get it done. Then the person owes them a favor. A working process takes power away from them. The level of cluelessness of leaders is unbelievable. The gatekeepers constantly say we need to dumb things down. This is unfathomable, because the gatekeepers themselves are headless chickens. All the leaders want is pretty ppts (and eliminate trigger works, every leader has a list of trigger words or their own arcane vocabulary that they want to use), some like bento boxes, some like sankey charts and some leaders who have seen other people ppts ask the gatekeepers that they like that specific slide from that meeting, can we have a chart like that? Source: I am an engineer now working in a gatekeeping org (in a mega corp).

thelastgallon 1y ago
I suspect the gatekeeping orgs collude and orchestrate the hiring of 'leaders'[1]. The sacred duty of the gatekeeping orgs is to preserve the gatekeeping org. These people are extremely well connected throughout the company. In fact, the only thing they are known for is for their connections. You might have used their services in your org, if something needed to be escalated in another org. [1] Reminds me of Bene Gesserit(https://en.wikipedia.org/wiki/Bene_Gesserit https://en.wikipedia.org/wiki/Bene_Gesserit) who install the 'leaders' they want. Except the gatekeepers have no greater mission other than keeping the gatekeeping orgs.

hitekker 1y ago

Related, from https://prachititg.com/wp-content/uploads/2014/04/the-everything-store-jeff-bezos-and-the-age-of-amazon.pdf https://prachititg.com/wp-content/uploads/2014/04/the-everyt... > At a management offsite in the late 1990s, a team of well-intentioned junior executives stood up before the company’s top brass and gave a presentation on a problem indigenous to all large organizations: the difficulty of coordinating far-flung divisions. > The junior executives recommended a variety of different techniques to foster crossgroup dialogue and afterward seemed proud of their own ingenuity. Then Jeff Bezos, his face red and the blood vessel in his forehead pulsing, spoke up. “I understand what you’re saying, but you are completely wrong,” he said. “Communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.” > That confrontation was widely remembered. “Jeff has these aha moments,” says David Risher. “All the blood in his entire body goes to his face. He’s incredibly passionate. If he was a table pounder, he would be pounding the table." At that meeting and in public speeches afterward, Bezos vowed to run Amazon with an emphasis on decentralization and independent decision-making.

LeifCarrotson 1y ago
I'll have to share this next week at my tiny, 20-person shop. We have a machine shop and an engineering group. ISO9001/AS9100 have stringent requirements about CAD models and print lifecycles and document management, which frequently add friction. We've got engineers who are good with their hands and could build most of the designs themselves without committing anything to CAD, and machinists/fabricators who are smart and could probably design most of the things they're building without needing a print to work towards. It's only the formal communication layer in the print release process which forces us to have accurate drawings of the things we've made and have to think through the whole design before putting a piece of steel in the mill.
- pixl97 1y ago
  I mean the problem with software is we dont do that. I've been in so many businesses where a piece of software is turned over with almost no documentation and a partial API spec. Like, thats like a quarter of a blueprint with "do the needful" written on one corner.

torton 1y ago

This is one of key points of _Team Topologies_ (https://teamtopologies.com https://teamtopologies.com, also a book). Close collaboration between teams saps resources from both and should be either time-limited (a shared project, and then step back) or scope-limited (this team will only do close collaboration with one other team at a time).

ChrisMarshallNY 1y ago

This is a sensible idea. It really just boils down to the K.I.S.S. Principle (Keep It Simple, Stupid). Remove as many branches and variables as possible. Increase focus.

mlmonkey 1y ago

> I observed an example of this at New Relic: So, sample size == 1. :-D

adev_ 1y ago

This is honestly a pretty terrible advise. Silos have very concrete negative consequences: - In large structures, you indubitably finishes with 4 teams doing the exact same thing in parallel and ignoring each other because communication did not pass through - Managers who tend to do that tend to concentrate all communications through them. This is disastrous for multiple reasons: - It creates communication bottleneck through them and slow down the entire organization - "Filtered" information tend to have reduced technical quality that lead to wrong technical decision - Soon or later, a dubious mid manager somewhere will leverage that to make his team follow *his* agenda and not the one of the company. - On long term, isolated teams indubitably loose touch with the current mission of the organization precisely because they can not see the big picture Most people I have seen following this ill practice are some maniac micro-managers that finishes burn out after few years when they do not make their entire team burn out. The initial 'problem' that silos try to solve is the fact many-many communication in large organization does not scale. And there is absolutely no need to create 'Silos' or similar non-sense to solve that. Creating a structure where people can peer-to-peer talk freely coupled with some more broad communication nodes (All hands, Retro, etc ...) is way more productive than any silo bullshit and way less toxic as a work environment.

talkingtab 1y ago

In complex situation you can often deal with parts of a problem to the detriment of the whole. There should be some expression "its the whole, stupid", because we all tend to do this. Long ago I worked at a significant corporation. We won't name names. They decide to completely rewrite their software because the original architecture was limiting. A good decision. So for one YEAR different groups went off - in silos - and worked on their area of the project. On the day, of the release they put all the pieces together only to find that NONE OF THE PIECES fit. The company was doomed. We talk about intellectual terms - like Agile, like Silos, like whatever. None of that matters. It is intellectual. Only one thing matters. Functionality. If you get better results from thinking in silos, then that is the best. If you get best results from 'agile' then great. But to a large extend arguing agile vs silos vs some other thing is just an indication you are not paying attention to the real thing. One strategy for all of this is just "hello world". Want to build a new, shiny software thingy? On day one, get it to say "hello world". Then every day forever after make sure it can say "hello world" AND can show some new feature. Like every day demo what it can do. That's it. If you can do that in a silo, great. If you can do that in agile, or waterfall, or whatever that is great. As long as you can *show* that the product can do more today than yesterday. "Decrease collaboration". Sigh.

starkparker 1y ago

This series has come up a few times, and as someone who's worked mostly on inherently cross-functional teams (support, docs, QA) it exemplifies the most dysfunctional places that I've worked at, because it presumes that the people gating connections between silos exist, are competent at it, are incentivized toward both openness and transparency, and are held accountable if they fail. Which, in practice, never all fucking happens at once. If your job is to both facilitate and limit unnecessary communication between teams, and you systematically build your org around centralized communications chokepoints to protect R&D from product/marketing/support, you need to field and triage all of the requests made to developers for everyone else to effectively do their own jobs. As the post notes: > You want local groups to be able to act independently and have what they need to be successful. You want centralized functions to set high level objectives and coordinate where necessary to produce the right outcomes. But nobody hires for this. C-suite sure as fuck doesn't want to do it. Their direct reports treat anything that _limits_ the visibility of their accomplishments like poison. So it ends up on the next level of project/product managers, or tech leads at orgs philosophically opposed to the concept of a PM; either way, that person already has too much work to do reporting to (or shielding the devs from) upper management. I've worked in exactly one place where the company siloed with a someone who was designated as responsible for the silo and also wasn't overloaded with tasks that compromised their ability to do that. So one of a few things happen: - The people supporting customers can't get the information they need, so they do a bad job. The company defends the PMs and devs, the customers blame the people in support for incompetence, the support teams get flushed, and nothing changes for anyone. The silo has done its job; the customer is unhappy, support is ineffective, docs are written blind, the PM and devs get pulled into customer escalations between increasingly rare moments of focus. - The support teams ignore all directives from upper management, dodge the PMs, and establish direct relationships with engineers. The silo has failed; the customer is supported better, but the devs are miserable from constant moments of small distractions, and product progress slows to a grind. - The company recognizes that the Platonic model of siloing described in OP doesn't work in an org led by glory hounds (so, all tech companies) with more stakeholders outside of R&D than in it (so, most B2B and especially B2C tech companies). It then restructures teams such that _some_ of the devs are outside of the silo to deal exclusively with those requests, which works only if you have enough unicorn devs who are both good at their job, social, can independently manage unrelated projects, and consistently document their own processes. The second post in the series suggests Amazon's single-threaded ownership for inherently cross-functional teams, which is where I gave up trying to give this the benefit of the doubt. Consolidating on a single point of failure as it recommends, instead of a fourth leg on the three-legged stool focused on cross-functional tasks and org awareness, will delight a team's engineers at the disproportional expense of every other person who's forced to deal with that owner.