Conway's Law isn't a "law" - it is an interesting observation and there are definitely interactions (both ways) between organizational structure and software "design". But people weigh it too heavily. There are plenty of counterexamples of, for instances, fine-grained teams in one company that build a monolith, and the same type of teams in another company building a microservices architecture. Complex software is complex, and once your require more than a handful of people, that complexity requires a complex organization structure to handle the challenges of communication and responsibility. But it isn't a purely deterministic relationship between organizational structure and software structure. More that certain organizational structures are really bad at building complex software, and some are better.

It is interesting to think about, but there is this tendency to invoke "Conway's Law" as some simple method of fixing the extraordinary complex problem of developing and evolving complex software over time.

Really what it is is that organizations from the 70s, 80s, and 90s were built around building physical things, for the most part. Manufacturing and construction, mostly. And taking those organizations and applying them to software development fundamentally was a terrible match. We had to find new structures that were better suited, and we have gotten a lot better, but we are still working on it. Management was taught by those that managed manual laborers, who's output was easy to measure, and whom you could force to work a certain amount without a significant drop in their output. The same isn't true for knowledge workers. And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago.

Read Conway's original paper, it is interesting, but it isn't a physical Law that cannot be violated!