> 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.
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.
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'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.
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.
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.
> “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).
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.
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.
I work in an org where you can talk directly to any leader. That doesn't actually help with the outcome. The org and culture are stronger than any leader. If the org has evolved with gate keepers the leader is generally never going to remove them just because you go and complain about them.
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".
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.
This is why golden handcuffs are terrible yet organizations keep wanting to have them. Why can't CEOs understand that having lots of people around who are staying mostly because of some RSUs but wouldn't otherwise want to be there is a poison to any organization. It's weird how supposedly super smart people can't get compensation and incentives right.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
>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.
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.
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.
Do you think that the recession would make it worth more or less? Hard for me to see how this makes sense.
There's some evidence that it may be tied to commercial real estate value, in some cases.
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.
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.
A 3D scan of an object doesn't help that much if you need drawings. You're still basically doing it from scratch.
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.
> “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).
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.
Reminds me of the Civil Service in the BBC series Yes, Minster.
Bingo.
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.
I work in an org where you can talk directly to any leader. That doesn't actually help with the outcome. The org and culture are stronger than any leader. If the org has evolved with gate keepers the leader is generally never going to remove them just because you go and complain about them.
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".
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.
This is why golden handcuffs are terrible yet organizations keep wanting to have them. Why can't CEOs understand that having lots of people around who are staying mostly because of some RSUs but wouldn't otherwise want to be there is a poison to any organization. It's weird how supposedly super smart people can't get compensation and incentives right.
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.
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.
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".
That makes coasting easy for everyone.
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.
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.
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.
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.
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.
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.
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.
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.
It's the era of consulting and corporate gurus.
How else would you sell something?
Just capitalism and its flaws.
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:
- 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.
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.