3 ms·

Do you think Conway's law also works in reverse? If you start as solo dev and then expand, will your org chart resemble the architecture? Can you plan your or

by k__ 6y ago

Do you think Conway's law also works in reverse? If you start as solo dev and then expand, will your org chart resemble the architecture? Can you plan your org chart by thinking hard enough about your architecture?

blowski 6y ago
There is such a thing as an “inverse Conway maneuver” where you do exactly that.
corpMaverick 6y ago
On the second question. Yes, you definitely should shape your org chart the way you want your architecture to be shaped.
- k__ 6y ago
  Ah, is this the third way? Don't shape your architecture, shape your org, then your architecture will follow.
gregw2 6y ago
At my large corp, we try to figure out and align stakeholders on the target tech architecture we want, and then sort the org structure out second as our way of mitigating the distortions that come with Conway's law. More towards your question, having also been in a mildly successful startup, I think there is a certain amount of layering in your architecture that you can setup on day one (frontend vs backend), but so much success rests on execution and product fit and such that it's not worth wasting too many cycles overoptimizing the architecture if you aren't already opinionated on it. Go with the architecture that you can iterate rapidly with. While I haven't been a solo dev, I'd ask myself the question "what work will I offload once I can afford to, and what architecture do I need to create so that next 1-3 persons able to work without a ton of my time?" Iterate from there.
iujjkfjdkkdkf 6y ago
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!
akra 6y ago
I've seen it work in reverse when the systems are just "too hard" to change. Think old legacy systems with large monolithic mainframe architectures as an example. Because it costs too much money to change them and the business needs to keep running many restructures just fail and managers just keep dropping. I see Conway's law as an equals relationship IMHO, not a cause. The side that can give ends up adapting to the side that can't. In newer business where the architecture isn't established of course the structure influences the design. As the architecture matures and is worth a lot of money to replace it sometimes switches the other way. This of course can kill a lot of big corp's and IMO one of the biggest reason they may seem less agile to startup dev's - they have so many use cases to handle and systems have grown so complex it is a lot of effort to understand yet alone modernize these architectures. Often as well because they have been successful for awhile the regulators/governments have caught up with them and they have obligations that aren't so easily depreciated in any replacement.

by k__ 6y ago

blowski 6y ago

There is such a thing as an “inverse Conway maneuver” where you do exactly that.

corpMaverick 6y ago

On the second question. Yes, you definitely should shape your org chart the way you want your architecture to be shaped.

k__ 6y ago
Ah, is this the third way? Don't shape your architecture, shape your org, then your architecture will follow.

gregw2 6y ago

At my large corp, we try to figure out and align stakeholders on the target tech architecture we want, and then sort the org structure out second as our way of mitigating the distortions that come with Conway's law. More towards your question, having also been in a mildly successful startup, I think there is a certain amount of layering in your architecture that you can setup on day one (frontend vs backend), but so much success rests on execution and product fit and such that it's not worth wasting too many cycles overoptimizing the architecture if you aren't already opinionated on it. Go with the architecture that you can iterate rapidly with. While I haven't been a solo dev, I'd ask myself the question "what work will I offload once I can afford to, and what architecture do I need to create so that next 1-3 persons able to work without a ton of my time?" Iterate from there.

iujjkfjdkkdkf 6y ago

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!

akra 6y ago

I've seen it work in reverse when the systems are just "too hard" to change. Think old legacy systems with large monolithic mainframe architectures as an example. Because it costs too much money to change them and the business needs to keep running many restructures just fail and managers just keep dropping. I see Conway's law as an equals relationship IMHO, not a cause. The side that can give ends up adapting to the side that can't. In newer business where the architecture isn't established of course the structure influences the design. As the architecture matures and is worth a lot of money to replace it sometimes switches the other way. This of course can kill a lot of big corp's and IMO one of the biggest reason they may seem less agile to startup dev's - they have so many use cases to handle and systems have grown so complex it is a lot of effort to understand yet alone modernize these architectures. Often as well because they have been successful for awhile the regulators/governments have caught up with them and they have obligations that aren't so easily depreciated in any replacement.