I've been at hugely decentralized companies (several thousand engineers, one level of management between me as team lead and the actual executives). Each team was fully empowered to solve their problems in the best manner and they went off and did it. It had downsides. In particular, teams often encountered similar problems, and each team solved that problem differently. There was no one in a position to see that Team A and Team D were both solving problem theta, and that Team D's solution was better, and Team A should just use Team D's (or, more often, that we needed to detail an engineer to solve problem theta fully and get both teams to use that full solution rather than the jury-rig that each team had built). There was also no one to keep us informed that Team Ssang-giyeok had already solved the issue months ago and we could just use their solution.
Internal communications like that are a scale problem: in a small company, the matrix of personal relationships is basically full, but as companies get larger, the matrix gets sparser and sparser. By the time you have a 100,000 employees in time zones all over the world your matrix is almost all 0's with only occasional 1s. And so information will travel quite poorly without people whose explicit tasks are to convey information to the right people. That's what managers and internal bureaucracy are supposed to do. Sometimes that information is "we need to build this and not that," sometimes it's "employee 24601 is great and should be given more responsibility," sometimes it's "this project is a Kafkaesque nightmare of un-ending pain that will never be delivered as scoped." But identifying this information and sharing it with the correct other people- that's what middle-management is supposed to do.
Believe me, I am not generally a fan of bureaucracy (as I type this I'm supposed to be fixing a problem that is somewhere in the interface between my 100k employee company and another 100k+ employee company, and it's goddamn terrible), but it does have value beyond just fief-building.
> In particular, teams often encountered similar problems, and each team solved that problem differently. There was no one in a position to see that Team A and Team D were both solving problem theta, and that Team D's solution was better, and Team A should just use Team D's (or, more often, that we needed to detail an engineer to solve problem theta fully and get both teams to use that full solution rather than the jury-rig that each team had built). There was also no one to keep us informed that Team Ssang-giyeok had already solved the issue months ago and we could just use their solution.
Convince me that this duplication of work is worse when you have to shoehorn solution X into solving problem theta poorly, because someone 2 degrees (or more) removed from the problem thought that problem iota (which X actually solves) was "basically the same thing" as problem theta.
> There was no one in a position to see that Team A and Team D were both solving problem theta, and that Team D's solution was better, and Team A should just use Team D's (or, more often, that we needed to detail an engineer to solve problem theta fully and get both teams to use that full solution rather than the jury-rig that each team had built)
I've seen it many times that forcing teams to use the same solution doesn't work as imagined. Often times, teams are solving similar problems. But similarity isn't grounds enough to merge a solution imo. A programming analogy is DRY. Everyone has seen what happens when you take DRY too far.
Some level of management and bureaucracy is necessary. But I think nearly every single company that's ever existed, takes this too far. There are far fewer examples of companies that under manage. I'd argue that all else being equal, under management has less downsides than over management. The reason we don't see companies with too few managers is because of individual interests.
Basically, imagine that a company has the perfectly correct number of managers (contrived example for sake of argument). Then imagine that you can choose to either add or a subtract exactly 1 manager. I am willing to bet that in the vast majority of cases, subtracting the manager leaves the company better off than adding one.
The interesting thing is that we have solved this. Groups of people much larger than single corporations work together effectively using systems like GitHub, Wikipedia, or npm, without overloading the social graph. I don't know why companies don't use similar systems internally — although I'm sure some do, but perhaps they don't advertise it, because it's a huge competitive advantage.
The modal OSS project is a one man band, or at most 2-3 people involved. By the time you get to something large scale there is also quite a bit of bureaucracy there too. Look at something like, to pick something mostly at random, a single project of the Linux Foundation, KernelCI, devoted to building CI for the Linux Kernel. And that has a Technical Steering Committee, ad hoc working groups, differentiation of responsibilities, etc. It has, for all practical purposes, just the sorts of middle management that I'm talking about.
I don't really think we have. There are many open source projects that duplicate work for a variety of reasons. Perfectly fine for stuff you want to do, but probably not an optimal allocation of resources
Internal communications like that are a scale problem: in a small company, the matrix of personal relationships is basically full, but as companies get larger, the matrix gets sparser and sparser. By the time you have a 100,000 employees in time zones all over the world your matrix is almost all 0's with only occasional 1s. And so information will travel quite poorly without people whose explicit tasks are to convey information to the right people. That's what managers and internal bureaucracy are supposed to do. Sometimes that information is "we need to build this and not that," sometimes it's "employee 24601 is great and should be given more responsibility," sometimes it's "this project is a Kafkaesque nightmare of un-ending pain that will never be delivered as scoped." But identifying this information and sharing it with the correct other people- that's what middle-management is supposed to do.
Believe me, I am not generally a fan of bureaucracy (as I type this I'm supposed to be fixing a problem that is somewhere in the interface between my 100k employee company and another 100k+ employee company, and it's goddamn terrible), but it does have value beyond just fief-building.