How to build silos and decrease collaboration on purpose
rubick.com
rubick.com
> 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 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.
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.
Well that lasted about 10 years or so. RTO mandate is the exact opposite of this.
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.
Politics-wise, I benefit from learning from Fisher (but obviously the reverse isn’t true). So it’s reasonable to say my views are more informed.
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).
[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.
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.
Obviously any exec who doesn't know how the company is being run is failing a pretty fundamental task, no real excuse possible.
The result of this is that I meet directors less often than anyone else and am not actually sure what a director even does.
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.
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".
This is not necessarily being clueless. It's more about being powerless against organizational forces. I've seen accessible strong leaders, with strong beliefs in culture, having their culture subverted by middle management and "organization".
I witnessed this on the past two YC startups I worked at, on adjacent teams.
There was a very clear strategy laid out by the founders, but engineers were unable to follow it due to a filter added by a "layer" of management.
For example: In one specific case, a designer (!) was massively bloating the design and the scopes after being given carte blanche by the CEO and the absence of the PM. After a few weeks of missing targets where engineers got the blame, the tech team finally had enough and requested a review of the work methods of the designer. It was obviously all very fucked up. Basically weeks of lost work and a burned out team working overtime.
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
But cross purposes get in there and even if you know what the EM or CTO really wants the PM may be hell bent to give them something else. And use narrative to explain why it tastes funny.
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.
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.
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.
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.
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.
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.
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.
Meanwhile, every time I get dragged into a private group DM at work for something that doesn't need privacy, I want to quit.
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.
How else would you sell something?
Just capitalism and its flaws.
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.
So, sample size == 1. :-D
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.
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.
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?
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.