The Mirroring Effect
Have you ever looked at a piece of software and felt like you could guess the company's organizational chart just by seeing how the code is structured? If you have, you've experienced Conway's Law — one of the most quietly powerful forces in software engineering.
In 1967, programmer Melvin Conway submitted a paper to the Harvard Business Review that was initially rejected for lacking proof. The idea was considered too obvious to be interesting. History proved the reviewers wrong. Conway observed:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
This isn't a suggestion or a best practice. It's an empirical observation about how human communication patterns get encoded into technical artifacts. The law applies whether you're aware of it or not.
Simply Put
The way your teams are organized — who talks to whom, who reports to whom, and how information flows — will inevitably dictate the shape of the software you build.
Consider a concrete example: if you have three separate teams working on a compiler, you will almost certainly end up with a three-pass compiler. Not because three passes is the optimal design, but because each team builds their piece, and the handoffs between teams become the interfaces between compiler stages.
If you have a massive, siloed "Frontend Team" and a massive, siloed "Backend Team" who only communicate via Jira tickets, you will build a monolithic frontend tightly coupled to a monolithic backend. The human communication barriers become software architectural barriers. The org chart becomes the architecture diagram.
Why This Matters Beyond Theory
Conway's Law operates at every scale. A startup with five engineers who all sit together and talk constantly will build a tightly integrated system — which is fine at that scale. A 500-person company with 20 teams will build something that looks like 20 loosely connected subsystems — for better or worse. The law doesn't judge; it just describes. Your job as an engineering leader is to make it work for you rather than against you.
Interviewers at senior and staff-level roles often ask: "How does organizational structure affect software architecture?" The weak answer describes Conway's Law as a problem to solve. The strong answer reframes it: Conway's Law is a tool. The Inverse Conway Maneuver is how you wield it. Demonstrate that you understand causality runs both directions — org structure shapes architecture, and deliberately restructuring teams can reshape architecture.