The org chart is an architecture diagram
Two diagrams describe every IT landscape. One is called the architecture and gets treated as technical. The other is called the org chart and gets treated as administrative. They are the same diagram, separated by a time delay.
In 1968, Melvin Conway observed that organizations design systems that mirror their own communication structures. Half a century of software later, the observation has hardened into something close to a law, because the mechanism is mundane. Interfaces appear where teams hand off, because a handoff needs an agreement and an agreement needs a boundary. Monoliths grow where a single team owns everything, because nothing ever forces a seam. And every long-lived integration mess in your landscape maps, with unsettling precision, onto an organizational seam that nobody actively manages.
Three consequences leaders underuse
First, you cannot fix with architecture what the org chart breaks. Draw a clean boundary between two systems owned by teams that do not talk, and you get a clean line on the slide and a mess in production, because the daily communication that would keep the boundary honest does not exist. Second, every reorganization is an architecture decision. Split a team, and within a couple of years its system will split too, along whatever line you cut, including a thoughtless one. Third, and most useful, the law runs in reverse. If you want a platform to exist, create the team whose explicit job is that platform, with real ownership and a real interface to its consumers. The system will follow the structure, because it always does.
Designing both diagrams at once
The practical discipline follows directly. Stop designing target architectures and organizational structures in separate committees on separate calendars. When the two diagrams disagree, believe the org chart, because it is the one that will win. Place organizational seams where you can afford interfaces: at boundaries that are stable, well understood, and worth their coordination cost. Keep together what must change together. And give every boundary exactly one owner, because a shared box on the org chart reliably becomes a shared mess in the landscape.
What this means for a technology leader
It means organizational design is not the soft part of the job that happens between architecture reviews. It is the hardest architectural instrument you have, with the longest lever and the slowest undo. Teams are how strategy gets compiled into systems, and the compiler has no warning messages.
Every reorganization is an architecture review, whether it was run as one or not. The only question is whether the architecture that results was designed, or merely inherited from wherever the boxes happened to fall.