How to build silos and decrease collaboration on purpose
38 comments
·October 31, 2025hitekker
no_wizard
>Bezos vowed to run Amazon with an emphasis on decentralization and independent decision-making
Well that lasted about 10 years or so. RTO mandate is the exact opposite of this.
renewiltord
I'd think it's perfectly in line with this. He wants seamless fusion at the team level. So everyone has to act uniformly consistent with that. That seems natural to me.
cheschire
What if one of the motivators of RTO was to lower the value of rural land?
During COVID, a lot of places that were considered untenable from a commuting perspective suddenly became viable options under remote work. But under RTO everyone would have to move closer to their offices again.
This would then enable the rich to more easily transfer their wealth into rural land in order to hedge a perceived coming recession. Bezos et al would benefit directly from this.
I know. It’s silly.
SR2Z
Do you think that the recession would make it worth more or less? Hard for me to see how this makes sense.
LeifCarrotson
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.
4star3star
Why don't you invest in some 3D scanning equipment/software. Build the physical object or close to it, then scan it and tweak it in software, doing the whole process backwards.
0x696C6961
A 3D scan of an object doesn't help that much if you need drawings. You're still basically doing it from scratch.
pixl97
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.
thelastgallon
> “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
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) who install the 'leaders' they want. Except the gatekeepers have no greater mission other than keeping the gatekeeping orgs.
AnonymousPlanet
Reminds me of the Civil Service in the BBC series Yes, Minster.
Spooky23
Probably the most spot on assessment I’ve read in years.
I’m kind of stuck with golden handcuffs for a time, but I’m deeply uncomfortable with the toxic behaviors I have to engage in to allow my team to thrive. It’s bad for the soul.
krackers
In addition the gatekeepers end up insulating the leaders from bureaucracy so execs end up having no idea how their company is actually being run.
SiempreViernes
Ah yes, the good king and the evil advisor, classic setup: turns out top leadership was innocent all along! /s
Obviously any exec who doesn't know how the company is being run is failing a pretty fundamental task, no real excuse possible.
pstuart
All of this needs to be traced back to the source driving all actions: incentives.
People will do what they're in incentivized to do. Yeah, it's a "duh!" statement but needs to be front and center when analyzing workflow.
Of course incentives can be gamed as well, so they should not be accepted blindly. There should be a Department of Game Theory that could help analyze and adjust accordingly to "do the needful for the same".
hassleblad23
That makes coasting easy for everyone.
darth_avocado
I came here to talk about gatekeeping and I think you described the situation pretty well.
But frankly speaking, the way corporations are being run where people are constantly being let go for profit, I would be very surprised if people are not actively gatekeeping to keep jobs. If the reward for collaboration is to assign all your work to someone else and let you go, what incentives exist for you to not gatekeep everything and collude with other gatekeepers to stay in the in group?
Ultimately it boils down to incentives. The most collaborative orgs tend to have a culture of sharing rewards and splitting the punishments. When you take that away, you’re just in the hunger games and all culture talk is just background noise.
krackers
Once the relationship becomes an adversarial one, it seems like the company is stuck in a spiral that is very hard to escape from. Employees can no longer assume good faith on behalf of the company, and will start complying with the letter instead of the spirit of incentives or policies. In turn the company is forced to tweak incentives or make policies stricter in an attempt to plug the gap. All the while increasing the amount of bureaucracy.
alexpotato
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.
Xcelerate
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.
softwaredoug
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.
yesfitz
Previous discussion: 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
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
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.
torton
This is one of key points of _Team Topologies_ (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).
ElijahLynn
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
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.
nyeah
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
It's the era of consulting and corporate gurus.
How else would you sell something?
Just capitalism and its flaws.
adev_
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.
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.
braza
It sounds like the same thing that Steve Yegge placed in his rant in 2011 [1] where teams should collaborate via interfaces.
mlmonkey
> I observed an example of this at New Relic:
So, sample size == 1. :-D
Related, from 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.