Hacker News new | ask | show | jobs
by monkeybutton 1627 days ago
I 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.
3 comments

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.
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.)

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.

I think you actually just argued for silos. Make sure small groups of people are independent and make sure they horde data.