Laws & Disorder #1 — Conway's Law: Your Org Chart Is Your Real Architecture (and AI Is Redrawing Both)

🎬 Also available as a blog walkthrough video — a short narrated screencast of this post.

This is the first post in “Laws & Disorder,” a short series where I take a software-engineering “law” we all half-quote, admit it’s a heuristic and not a law of physics, and ask what it means for building on the cloud in the age of AI. First up: the one that keeps quietly winning arguments in architecture reviews.

A long time ago I stopped believing my architecture diagrams. Not because they were wrong on paper, but because the real diagram was hanging in HR. Every time I tried to change the overall shape of a system that spanned many services and many teams, the thing I actually ran into was not the code. It was the org chart. The boxes and reporting lines that decided who talked to whom turned out to be the load-bearing walls, and the software had quietly been poured into the mold they made.

That is Conway’s Law, and once you have felt it you cannot unsee it.

The law in one sentence

Melvin Conway put it plainly in 1967: organizations that design systems are constrained to produce designs that copy the communication structures of those organizations [1]. He wrote it up in a paper called “How Do Committees Invent?”, Harvard Business Review turned it down, and it ran in Datamation in 1968 instead. Fred Brooks later gave it the name it carries today.

The everyday version: if you have a frontend team, a backend team, and a database team, you will almost certainly ship a three-tier application with a frontend, a backend, and a database, and the painful integration seams will land exactly where the teams stop talking to each other. The architecture is a cast of the communication paths that made it.

On AWS, the boundaries you don’t design still get drawn

This is not an abstract 1968 curiosity. It shows up in the most concrete places on AWS: where you draw service boundaries, and where you draw account boundaries.

When a single team owns a service end to end, the API around that service tends to be clean, because there is one group of people responsible for the contract and they feel every rough edge. When two teams share a service and coordinate through tickets, the seam between their parts of it tends to calcify into an internal interface nobody wants to touch. Multi-account strategy has the same gravity. AWS guidance on organizing with multiple accounts leans on aligning account boundaries with ownership and workload boundaries [5], and in practice those ownership boundaries are team boundaries. Draw them to match how your teams actually work and the accounts stay coherent. Draw them against the grain of your teams and you will spend the next year fighting cross-account friction that is really cross-team friction wearing an IAM costume.

None of this makes a monolith wrong, and I want to be careful here. A monolith owned by one small team that talks constantly is Conway-correct. It matches its communication structure. The failure mode is not “monolith” or “microservices,” it is a mismatch between the shape of your teams and the shape you keep trying to force onto the software.

The move most people miss: reshape the org first

If architecture follows communication structure, then the highest-impact architectural decision is often not a technical one. It is a team decision. This is the Inverse Conway Maneuver: instead of drawing the target architecture and hoping the org cooperates, you reshape the org into the shape you want the software to take, and let Conway’s Law work for you instead of against you [2]. Skelton and Pais built an entire practice, Team Topologies, around designing team boundaries to get the architecture you want [3].

The cleanest example is one I keep coming back to. Amazon’s move toward small teams that own a service end to end, the “two-pizza” idea, is not first a technology story. It is an organizational one, and the service-oriented architecture followed from it rather than the other way around [4]. Small teams with a clear ownership boundary produced services with clear API boundaries, because the communication structure and the software structure were finally the same shape. I wrote more about the ownership half of that story in The Other Half of Two-Pizza, and about how the operating model around these teams is changing in the post-agile operating model.

The practical takeaway for an architecture review is a single reframing question: is this coupling problem a code problem, or an org problem? If two components cannot be cleanly separated in the software, look at whether the two teams behind them can be cleanly separated in the org. Very often the tangle in the codebase is a faithful mirror of a tangle in the reporting lines, and no amount of refactoring fixes it until someone changes who talks to whom.

The AI twist: does the mapping loosen, or just replicate faster?

Here is the part I find genuinely open, and I want to flag clearly that this section is my reading of where things are heading as of 2026, not settled fact.

Conway’s Law runs on a cost. Coordinating across a team boundary is expensive: meetings, handoffs, shared context that has to be rebuilt every time. Architecture drifts to match communication structure precisely because communication across boundaries is costly, so teams minimize it and the software hardens along those lines. AI coding assistants change that cost. When a small team plus AI can produce what used to need several teams talking to each other, the coordination cost that Conway’s Law is built on drops. If that cost is what pins architecture to the org chart, a lower cost should loosen the pin.

There is a second shift. “The org” is starting to include more than humans. Fleets of AI agents are becoming part of how work gets done, which means the communication structure Conway described now has non-human nodes in it. If architecture mirrors communication structure, and part of that structure is now agents talking to agents, then the system may start to mirror how you organize your agents and your human-plus-agent teams, not just how you organize people.

I can argue this two ways, and honestly I hold both. The optimistic read is that AI finally lets architecture escape the org chart, because the coordination cost that trapped it is collapsing. The skeptical read is that AI just entrenches the existing structure faster: everyone generates more code inside the silos they already have, and the seams calcify at machine speed. I do not think we know yet. What I am fairly sure of is that the question is worth asking on purpose, rather than discovering the answer a year later in an architecture review.

If you’re running this on AWS

A few concrete places to apply the lens:

• Service ownership. Aim for one team per service with a clear contract at the edge, expressed through API Gateway or events over EventBridge. The contract is easiest to keep clean when a single team feels every consumer.
• Account structure. When you set up AWS Organizations and a multi-account layout, align account and organizational-unit boundaries with team ownership boundaries, not with an org-neutral ideal [5]. The accounts stay coherent when they match how people actually work.
• Well-Architected reviews. When you find tightly coupled components, add “team structure” to the list of root causes you check. It is frequently the real one, and the Inverse Conway Maneuver is a legitimate recommendation, not just an architecture one.
• Agent topology. As you add AI agents to a workflow, decide deliberately which team owns each agent and what it is allowed to talk to. You are drawing communication paths, and Conway’s Law does not care whether the nodes are people or agents.

Your architecture diagram is a hypothesis. Your org chart is the evidence. When the two disagree, the org chart usually wins. So before you redraw the boxes in the system, look hard at the boxes in the org, and ask which one you actually need to change first.

Where does your real architecture live right now: in your repo, or in your reporting lines?

More in this series

“Laws & Disorder” continues with Hyrum’s Law (every observable behavior of an API is a contract someone depends on) and Tesler’s Law (you can’t delete complexity, only choose who owns it). This post was sparked by the excellent Laws of Software Engineering collection [6], which is well worth a browse.

Sources

• [1] Melvin Conway — How Do Committees Invent? — the original 1968 paper (published in Datamation after HBR passed on it) that states the law.
• [2] Martin Fowler — Conway’s Law — clear explainer plus the Inverse Conway Maneuver.
• [3] Team Topologies — Skelton and Pais on designing team boundaries to get the architecture you want.
• [4] Werner Vogels — A return to two-pizza culture — small teams owning a problem end to end, the organizational root of service-oriented design.
• [5] AWS — Organizing your AWS environment using multiple accounts — aligning account boundaries with ownership and workload boundaries.
• [6] Laws of Software Engineering — Conway’s Law — the collection that sparked this series.

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• LawsAndDisorder
• Architecture
• Teams
• AWSArchitecture
• AIAgents