4 ms·

I think the article has some good points about interpersonal comms and alignment problems and their solutions but doesn't actually mention some of the structura

I think the article has some good points about interpersonal comms and alignment problems and their solutions but doesn't actually mention some of the structural / political issues associated with really large organisations. For example, I have worked at or seen organisations that are actually loose groupings of 'cottage industries' (often called divisions or similar) that have separately evolved local solutions to problems (technical /commercial, etc) with a small centralised head-office. Moving between divisions is hard because they are running separate systems. Aligning their processes can improve efficiencies but can also lead to loss of local knowledge or inappropriate one-size-fits-all solutions.

Agentlien 5y ago
The biggest example of your last point that I've seen first hand is Electronic Arts and Frostbite. Mandating that all EA games be made with their own engine has caused so many delays, rushed games, and broken products by teams who have already proven they can deliver amazing games on their own terms.
Macha 5y ago
I worked for such a fragmented company before. The team I joined was effectively still the startup that had been acquired by that company 7-8 years prior to my joining. Since the group continued to make profits that were growing most of the time, they were largely left autonomous by head office for 90% of their work even over such a large time period. There were people in some of the US offices which formerly had belonged to that startup that would describe themselves as working for that startup despite joining after the startup had already been absorbed into the parent company. This division wasn't the only such division in the company. There were certainly negatives, an internal transfer was effectively a new hire, just one who already had their email/git/vpn access sorted and probably already spoken to a few of the cross org teams like IT or security, but overall I never felt as much organisational friction as other teams I've worked in large companies. Anyway, the parent company was acquired by a much larger one, that much larger one acquired a similar size company with a much more top down/unified approach to direction, and given that unified approach they were much more effective at selling a vision to our parent companies execs, so a lot of them were put in charge despite the original parent company being profitable and the new acquisition not being so. There was a big push to standardise/centralise/etc. and in that time a few products stagnated and we lost customers. The newly acquired company has a pretty poor track record in dead/broken acquisitions from this pattern, so it shouldn't have been news that prioritizing this has costs. There was a lot of grumbling at being made move to "standardised" solutions that were suboptimal in meaningful ways, but were preferred at high levels because they were homegrown. Everything certainly took longer in the new company, dealing with centralised, barely informed non-stakeholders who still had red tape in place to get anything done, along with a strong impulse to just copy other teams rather than come up with a solution that cleanly and effectively solves the problem. I left during this process, and a lot of the people who were the core of the startup-turned-business-unit also left, the largest group now at a rapidly growing competitor.
- KineticLensman 5y ago
  > Everything certainly took longer in the new company, dealing with centralised, barely informed non-stakeholders who still had red tape in place to get anything done, along with a strong impulse to just copy other teams rather than come up with a solution that cleanly and effectively solves the problem. Yes. The last place I worked was a UK organisation that had around 5000 staff, many of whom were software engineers. The org was divided into 5 or so different divisions, each of which had its own customers, sales teams, PMs, etc. Crucially, each division had its own resourcing function, so new projects could exploit local knowledge to find engineers who had domain knowledge, and could even consider career development opportunities when picking staff for new bids/projects ('Fred is interested in trying this, he's not a perfect fit but is competent and motivated to learn'). Anyway, a new CEO (who himself had an engineering background) joined the organisation and apparently in an early meeting asked 'how many engineers do we have across the company?'. Nobody actually knew. So after a while he started an initiative to launch a company wide resource management process. Although well intentioned, it was a disaster. We ended up with global resource managers who didn't actually know any of the people concerned. A lot of our work was specialised engineering (e.g. simulation development, signal processing, etc) and it proved impossible to develop a global skills framework with all of the right categories. After a very painful year, bid teams and projects reverted to local resourcing to find the staff who had relevant skills and domain knowledge. I'm not against standardizing things across organisations (indeed, my main function was trying to drive technical commonality) but like optimization, you have to choose the right things to standardize, and the right things to leave untouched.

Agentlien 5y ago

The biggest example of your last point that I've seen first hand is Electronic Arts and Frostbite. Mandating that all EA games be made with their own engine has caused so many delays, rushed games, and broken products by teams who have already proven they can deliver amazing games on their own terms.

Macha 5y ago

I worked for such a fragmented company before. The team I joined was effectively still the startup that had been acquired by that company 7-8 years prior to my joining. Since the group continued to make profits that were growing most of the time, they were largely left autonomous by head office for 90% of their work even over such a large time period. There were people in some of the US offices which formerly had belonged to that startup that would describe themselves as working for that startup despite joining after the startup had already been absorbed into the parent company. This division wasn't the only such division in the company. There were certainly negatives, an internal transfer was effectively a new hire, just one who already had their email/git/vpn access sorted and probably already spoken to a few of the cross org teams like IT or security, but overall I never felt as much organisational friction as other teams I've worked in large companies. Anyway, the parent company was acquired by a much larger one, that much larger one acquired a similar size company with a much more top down/unified approach to direction, and given that unified approach they were much more effective at selling a vision to our parent companies execs, so a lot of them were put in charge despite the original parent company being profitable and the new acquisition not being so. There was a big push to standardise/centralise/etc. and in that time a few products stagnated and we lost customers. The newly acquired company has a pretty poor track record in dead/broken acquisitions from this pattern, so it shouldn't have been news that prioritizing this has costs. There was a lot of grumbling at being made move to "standardised" solutions that were suboptimal in meaningful ways, but were preferred at high levels because they were homegrown. Everything certainly took longer in the new company, dealing with centralised, barely informed non-stakeholders who still had red tape in place to get anything done, along with a strong impulse to just copy other teams rather than come up with a solution that cleanly and effectively solves the problem. I left during this process, and a lot of the people who were the core of the startup-turned-business-unit also left, the largest group now at a rapidly growing competitor.

KineticLensman 5y ago
> Everything certainly took longer in the new company, dealing with centralised, barely informed non-stakeholders who still had red tape in place to get anything done, along with a strong impulse to just copy other teams rather than come up with a solution that cleanly and effectively solves the problem. Yes. The last place I worked was a UK organisation that had around 5000 staff, many of whom were software engineers. The org was divided into 5 or so different divisions, each of which had its own customers, sales teams, PMs, etc. Crucially, each division had its own resourcing function, so new projects could exploit local knowledge to find engineers who had domain knowledge, and could even consider career development opportunities when picking staff for new bids/projects ('Fred is interested in trying this, he's not a perfect fit but is competent and motivated to learn'). Anyway, a new CEO (who himself had an engineering background) joined the organisation and apparently in an early meeting asked 'how many engineers do we have across the company?'. Nobody actually knew. So after a while he started an initiative to launch a company wide resource management process. Although well intentioned, it was a disaster. We ended up with global resource managers who didn't actually know any of the people concerned. A lot of our work was specialised engineering (e.g. simulation development, signal processing, etc) and it proved impossible to develop a global skills framework with all of the right categories. After a very painful year, bid teams and projects reverted to local resourcing to find the staff who had relevant skills and domain knowledge. I'm not against standardizing things across organisations (indeed, my main function was trying to drive technical commonality) but like optimization, you have to choose the right things to standardize, and the right things to leave untouched.