You can actually use the SOLID heuristics that people use to evaluate code quality to also look at organizational quality and the quality of decision making in

You can actually use the SOLID heuristics that people use to evaluate code quality to also look at organizational quality and the quality of decision making in organizations. Larger amounts of managers means more levels of indirection and more opportunity for miscommunication, conflicts of interest, and other negative patterns. The way to fix a broken software organization is similar to how you would refactor a faulty code base. You start by looking at the most complicated bits and refactor those to be simpler and easier to understand. You might also profile things a bit: where are things getting stuck in the organization. And so on. Either way, the fixes tend to be similar as well: remove unnecessary levels of indirection (layers of management). Look for places with lots of dependencies. Look for ways to increase cohesiveness and reduce coupling. Etc. How do you improve cohesiveness and reduce coupling? Break teams up. Have less managers. Reduce their interfaces to each other. Shorten the lines of communication. If you know your SOLID principles, that should sound familiar. Large organizations do the same as bloated code bases: when in doubt, they add people (more code) to fix issues. So, you get a lot of functional duplication because this part of the organization is just in the wrong part of the org tree to be off use to that part. So, they hire their own people to do the same. And some more managers to manage those, which then fractally make things worse. And you get this culture of fracturing responsibilities across large amounts of teams and those teams having to work around each other. That's how Google ended up with a few dozen different chat clients. Instead of just one good one. They are still figuring that one out.