Conway's Law isn't a flaw, it's the correct way to engineer a product, whether the organization is dysfunctional or functional.
Humans working together on the same product need to communicate. The farther away they are, the more this communication becomes harder, fragile, and prone to misunderstandings.
Thus, the boundaries between their areas of responsibility must be manageable via whatever communication resources are available.
If two people are working side-by-side and constantly aware of each other's work, they can easily cooperate on a single imperative function with no isolation whatsoever.
If they're totally separate teams that normally communicate via emails and need to schedule a meeting a week in advance, then you need to have iron-clad API contracts between their codebases to enable them to work in peace. The other option is to get the teams closer, but that may simply not be possible past a certain scale - you just can't get 100 engineers to know what everybody else is doing.
Sure, if you have a team of 8 people and they have no idea what each other is doing because there are 16 middle managers wasting their time? Then yeah, you absolutely have a business problem, and Conway's Law will be a bandaid over it - you'll split the product into 8 libraries or 8 microservices, wasting a bunch of resources but keeping your engineers sane. But if you solve the problem and put the 8 engineers in a shared room so they can collaborate efficiently, and get rid of the no-longer-necessary boundaries, you're still following Conway's Law.