"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Thus, if an organization is poorly-structured, it will produce poorly-structured software.
Does this imply the opposite, i.e. that if a piece of software is poorly-structured, the organization that produced it must be poorly-structured as well?
If so, this seems like quite a useful rule-of-thumb for evaluating organizations, for example in order to decide if I as an engineer should work there.
Conway's law doesn't carry good or bad connotations for organizations or software, its simply a belief that software is designed first by managers writing down the org chart.
There's three moving parts in Conway's Law:
1. The problem to be solved
2. The organization that will produce software to solve it
3. The software produced
In the years since Conway published in the 60s, we've seen a lot of industry changes. In his paper he states "there's always enough time do to it again, but never enough time to do it right," referring to the way teams would start from scratch for new clients. In today's marketplace, software is sold to multiple customers, and more often reused & improved over time. This leads to what some call "Conway's Nightmare" -- the software reflects not just today's org chart, but represents a mixture of all org charts ever.
In general I don't think you can evaluate an org structure and make any prediction about software quality. Instead, you might be able to predict quality from how closely the org matches the software product. A team that doesn't match will have endemic communication problems, fix bugs slowly, and introduce new ones between components more often. And applying this to the modern era, the more often you reorg, the more tech debt you need to pay down.