4 ms·

For some reason, this is a controversial idea but: it's hard to argue that multiple layers of management can become anything other than bureaucracy. Corporatio

For some reason, this is a controversial idea but: it's hard to argue that multiple layers of management can become anything other than bureaucracy. Corporations reward an individuals tenure and experience with increased decision making (often, this means manager title). That increase in decision making means that less senior IC's become less autonomous, even when they inevitably exceed their superior's experience on the topic. The level of autonomy is at odds with the number of managers. Some people argue this is a good thing. I argue that those people are just managers justifying their jobs.

mandevil 2y ago
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.
- InsideOutSanta 2y ago
  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.
  - mandevil 2y ago
    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.
  - geewee 2y ago
    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
- aidenn0 2y ago
  > 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.

mandevil 2y ago

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.

InsideOutSanta 2y ago
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.
- mandevil 2y ago
  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.
- geewee 2y ago
  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
aidenn0 2y ago
> 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.