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.

> “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).

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.

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.

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.

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.

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).

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.

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.

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.

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

> I observed an example of this at New Relic:

So, sample size == 1. :-D

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.

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.

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?

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.