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.

This is not at all what people mean when they talk about silos

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?

"How does efficient compartmentalization become bad siloing?"

Step one: build Aa and Bb with the A and a people together, and the B and b people together.

Step two: realize you need AB and ab.

Step three: keep the same organizational structure, and try to get the A team to work with the B team ten managers and five hundred miles away.

Data point of one, but it's precisely what I mean when I talk about silos.