Conway's Law Is a Leadership Problem

Software architecture doesn’t exist independently of the people building it. How we divide work, define ownership, and communicate across teams influences the software we produce.

Melvin Conway described this in his 1968 paper, How Do Committees Invent?:

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

That’s the heart of Conway’s Law. Organization design isn’t just a management concern. It’s also an architectural decision.

Team boundaries become software boundaries

Teams naturally optimize for the work they own and the people they talk to most often. Engineers working closely together can make quick decisions, share context, and build tightly integrated software. Across teams, communication requires more deliberate coordination.

Neither tight nor loose coupling is inherently good. A mobile application team may benefit from owning a cohesive app experience. But if mobile and cloud engineers are organized around an individual product feature, shared cloud capabilities—like authentication—can become harder for other products to use.

The question isn’t simply whether teams should be organized by platform or product. It’s where we want strong ownership, where we need shared capabilities, and which communication paths the architecture will require.

What I saw at Control4

Control4 experimented with different organizational structures as our products and teams evolved. One of those experiments was the pillar model: teams organized around major domains of the Control4 system, each responsible for work across the software stack.

I was a Staff Software Engineer in the Listen and Watch pillar, primarily working on the graphical user interface.

Before that change, our iOS and Android applications were developed by a team we called Navigator. The applications had a cohesive architecture that made it relatively straightforward for the team to work across the app.

Under the pillar model, domain-specific code moved into separate modules owned by the individual pillar teams. Building the application meant bringing together the current versions of multiple modules. I recall roughly six or seven, although the exact number isn’t important to the lesson.

The architecture gradually began to reflect the organization. Work that had been coordinated within one team was now divided across several teams. We saw duplicated effort and different implementations of similar capabilities.

Those changes didn’t happen overnight, but they appeared quickly enough to make the relationship clear.

When we eventually moved away from the pillar model and reestablished a single Navigator team, we also consolidated the pillar modules over time. The code became easier for the application team to work with because its structure once again better matched how the team operated.

The tradeoff isn’t one-size-fits-all

The pillar model wasn’t inherently a bad idea. It created clear responsibility for product domains and brought different engineering disciplines together around customer outcomes.

But it also introduced costs where we needed consistency across those domains. Those costs showed up in integration work, duplicated solutions, and the experience of developing the applications.

A platform-oriented structure has tradeoffs too. It can encourage shared capabilities and consistent interfaces, but it can also create dependencies and handoffs that slow product teams down.

A leader has to understand those tradeoffs instead of assuming one organization chart is universally better.

Shape the organization deliberately

When evaluating a team structure, I ask:

• What should this team own end to end? Ownership needs clear boundaries.
• Which capabilities must be shared? Those shouldn’t accidentally become isolated inside a product team.
• Where will teams need to coordinate? Frequent cross-team communication is a signal worth examining.
• What architecture are we trying to enable? The organization should make that architecture practical to build and maintain.

It’s not enough to draw clean boxes on an organization chart. We need to understand the communication paths between them and how those paths influence technical decisions.

A later example: align teams with shared architecture

When I later led mobile engineering, two cross-functional Scrum teams shared one application architecture. Rather than split the architecture to match the team boundaries, I brought the teams together to make domain expertise and technical feedback accessible across the organization. I describe that decision and the broader evolution of our mobile development practices in Transforming Mobile Engineering.

What I’ve learned

Changing an organization can change the software, even when nobody sets out to redesign the architecture. The reverse is also true: if we want a different architecture, we may need to change ownership and communication patterns to make it possible.

That’s why I think of shaping the organization as part of the engineering leader’s job. We should build teams around the work and the technical boundaries we want to support, then be willing to evolve both as we learn.

Conway’s Law doesn’t prescribe a perfect organizational model. It reminds us that organizational decisions have technical consequences.