We fought Conaway's law and the law won

Conway's law says systems, software, and wetware, end up shaped like the organizational structure that designed them or that they are designed for.  

Organizations understand this at some level. Much of the corporate re-organization efforts are fed by people trying to change the corporate structure to push closer together the people creating a new paradigm or system.  The other main approach is to live with the partitioning that aligns with the organizational structure allowing any global redundancy or other inefficiencies.

Video

Images used in Video

Conway's law states that software systems will be designed and built with the same alignment and partitioning as the organization that built created the software.  Teams that are closer together organizationally will build software that works better together. Teams that are farther apart will build software more loosely coupled or more error-prone.  

We see the same behavior for non-software ecosystems. 

Chevy aligns their divisions by subsystems.  Today they have sold much of their engineering and parts design to other companies further splitting up the overall design. This drives them to create a cooling system for each subsystem.  Tesla is smaller and only has one engineering group for this type of thing.  They have a single pump that handles all needs.

The Federal Government has 65 different departments that carry guns and can make arrests.  This is because the alignment of their policing structures aligns with their organizational boundaries.

System design iterates faster the closer the teams are together.  Agile is partially based on the notion that small teams can quickly make unified decisions. This means software designed by smaller teams can be more cohesive and with components that have a similar feel.

Software Systems are stronger within their organizational boundaries. Teams are rewarded for group success but are strongly rewarded for team success and punished for team failure. This becomes more true as you move up an organization. 

One way to estimate separation or risk is to count the number of layers, up and down, that must be crossed to reach the team you are cooperating with. Your influence and mindshare are inversely proportional to that.  There are situations where this is not true because of major initiatives but that is relatively rare. This picture shows a team that needs work or decisions by two other teams. One of the decisions is by a team in the same org in the same tier.  The other is in a different VP's organization where shared responsibility is 4 levels up or 7 levels of traversal.

Some executives say stuff like "our smart people will work this out".  That is true until the time where the teams have different priorities or business goals. 

Shared resource teams have their own management structure and impact other unrelated management structures. Each one of the dependent groups sees themselves as stakeholders of a priority higher than the other dependent groups or the shared team's internal responsibilities. The shared platform or resource team ends up with many virtual bosses.  Success rewards and failure accountability are also hard.  Did the piece fail because the shared team did poorly or did their partner teams wait too long or provide unclear information?

Expanding just a little, shared responsibility makes it accountability difficult. There is no "one throat to choke" in situations where the management of partner teams are far apart.

I can only really think of three ways to attack this problem

You can align the organization with the deliverable instead of fighting the organizational structure. Re-organize the teams and departments to force the organization to be shaped similar to the target architecture.  This can lead to a fairly rapid reorganization cadence as requirements or business needs change.

Accept the fact that corporate departments, towers,  will have higher coupling internally than externally.  Accept redundant systems and multiple solutions to the same problems. This can lead to security and governance issues in software projects while reducing the amount of organizational friction.

Create and empower PMOs or other oversight to try and shrink the open seam between organizational groups.   This is sort of Accept the Tower Model with an oversight Police department.

Conway's Law was derived sometime in the 1960s.  Organizations may be more nimble or more connected but this part of human nature hasn't changed. Ignore Conway's law at your own peril.