Conway’s Law is the idea that software represents the organization that created it. It is often described wherein the organization creates design, like “Four developers make a compiler and you get a four-pass compiler.” But it could also make sense that it would go the other way. There is a three tier architecture and as you scale up you end up with teams for each tier. Is either causal relationship more true than the other?
The initial paper describing the concept seems to be arguing for the former, but the examples I’ve seen have been more the latter. The team grew after the software started and then you brought in additional teams to scale out development that were given responsibility for a chunk of the system. I went looking for data about this and was unable to find any, so I’ll propose a thought experiment. You’ve got an existing system with three teams working on four parts. If you were to create a fourth team and not have them work on any particular part, how do you think it would go? I see frustration until responsibilities shift to make space for the new team. What about with the same three teams and the same four parts, creating a fifth part and having an existing team own it? That situation seems like it would work fine.
“Your org structure isn’t solving your problem. It’s an artifact of how it was solved before” – Adam Jacob (I’m assuming the one from Chef). This seems to support that the system grew the organization around it, not that the system reflects a preexisting organizational structure. If the system influences the organization to this degree, then that means as we architect software we wield outsized influence of the organization that will form around it.
This influence can’t fix all organizational structural problems, but it can be used to help guide the organization’s growth. I recognize that there’s a bit of a cart before the horse problem, in that if your organization has set staffing level budgets by team, you’re probably stuck with those and can’t easily reallocate each team’s staffing level to what you’d like the development to reflect. You can, however, structure responsibilities so each team owns multiple things, rather than one big thing. This would allow you to grow a team and then split it and split up their responsibilities to the resulting teams.
Chaotic Good Programming 