Casey Muratori has an excellent lecture on this same topic, which draws many of the same conclusions as this article but goes into more depth on why it happens

Casey Muratori has an excellent lecture on this same topic, which draws many of the same conclusions as this article but goes into more depth on why it happens and what it means to you in a practical sense. (https://youtu.be/5IUj1EZwpJY https://youtu.be/5IUj1EZwpJY, skip to 15:30 as the beginning is about setting up the idea of software laws, discussing other candidates for strong software laws, and the history of the law.) The Cliffs notes if you don’t have time for 45 minutes of video: Conway’s Law is pithily stated as “org charts reproduce themselves in the product”, or more comprehensibly as “the software architecture will resemble the org chart of the company producing it”*. The mechanism of this effect is communication bandwidth. Communicating inside a team is high bandwidth; between teams is low bandwidth and multiple lossy hops, with the problem getting worse the further teams are away in the org chart. What this means for you is that when you set down an org chart (which you have to do at least a little bit before even getting started), or when you change an org chart, you are eliminating any potential architectures that don’t look like that org chart. There If you split your teams into frontend and backend, you are ruling out potential architectures that would mix or closely intertwine the two. Any architecture like that would require the two teams to work together intimately, taking steps in tandem, which they cannot do because the low bandwidth cross-team communication cannot support it. Later in the video he also adds another interesting consideration, which is that Conway’s Law persists in long-lived projects; because yesteryear’s org chart reproduced itself in the software architecture and today’s development efforts have to engage with the existing architecture, you are not just constrained by your org chart, but rather (in some sense) constrained by every org chart you’ve ever had. The main point of Conway’s Law is that when you are making your org chart, you are also choosing the destiny of your product, in ways you might not realize. Some actionable steps from this point might be “if you want a unified consistent UI, you need a single UI team with responsibility for all parts of the UI”, or “if you want good integrated graphics in your CPU, you can’t have separate GPU and CPU departments”. * There are examples showing this is an unusually strong effect. Microsoft had a graphics and an audio team; for graphics split into a subteam for 2D and a different subteam for 3D, for audio they split into a subteam for music and a different subteam for sound effects. As a result you get these APIs in the final code: Direct2D, Direct3D, DirectMusic, and DirectSound. The Music and Sound subteams got combined; DirectMusic and DirectSound got deprecated and merged into XAudio.