6 ms·

I worked at a place where the org structure had been heavily influenced by software architects. And I found that there was way too much of a "this team will com

I worked at a place where the org structure had been heavily influenced by software architects. And I found that there was way too much of a "this team will come in at this point to do this" kind of coordination assumed in the org design that may be possible with software, but works very poorly with actual people. People did not see the value in handing off or involving other groups just because the org plan said to, there were not proper accountabilities, and there was tons of communication overhead as groups flitted in and out of involvement and debated who had what responsibility. Obviously you can't blame all that on software architecture, but it is a danger that comes with architecting an org in the same way as code, and expecting it to work once animated.

Jtsummers 6y ago
Were they, by chance, from an industrial/manufacturing background or from Waterfall projects? Those are the ones I see trying to establish what you describe. Often there's a notion that the teams are operating in a pipeline/production flow similar to manufacturing. So you hand X off to the designer to do their thing, they hand it to the devs (may be multiple teams), then the designer is working on the next design (either an iteration of the current one or a different system), repeat down the chain. I've only seen this work well in highly-repetitive, relatively low-skill/knowledge required workloads. Not knocking the participants, but there was often little novelty or real troubleshooting involved in those projects (often troubleshooting was handed off to a specific individual or group and the regular staffers weren't responsible for it).
k__ 6y ago
Good point!