Silos and fiefdoms allow small gelled teams who know and trust each other, have similar levels of competence, and sit physically near each other to put their heads down and execute with extraordinary speed and quality. Once silos are broken down and cross-team/cross-org collaboration becomes valorized, everything is strangers and Zoom meetings and time zones and Process and maybe if you’re lucky one person in your partner org or site who can be trusted to give a straight answer or get something done that wasn’t formally planned a year in advance. The best way to derail a project is to get the greatest number of engineers involved in it, especially engineers who don’t share priorities, timelines, conventions, geography, or language. This is coincidentally also the best way to get promoted at a large company that believes in breaking down silos.
> Silos and fiefdoms allow small gelled teams who know and trust each other, have similar levels of competence, and sit physically near each other to put their heads down and execute with extraordinary speed and quality.
...for things that align with that silo structure. If you try to build new things that necessitate conceptual integrity across org boundaries, then teams that think this way will first debate ownership and responsibility breakdown before it's even clear how the thing should work at a high level. I've seen too many examples of horrible engineering done by silo'ed teams, where they build down blind alleys that turn out to be unmaintainable and net-negative producing over time because they approached it based on what services they could touch rather than what made sense from an overall system and UX perspective.
Obviously "breaking down silos" involves greater coordination and communication overhead, and thus is harder to pull of successfully, so it's a tradeoff that should be weighed carefully in the context of business needs.
And this is another reason why managers growing their fiefdom to make big teams is bad for the organization.
Most of the most successful projects and incredible feats of engineering happen by tiny teams full of very talented people NOT a 4-layer management pyramid of people who are here for a nice stable 9-5. Not to say you can’t be successful with WLB but you need a certain fire in your gut and a hunger to execute as a small and efficient team.
I don’t disagree. But I have also seen situations where middle managers are highly attuned to and proud of cross-team projects, and basically don’t pay any attention or give any weight to value delivered for end-users within teams, so everyone is encouraged to structure their projects to maximize communication overhead (even line managers, since doing so gives them the opportunity to grow their directs).
Absolutely. There are a lot of failure modes. This is why true IC leadership with teeth is needed. The whole point of staff+ engineer roles (outside of specialist research) is to navigate the right technical decisions that span across teams.
IC leadership positions are earned by leading cross-team projects, so the senior engineers who want them (and the managers who want to grow IC leaders) are encouraged to turn everything into one.
Leadership positions should be granted not just on “projects”, but demonstrated technical ability and judgement. This often includes influence of what NOT to do just as much as it involves driving projects. Obviously any rubric is only as good as the people who apply it, and if you hire tens of thousands of smart engineers with only one really profitable product and not much in the way of vision it’s going to be a fucking mess.
But because of the stigmatization of silos and valorization of cross-team efforts, making a project cross-team when it doesn't need to be is considered an example of demonstrating the company's values rather than example of bad technical judgement.
That’s a false dichotomy and bad leadership judgement. I don’t doubt these arguments are made and sometimes won (especially in dysfunctional or apathetic orgs), but context matters, there’s no value system that supersedes critical thinking in context. One of the questions I ask in staff+ promo committee is what did this person prevent from being built.
High process and high collaboration/coordination is not the only alternative to silos.
Google in the mid aughts still had tightly aligned teams with clear priorities. But they were also transparent in what they were doing, and open to collaboration where it made sense. Teams felt empowered to reject requests that would trip them up, but also empowered to do small things to help another team (and got rewarded for doing so).
The reality at a large org is you’re going to have dependencies. In my experience, highly-siloed orgs have tremendous coordination barriers to even the smallest request across teams. Your one-line API change didn’t make it onto your dependency’s roadmap this quarter? Too bad, try again in three months.
And I’m not sure we have the same understanding of “fiefdom.” I’m talking about the pattern where middle managers try to grow their headcount as large as possible without a clear purpose other than building status within the org. This often manifests as disparate and disjoint teams aggregated under a leader who has little understanding or care as to what exactly it is they’re doing. It is hard to find value in this arrangement.
> Your one-line API change didn’t make it onto your dependency’s roadmap this quarter? Too bad, try again in three months.
This is one of the key problems of working across teams, and its impact is amplified by a culture that says you should turn everything into a cross-team project that you possibly can. The whole company grinds to a near halt on these sorts of blockages.
It’s Coase’s theory of the firm [1] in synecdoche. Silos escape the political transaction costs around them at the expense of access to external resources.
They can famously work, e.g. Skunkworks. But they also decay into fiefdoms.
I feel like you're working with a different definition of "silo" than the parent. My understanding of a "silo" is "closed off teams that aren't allowed to work with outsiders" who have their own culture that may be at odds with the company.
It seems like you're talking about team nimbleness and cohesiveness, which I want to say is orthogonal.
Building in silos is when you get something done by yourself or with your direct teammates. Cross team collaboration involves e.g. a weekly sync, coauthored design documents, code changes made in modules you’ve never seen before reviewed by people you don’t know, tasks that are critical blocking dependencies for you but totally irrelevant to the decision-makers of the teams that need to allocate time for them. The extent to which a company is siloed is the extent to which its engineers are talking to their desk neighbors and getting things done vs. navigating communication overhead and being blocked on people quite remote from them and their goals.
It’s hard to believe you could have a nimble and cohesive team at the scale of a large corporation, because the number of communication edges gets silly. Dunbar’s number and all that. You can have team nimble and cohesive teams within large corporations. But having several distinct networks is otherwise known as being siloed.
Ok how do you meaningfully define the difference and moreover how would you prevent his version of a "good" silo from devolving into a "bad" one in actuality?
Silos and fiefdoms are normally seen as negative things. And that's not entirely wrong.
But they can also describe skunkworks/internal startup/etc. teams doing their own thing without a lot of interference or having to constantly coordinate with every other organization in the company.
Breaking down silos de-risks a company, despite some of the costs you mentioned. Especially after covid, companies capitalize on the flexibility of employees and lack of (physical) offices. Employees can be replaced like never before.
But even without that in mind, breaking silos can also put the right people in the loop - for every successful silo you mentioned, I bet there is a successful company which was able to have a good mix of people from different teams.
For me it always boils down to: what does the company want? Who they want to be in the next 3-5-10 years? Based on this you need to have proper management training. Without that, they simply throw engineers at the problem, which as you mentioned, can backfire. If you as an organization are able to scale well (even with some small and monitored silos) I don't see why it should be a problem.
Reality is: companies want to be able to scale like Google for their pet projects, fire fast upon need, have a lot of teams all with the performance of 10x engineers, etc etc. That's the BS they write on their about page.
Do they have agile coaches? Do they have people that help them organize work? Skilled people, not random guy that developed software all his life and now he/she wants to try something new, and he/she read a book over the weekend or listened to some podcasts..
People have high expectations by paying little. It takes effort to do things right. That's in my opinion the truth.
