Conway's Law
en.wikipedia.org
Conway's Law
1–10 of 13 posts
Re: Conway's Law
#2I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the domain is okay but should be minimized outside of it.
Re: Conway's Law
#3Previous threads discussing Conway's Law from 1, 3, 4, 5 and 7 years ago, reflecting HN's memetic structure.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Re: Conway's Law
#4I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the…
There's a decent book about this called Team Topologies. Not necessarily the org design bible, but maybe close, and definitely addresses many specifics around this topic and your comment.
https://www.amazon.com/Team-Topologies-Organizing-Business-T...
Re: Conway's Law
#5Previous threads discussing Conway's Law from 1, 3, 4, 5 and 7 years ago, reflecting HN's memetic structure. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
What do you mean by memetic structure? As in .. ideas and their recollection and submission onto HN have some sort of structure?
I'm just curious if you mean something more than 'this gets reposted here once everyone every year or two, here's all of the other threads'.
Re: Conway's Law
#6I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the…
There's a decent book about this called Team Topologies. Not necessarily the org design bible, but maybe close, and definitely addresses many specifics around this topic and your comment. https://www.amazon.com/Team-Topologies-Organizing-Business-T...
A great read.
Re: Conway's Law
#7I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the…
Oh, it's a huge connection. When I first encountered it in my very early twenties in a list of a whole bunch of "joke" laws, I just chuckled at it, but now over 20 years later I understand it to be one of the important things for someone trying to move into the architect/principal contributor/whatever your organization calls the top level of engineer to understand.
It isn't quite a 100% constraint, but you better pick your violations of Conway's law very carefully.
Usually you have to take the design of your system from the company's organization. I still haven't quite managed to pull off the "successfully convince the company to reorganize because some technical thing they want requires it". And, I mean, obviously I don't treat that as a terminal goal in and of itself. But I do sorta hope to see it at some point. (We have at least had serious conversations about variations on that theme.)
Re: Conway's Law
#8AKA you will inevitably ship your org chart.
Re: Conway's Law
#9I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the…
I think you actually just argued for silos. Make sure small groups of people are independent and make sure they horde data.
Re: Conway's Law
#10I think there's a connection to be made between Conway's law, domain driven design, and building silos within an organization to reduce communication overhead between teams. Teams and project ownership should be structured so that teams have what they need to work on their own, with as little dependency on others as possible. The same thing goes for the services they're writing: data transfer and ownership within the…
Oh, it's a huge connection. When I first encountered it in my very early twenties in a list of a whole bunch of "joke" laws, I just chuckled at it, but now over 20 years later I understand it to be one of the important things for someone trying to move into the architect/principal contributor/whatever your organization calls the top level of engineer to understand. It isn't quite a 100% constraint, but you better pic…
I just did this at a fairly large company and it feels good... after almost a year of stress.
What worked for me was to point out the issue early, and keep pointing it out to the high level leads that could do something about it.
At the same time with my own smaller group just buckled down and delivered more, high visibility work.
When the complaints started coming in about the other groups I pointed out we could do more with a consolidated team and that design overhead was to blame for most of our problems.
In the end, there were a couple of folks who didn't make out well here and I feel bad about that. But the overall tone from various stakeholders seems to be a huge sigh of relief.