Some thoughts about Conway's law

One of my best learned from QCon San Francisco is Conway's Law, I heard it at least 3 times from different talks, especially from Michael Feather's talk. It is so striking, I never aware this before. Here is the definition of the Conway's law:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

In short, you can understand Conway's law like this:

• The software design structure is constrained or shaped by the company's physical structure;
• Your code structure mirrors your organization's structure.

This concept is quite interesting and so striking, it forced me into further thinking:

Constraints
Based on Conway's law, we can conclude:

• Good organization's structure generate good software architecture, bad organization's structure generates bad software architecture;
• The messy code base reflect its organization's messy management, the clean code base reflects the organization's clear structure;
• Management structure is quite similar as the code structure, for example, some manager like to control everything and focused on details, he does not know how to delegate, just like the "GOD Object" anti-pattern in the software development.
• The software manager's style, like/dislike and skills may also constraints the software product;
• Developer's own skills, knowledge, communication skills and ignorance level, etc, may also constraint the software product. We need to be aware of these constraints.

Conway's law in the other way
Can we good developer influence/improve organization by applying the good practices/patterns/principles?  For example, As a developer we knows how powerful the design patterns and SOLID principles to the OO design, and manager can apply those patterns to improve/refactoring the organization structure. Actually I have the idea long time ago: manage a company is like managing software, if you are a good developer you can be a good CEO or manager. We can use the software technologies to manage the company team. Although the context is quite different, they both solve the similar problems: How to manage dependency, how to make the team or software product more adaptable. 
This seems has a higher requirement for the manager, since I seldom see a manager who has a strong developer background. I really experienced how difficult it is to communicate with a non-technical background manager, it is really frustrating, and so hard to explain the issue, some time you have to translate it into an real life example to make it easy to understand. Think about it, it is so hard to let the manager to understand an issue, how could he actively find out the issue that developer himself does not aware? This is definitely an example of the Conway's law.