Conway’s Law: Why Your Org Chart Is Quietly Breaking Your Product
And How to Design your organization for speed, ownership, and clarity
In this issue:
The Hidden Cost of ‘Simple’ Work
What Conway’s Law Really Means
How Your Org Design Shapes Culture and Impact
Putting Conway’s Law Into Practice
The One Shift: Design Teams Like You Design Systems
How This Plays Out in Real Teams
Common Pitfalls (and How to Avoid Them)
Final Thoughts
The Hidden Cost of ‘Simple’ Work
At one point early in my career as an engineering manager, I had a ‘frontend team’, a ‘backend services team’, and a ‘desktop team’. In the org chart, it looks nice and cleanly organized.
But every change in our product needed coordination across all three teams. One team would finish their part and “wait” for the next team to “deliver” their work. Several meetings, multiple wikis, and dozens of Jira tickets later, the feature would finally get tested and delivered.
Over time, I realized the problem wasn’t the people, or the effort, or even the process. The real problem was the way I had structured my teams. The simple feature was taking weeks to ship, not because it was hard, but because it was touching three teams. Small changes turned into a chain of dependencies simply because of the way the teams were organized.
At the time, I used to think system design was about architecture diagrams, APIs, and technology choices, but the way I had structured my teams was shaping the system far more than any technical decision we made.
This phenomenon is popularly known as Conway’s Law.
I’ve seen this show up in almost all organizations I’ve worked at, and, should I say, it is one of the elephants in the room that nobody wants to talk about. As the illustration above (somewhat hilariously) demonstrates, every company has its own structure, and that, in turn, influences how and what they deliver.
In this issue, I will discuss Conway’s Law from a practical standpoint - why organizational design matters, and how you can proactively set up your teams for speed, ownership, and clear execution without “shipping your org chart.”
Ready to dive in? let’s go!
What Conway’s Law Really Means
Coined by Melvin Conway in 1967, Conway’s Law says that organizations design systems that mirror their communication structure.
In plain terms, your system will look like your org chart. If your teams are split into frontend, backend, and platform, your system will likely follow the same boundaries. If your teams don’t talk well, your systems won’t integrate well either.
But what do we mean by systems here? Systems could be the product that you’re shipping, or the services that you’re making available to your customers. I like to think of it as anything that is externally visible to customers, not just products or services, but even things like customer support.
Let’s go back to my own example from earlier.
Since I had three teams set up (backend, frontend, and desktop) to deliver a feature, the system we built reflected that. It was split across layers, with dependencies between them. Every handoff between teams became a dependency in the system.
And unsurprisingly, over time, these dependencies would pile up. What would start as a clean design turns into something slow and hard to change.
Another way to think about Conway’s Law is this: You don’t design systems directly. You design the organization, and the system follows. Every team boundary becomes a system boundary, and every communication gap becomes a point of friction.
So the real question that matters is: “How do we design the teams?” not “How do we design the system?”
How Your Org Design Shapes Culture and Impact
Conway’s Law doesn’t just shape your system. In many ways, it shapes the limits of your culture and the impact of your organization.
Your org structure defines the communication boundaries, the decision-making process, who talks to whom, etc., and these in turn shape the cultural norms. Also, the boundaries can either help teams move quickly, or slow them down, and ultimately shape the impact your org is making towards the business goals.
Let’s look at a few cases where it shows up in unexpected ways.
Layered Structures
The most obvious way is what we’ve already seen - layered structures.
If your teams are split by layers, your system will be split by layers. A simple feature will need multiple teams, multiple handoffs, and multiple cycles of coordination. What should be fast becomes slow.
Workload Imbalance
Another, less obvious impact is workload imbalance.
Imagine two teams, each owning a different capability. On paper, it looks clean. Clear ownership, clear boundaries. But in reality, the work is not “equal”. One team has more demand, tighter timelines, and more dependencies. The other has less work and more breathing room. Over time, one team feels constant pressure, while the other cruises.
In this case, nothing is wrong with the people or the teams themselves. It is the structure that created the imbalance.
Roadmap “Long-poles”
I’ve also seen this in how priorities play out. If a critical initiative depends heavily on one team, that team becomes the bottleneck. Every roadmap discussion starts to revolve around their capacity.
Other teams may be ready to move, but they are forced to wait. So your roadmap is no longer driven by business priorities, but by team structure.
Platform Services
And then there’s the classic platform services problem.
A central team owns ‘shared services’, and every other team depends on them. Initially, this feels efficient, but as the organization grows, that team becomes the ‘gate’. Over time, they see requests piling up, and other teams waiting in queues. Again, the platform team isn’t ‘slow’, but the structure made them the bottleneck.
Matrix vs Functional Structures
Most companies are organized around either matrix or functional structures.
In matrix structures, people report to one team, but work for another, and coordinate priorities and execution horizontally. In functional structures, the entire org or team owns the end-to-end capabilities, and the boundaries are more rigid.
Each structure has its own tradeoffs, but most companies just let their organizations evolve without having any intention or reason for why they’re organized the way they are.
This creates confusion and a lack of direction. Again, this is not a people problem, but a structure problem.
Now, if you step back, you’ll notice a pattern:
Team boundaries influence system boundaries.
Ownership boundaries influence accountability.
Structure defines how fast, how clearly, and how effectively work gets done.
So, how should you design your organization? Let’s look at that next.
Putting Conway’s Law Into Practice
For the rest of this article, we will focus our attention on putting Conway’s Law into practice in your own organization.
As we do that, don’t forget to download the following resources:
Conway’s Law Worksheet: Use this to diagnose your current organizational structure, what your business or team priorities are, and where the gaps lie. The worksheet includes step-by-step prompts to guide you through the entire application process.
Conway’s Law Mind-map: Use this as a quick visual refresher about the framework. You can also use it as a visual guide to help you when you need to practice the framework in your own situations.
These resources are part of The Good Boss Practitioner resource library, available to all paid subscribers to The Good Boss.
⬇️ Already a member? Download these from your Resource Library.
💬 Have questions about applying this? Drop a comment in the Practitioner Community and let’s discuss how to tailor this to your specific situation.
👉🏼 Not a paid member? Upgrade now and get instant access to these resources, plus the complete practitioner resource library with 100+ worksheets, mind-maps, posters, and framework deep-dives to handle dozens of situations you face at work every day.