3 ms·

Another way to be "bloated" is to have a lot of teams working very hard on systems/projects that don't add value to the overall business. Those teams will still

Another way to be "bloated" is to have a lot of teams working very hard on systems/projects that don't add value to the overall business. Those teams will still manage out their low-performers and run a ruthless environment, but the folks that remain continue to work hard without providing value. Add new systems/projects underneath because people want more scope and responsibility, repeat through a few cycles, and you arrive at the quoted line.

LanceH 4y ago
The biggest bloat I've found in big companies is duplicate teams. You have one problem needing to be solved and a couple VP's running a program trying to make it happen under their domain. I generally see this play out as, one team trying to tackle the problem with a prototype and demonstration of tech. The other team just acquires as many people as possible and writes a bunch of documents. Then it gets run up the flag pole and the solution seems to be to go with the team that already has all the people.
- fdye 4y ago
  I used to see this occasionally and always see it as wasteful. However, there is another angle here. Imagine your a C-Suite or senior level manager and you have lots of resources at your disposal. Now you have identified a strategic widget you need to get to within some timeframe, say 2 years to lay into your grand strategic vision. Scenario A: Task a single team, staff them and let them do their thing. Cross your finger and hope they get it done. Scenario B: Look across offices, org groups, whatever, and task 2-3 (sometimes more) teams with your task. Let them start work on it and get regular demos and updates. Eventually, pick a winner. B looks very wasteful from the outside, until you realize that many software projects fail (like 50%). So more attempts give you a higher chance of success. Downside: Internal politics, waste, attrition from engineers throwing away code/busy work. A is great if you can do it, but you're putting all your eggs in one basket. A lot of times this is just bad org/bureaucracy though, but it can be done to great effect. Disclaimer: Worked for a CEO with a large outsourced engineering base and several offices. Would see multiple attempts at different offices all the time. Eventually, grudgingly acknowledged there was a method to that madness. Trump also is famous for this (although his seemed more madness).
  - vkou 4y ago
    Scenario B very rarely happens. What actually happens is Scenario C - it doesn't arise from a top-down planner mandating it, it arises from middle managers (or their subordinates) further down the food chain each trying to grow their own kingdom, who all get the same idea at roughly the same time, and each build their own solution to the same problem. During times of plenty, or if the top-level planner is only absent-mindedly managing that part of their org, the firm will be willing to tolerate these competing implementations, but during lean times, they cut, cut and cut and consolidate down to one winning solution. A lot of corporate politics and strategy makes a lot more sense when you start looking at the personal motivations of the participants in it.
    - fdye 4y ago
      Agreed, C is also a very real possibility.

LanceH 4y ago

The biggest bloat I've found in big companies is duplicate teams. You have one problem needing to be solved and a couple VP's running a program trying to make it happen under their domain. I generally see this play out as, one team trying to tackle the problem with a prototype and demonstration of tech. The other team just acquires as many people as possible and writes a bunch of documents. Then it gets run up the flag pole and the solution seems to be to go with the team that already has all the people.

fdye 4y ago
I used to see this occasionally and always see it as wasteful. However, there is another angle here. Imagine your a C-Suite or senior level manager and you have lots of resources at your disposal. Now you have identified a strategic widget you need to get to within some timeframe, say 2 years to lay into your grand strategic vision. Scenario A: Task a single team, staff them and let them do their thing. Cross your finger and hope they get it done. Scenario B: Look across offices, org groups, whatever, and task 2-3 (sometimes more) teams with your task. Let them start work on it and get regular demos and updates. Eventually, pick a winner. B looks very wasteful from the outside, until you realize that many software projects fail (like 50%). So more attempts give you a higher chance of success. Downside: Internal politics, waste, attrition from engineers throwing away code/busy work. A is great if you can do it, but you're putting all your eggs in one basket. A lot of times this is just bad org/bureaucracy though, but it can be done to great effect. Disclaimer: Worked for a CEO with a large outsourced engineering base and several offices. Would see multiple attempts at different offices all the time. Eventually, grudgingly acknowledged there was a method to that madness. Trump also is famous for this (although his seemed more madness).
- vkou 4y ago
  Scenario B very rarely happens. What actually happens is Scenario C - it doesn't arise from a top-down planner mandating it, it arises from middle managers (or their subordinates) further down the food chain each trying to grow their own kingdom, who all get the same idea at roughly the same time, and each build their own solution to the same problem. During times of plenty, or if the top-level planner is only absent-mindedly managing that part of their org, the firm will be willing to tolerate these competing implementations, but during lean times, they cut, cut and cut and consolidate down to one winning solution. A lot of corporate politics and strategy makes a lot more sense when you start looking at the personal motivations of the participants in it.
  - fdye 4y ago
    Agreed, C is also a very real possibility.