The Org Chart Inside the Product
Windows Vista shows how organizational boundaries can become product boundaries.
Windows Vista was enormous. More than 50 million lines of code, thousands of engineers, and thousands of individual software components, all built inside one of the largest software organizations in the world.
We usually think of software architecture as something engineers design on purpose: the deliberate decisions about which pieces exist, what they do, and how they fit together. Vista had that kind of architecture.
But it had another architecture too: the organization that built it.
What Conway actually claimed
Programmer Melvin Conway proposed the idea in 1968, in a paper called “How Do Committees Invent?” Conway submitted it to the Harvard Business Review in 1967; it was rejected for being unproven, and ran instead in the trade magazine Datamation. Fred Brooks read it, named it Conway’s Law, and repeated the claim in The Mythical Man-Month.
The claim is narrower and stranger than it usually gets remembered. Conway wasn’t saying dysfunctional organizations produce dysfunctional software. He was saying something more structural: organizations that design systems are constrained to produce designs that copy their own communication structure. Not a claim about quality. A claim about shape. Draw the lines around who talks to whom inside an organization, Conway argued, and those lines will tend to reappear in what the organization builds.
What Windows’ organization actually looked like
For most of Vista’s development, Windows was organized into three groups. Core owned the plumbing shared by every version of Windows: the kernel, storage, security, networking, device drivers, Win32. Server owned the technologies aimed at the enterprise and data center: clustering, terminal services, high availability, management tools. Client owned the desktop-facing pieces: the shell, the browser, the media player, graphics.
Ben Fathi, who managed Windows’ core development teams through Vista and into Windows 7, described that structure plainly in a 2018 retrospective: “An organization, sooner or later, ships its org chart as its product (Conway’s law); the Windows organization was no different.” He also noted a detail that matters as much as the org chart itself: in culture and structure, Core sat closer to Server than to Client for most of Vista’s life. Fathi believed that proximity mattered. Core’s closeness to Server meant more attention to scalability, redundancy, and enterprise needs, even though the same operating system also had to serve the consumer desktop. Those internal relationships were quietly shaping which product needs got the most attention.
Three organizational groups, each responsible for a corresponding part of the system. Whether the organization created those boundaries or grew around them is harder to establish. What’s striking is how hard it becomes to separate the product’s architecture from the organization behind it.
What the numbers add, and don’t
An insider’s account is a good story. It isn’t independent evidence. In 2008, three researchers tested whether information about the people and teams behind different parts of Vista could predict which parts would fail after release. Nachiappan Nagappan and Brendan Murphy at Microsoft Research, and Victor Basili at the University of Maryland, looked at things like how many engineers had worked on a component, how widely its ownership was spread across the organization, how often that ownership had changed, and how far apart the contributors were organizationally.
The results were striking. Their organizational measures identified failure-prone parts of Vista with 86.2 percent precision and 84.0 percent recall, outperforming several traditional measures based on the software itself, including code churn and code coverage.
Here’s what the study actually tested, and what it didn’t. It wasn’t a direct test of Conway’s Law. It didn’t check whether Vista’s code structure resembled Windows’ org chart. It tested something narrower: whether organizational measures could predict where the system would fail. But read alongside Fathi’s account, the result starts looking like evidence for something broader: organizational structure wasn’t merely surrounding the software. It was associated with measurable differences in what the software ultimately became.
The organization gets built into the product
None of this is really a claim about software. If three departments have to coordinate to serve one customer, the customer eventually experiences those three departments, in handoffs, in inconsistent answers, in the places where nobody was quite sure who owned the relationship. If ownership of a process is fragmented across teams, the fragmentation tends to show up in the output. If information struggles to cross an organizational boundary, whatever gets built across that boundary usually carries some evidence of the struggle. Customers experience org charts without ever seeing them.
The organization isn’t just the environment the product gets built in. The organization gets built into the product. Vista is an unusually vivid case: an insider who saw his own organization’s shape in the product it built, alongside research showing that organizational characteristics were strongly associated with where that product later failed. But the pattern doesn’t stay inside software. Look closely enough at almost anything an organization produces, and you may be looking at the organization itself.
Field Questions
- If a stranger studied only our org chart, could they sketch the rough shape of what we produce, its divisions, its handoffs, its gaps?
- Where in our product or process do customers experience our internal team boundaries directly?
- Is there a persistent seam in what we build that keeps getting treated as a technical or process problem, when it might be an organizational one?
- If we redrew the org chart tomorrow, which seams in our product would move, and which would simply reappear in a different place?
Further reading: Ben Fathi, “What Really Happened with Vista: An Insider’s Retrospective,” Medium, January 3, 2018; Nachiappan Nagappan, Brendan Murphy, and Victor R. Basili, “The Influence of Organizational Structure on Software Quality: An Empirical Case Study,” Proceedings of the 30th International Conference on Software Engineering (ICSE), 2008; Melvin Conway, “How Do Committees Invent?”, Datamation, April 1968.