2 ms·

Many people refer to Conway's law here, but I'd argue that this law is true only for the static organization design, where structure is rigid and never changes.

Many people refer to Conway's law here, but I'd argue that this law is true only for the static organization design, where structure is rigid and never changes. This law and and the title of the link hide much more important dependency: organization is a function of business requirements. System design is a function of them too. It MAY happen that organization is designed first, but it is not necessarily the case. Organization changes happen all the time and systems tend to stay during those changes. Many companies have subdivisions organized around the customer journey or certain product topics, e.g. Acquisition tribe or B2B business unit. Those structures work very well and do not reflect the Conway's law (system architecture required in this case is often org-wide and modular, requiring all org units to follow the same design approach).

btbuildem 3y ago
It's interesting to think of this in conjunction with the Peter Principle. In any org that's existed long enough, you will have a "crust" of people who have been promoted until they're too incompetent for their position. If long enough time elapses, these incumbents will account for most of the decision makers in the org chart, from the root on down. Given how incentives and motivations change with seniority, it's not a far stretch to assume that they will want to remain where they are - cannot be promoted any further, and would rather not lose current status. I know it's just a little thought exercise, but I see enough of that reflected in the real world to pause and consider. I would wager that in majority of cases, organizational structure does indeed remain static, at least in orgs that live on long enough timescales.
MajimasEyepatch 3y ago
Conway's law would still apply in a company where the org chart is changing. Obviously old systems don't disappear in a reorg, but new ones will reflect the communication structures at the time that they were built. In companies that go through frequent reorgs, you'll often see a lot of "scar tissue," where you can tell that one set of services date back to a particular epoch. For example, these services are from a different time when the company tried to enter a new market, and here's a bunch of messy microservices from when the company added a bunch of developers after the Series C and the engineering processes failed to keep up. And along the way, you'll see a bunch of half-finished migrations that require both the old and new systems to be maintained simultaneously. In your example, if that org is adapted to frequently shifting team boundaries with some central top-down architectural authority (CTO, architect, committee, whatever), then Conway's law would predict exactly the kind of modular architecture with a "shared design approach" that you describe.
- btbuildem 3y ago
  When I look at a nightmare scenario like Salesforce, I am inclined to agree with you.
- ivan_gammel 3y ago
  >but new ones will reflect the communication structures at the time that they were built It is correlation vs causality question. Conway law may actually be the former rather than the latter.
- dredmorbius 3y ago
  I spent a fair bit of my career working with a piece of software which has evolved across a number of different operating systems, and, one presumes, development teams. Among the reasons I refer to myself, tongue in cheek, as a software anthropologist, is what I'd recognised from that software: it bears the marks of the major platforms it evolved through: IBM mainframes, VMS, Unix, MS Windows, and ultimately an Apple Macintosh variant (though principally the tool now seems to be PC-oriented). Similarly, on Unix, one can often identify applications' origins based on their toolkits and widgets: Athena Xaw widgets, Motif, VUE, KDE, GNOME, etc. Though often criticised for the lack of consistency, I'm aware that different tools reveal their affordances by the toolkits (and GUI presentation and behaviour) they reveal. Similarly BSD vs. GNU command-line tools, and various other command origins. Particularly notably, the 'dd' command, which comes from, and borrows syntax from, IBM TCL, a mainframe environment. Digging deeper, Unix's origins in Multics, the B programming language, etc., are also apparent. Again, this is somewhat confounding tools and teams, though I'd suggest that the principles are similar and related. The upshot is that past decisions get layered into software, with the oldest layers typically closest to the core.
- pvdoom 3y ago
  This. Conways law is about the actual organization, not the orgchart.
db48x 3y ago
Conway didn’t discuss how organizations change over time, but if you look for them you can see the results in the systems around you. Casey Muratori has some great examples in his video on the subject: https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY

btbuildem 3y ago

It's interesting to think of this in conjunction with the Peter Principle. In any org that's existed long enough, you will have a "crust" of people who have been promoted until they're too incompetent for their position. If long enough time elapses, these incumbents will account for most of the decision makers in the org chart, from the root on down. Given how incentives and motivations change with seniority, it's not a far stretch to assume that they will want to remain where they are - cannot be promoted any further, and would rather not lose current status. I know it's just a little thought exercise, but I see enough of that reflected in the real world to pause and consider. I would wager that in majority of cases, organizational structure does indeed remain static, at least in orgs that live on long enough timescales.

MajimasEyepatch 3y ago

Conway's law would still apply in a company where the org chart is changing. Obviously old systems don't disappear in a reorg, but new ones will reflect the communication structures at the time that they were built. In companies that go through frequent reorgs, you'll often see a lot of "scar tissue," where you can tell that one set of services date back to a particular epoch. For example, these services are from a different time when the company tried to enter a new market, and here's a bunch of messy microservices from when the company added a bunch of developers after the Series C and the engineering processes failed to keep up. And along the way, you'll see a bunch of half-finished migrations that require both the old and new systems to be maintained simultaneously. In your example, if that org is adapted to frequently shifting team boundaries with some central top-down architectural authority (CTO, architect, committee, whatever), then Conway's law would predict exactly the kind of modular architecture with a "shared design approach" that you describe.

btbuildem 3y ago
When I look at a nightmare scenario like Salesforce, I am inclined to agree with you.
ivan_gammel 3y ago
>but new ones will reflect the communication structures at the time that they were built It is correlation vs causality question. Conway law may actually be the former rather than the latter.
dredmorbius 3y ago
I spent a fair bit of my career working with a piece of software which has evolved across a number of different operating systems, and, one presumes, development teams. Among the reasons I refer to myself, tongue in cheek, as a software anthropologist, is what I'd recognised from that software: it bears the marks of the major platforms it evolved through: IBM mainframes, VMS, Unix, MS Windows, and ultimately an Apple Macintosh variant (though principally the tool now seems to be PC-oriented). Similarly, on Unix, one can often identify applications' origins based on their toolkits and widgets: Athena Xaw widgets, Motif, VUE, KDE, GNOME, etc. Though often criticised for the lack of consistency, I'm aware that different tools reveal their affordances by the toolkits (and GUI presentation and behaviour) they reveal. Similarly BSD vs. GNU command-line tools, and various other command origins. Particularly notably, the 'dd' command, which comes from, and borrows syntax from, IBM TCL, a mainframe environment. Digging deeper, Unix's origins in Multics, the B programming language, etc., are also apparent. Again, this is somewhat confounding tools and teams, though I'd suggest that the principles are similar and related. The upshot is that past decisions get layered into software, with the oldest layers typically closest to the core.
pvdoom 3y ago
This. Conways law is about the actual organization, not the orgchart.

db48x 3y ago

Conway didn’t discuss how organizations change over time, but if you look for them you can see the results in the systems around you. Casey Muratori has some great examples in his video on the subject: https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY