[HN Gopher] How to build silos and decrease collaboration on pur...
___________________________________________________________________
How to build silos and decrease collaboration on purpose
Author : gpi
Score : 96 points
Date : 2025-10-31 19:16 UTC (3 hours ago)
(HTM) web link (www.rubick.com)
(TXT) w3m dump (www.rubick.com)
| softwaredoug wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nyeah wrote:
| 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 wrote:
| It's the era of consulting and corporate gurus.
|
| How else would you sell something?
|
| Just capitalism and its flaws.
| braza wrote:
| 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
| ElijahLynn wrote:
| 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.
| thelastgallon wrote:
| > "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 wrote:
| 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 wrote:
| Reminds me of the Civil Service in the BBC series Yes,
| Minster.
| hassleblad23 wrote:
| That makes coasting easy for everyone.
| Spooky23 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| darth_avocado wrote:
| 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 wrote:
| 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.
| pstuart wrote:
| 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".
| hitekker wrote:
| 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.
| LeifCarrotson wrote:
| 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 wrote:
| 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.
| 4star3star wrote:
| 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 wrote:
| A 3D scan of an object doesn't help that much if you need
| drawings. You're still basically doing it from scratch.
| no_wizard wrote:
| >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 wrote:
| 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 wrote:
| 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.
| torton wrote:
| 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).
| ChrisMarshallNY wrote:
| 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 wrote:
| > I observed an example of this at New Relic:
|
| So, sample size == 1. :-D
| adev_ wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-31 23:00 UTC)