Lord yes. It's both. It's very much both. Small companies tend to have everyone working on the same thing. You might have a marketer, a couple engineers, etc,

Lord yes. It's both. It's very much both. Small companies tend to have everyone working on the same thing. You might have a marketer, a couple engineers, etc, but they all care about the same thing. As you grow, you silo. You have a marketing department, and an engineering department. There starts being disconnects between each group; engineers don't know what marketers are doing, marketers don't know what engineers are doing. As you get bigger still, you silo the silos. Now you have your client dev teams, maybe a couple backend dev teams, various marketing teams, some data analysis/engineering teams, etc. To get a change through, now, you have to get disparate teams, all with different criteria for success, pulling in the same direction. A lot of the time companies notice that better culture helps. It surely does. If I care about the other teams, even for things whose success/failure does not impact me directly, it leads to better results. But the core problem is one of process. It's also one of the things that these companies trying to be 'agile' have clearly missed; rather than creating a 'self-organizing team' by taking one dev from the client team, one dev from each backend team, a marketer, a data guy, etc etc, and building a team out of them, that is responsible for a feature (and it can be a somewhat ephemeral team, it just needs to be one who is responsible for the success/failure of something, and can truly own it), they've instead created "self-organizing teams" inside each silo, and then are left with trying to chart a path for a feature across all of them via project managers or similar, and it's both incredibly slow, and incredibly painful.