I’ve been working a lot with service line architecture recently. If you’re not familiar with that; it’s how business units such as IT, HR, or Sales bring services to clients, both internal and external. These structures often mirror team organization.
Think of it as a hierarchy: IT at level one, Software Development and Ops at level two, and then individual teams, like: Software Team X or Ops Team Y, at level three.
What’s surprising is how rarely these structures reflect reality. In practice, I often see people from multiple teams collaborating informally on projects. Even more striking, these same ad hoc groups reappear in project after project, suggesting a pattern that isn’t captured in the formal architecture.
If you’re a bit familiar with domain driven design, you might see some parallels with Conway’s law. And that is exactly what we’re going to talk about.
Conway’s Law
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
This is Conway’s Law, most typically applied to software systems and products. In essence, products are a direct reflection of the communication patterns within the teams that created them. How they think, talk and view the world.
I want to take it one step deeper, I believe that organizations themselves are defined by these communication structures. As a result, the products they deliver inevitably embody those same patterns.
The challenge is that these communication networks are informal, fluid, and nearly impossible to map. Yet they are precisely what shape the outcomes.
How teams actually form
... continue reading