The Org Chart Is the First Architecture Diagram
The design review is on Thursday. The reporting lines were set in March, and they already decided which interfaces will be clean and which will be a negotiation. Reading the org chart that way changes what you reorganize, and when.
Every architecture review I have sat in treats the diagram on the screen as the decision being made. It usually is not. Most of the boundaries in that diagram were fixed months earlier, by somebody deciding which teams would exist and who would report to whom. The review is where we find out what the org chart already chose.
Melvin Conway put this in writing in 1968: an organization that designs a system produces a design whose structure mirrors the organization's own communication structure. It gets quoted as a warning, usually after something has gone wrong. I have come to read it as a schedule instead. The org chart is not a risk to the architecture. It is the first draft of the architecture, and it ships before anyone opens the design doc.
What the org chart actually decides
A team boundary is an interface with a manager attached. Inside a team, changing a contract is a conversation at a desk. Across a team boundary, the same change is a ticket, a priority call between two managers, and a place in somebody else's quarter. The code does not know the difference. The calendar does.
So the practical effect of the org chart is a cost function laid over your system. Every seam that falls inside a team is cheap to move. Every seam that falls between teams is expensive, and expensive seams calcify. Within a year, the expensive ones are your real architecture, whatever the diagram says, because those are the ones nobody could afford to revisit.
This is why the same design produces different systems in different orgs. Put one team on it and you get a well factored monolith, because internal boundaries stayed cheap. Put four teams on it and you get four services, because that is where the cheap boundaries were. Neither outcome was argued for. Both were inherited.
Why the diagram loses
Nobody overrules the architecture in a meeting. What happens is smaller and harder to see. A team needs a field that lives on the other side of a boundary, and asking for it costs six weeks, so they cache a copy. Another team needs behavior that belongs in a shared service owned by a group with a full quarter, so they add a special case on their side. Each of those is a sensible local decision made by a competent person under real constraints.
When the architecture diagram and the org chart disagree, the org chart wins. It just takes two quarters to show up in the code.
Add a year of those decisions and the system has quietly reshaped itself around the reporting lines. The duplicated data, the special cases, the service that is technically shared but practically owned by whoever shouts loudest: none of it is in anyone's design doc. It is the org chart, rendered in code, at the resolution the incentives allowed.
Reading the org chart as a diagram
The useful version of this idea is not the warning. It is that the org chart is readable before the damage, and reading it is a twenty minute exercise. Three things to look for.
1. Where do the expensive seams fall?
Draw your intended architecture, then draw the team boundaries over it. Every place a system boundary and a team boundary line up, you have a seam that can hold. Every place a system boundary falls inside one team, expect it to erode, because nothing charges anyone for crossing it. Every place a team boundary cuts through what should be one component, expect duplication, because the alternative is a standing negotiation.
2. Which interface has no owner?
Interfaces between two teams tend to belong to neither. Both sides treat the contract as the other side's artifact, so it drifts, accumulates undocumented behavior, and eventually nobody can say what it promises. Any interface where you cannot name one person accountable for the contract is already degrading. You just have not been billed yet.
3. Who is everyone's dependency?
Find the team that appears in every other team's plan. That team is the bottleneck your org chart designed, and no amount of prioritization inside it will fix a structural problem. Either its scope is too broad for its staffing, or work that should live with the teams that need it has been centralized for tidiness. This is the failure mode I wrote about in The Platform Team Trap, seen from the org side rather than the product side.
A reorg is a refactor with people in it
Once you accept that the org chart is a design artifact, the reorg stops being an HR event and becomes an engineering change with unusual properties. It moves boundaries. It changes which contracts are cheap. It has a blast radius, a migration period, and a set of things that break during the cutover. What it does not have is a rollback, because the people remember.
That argues for treating it with more design rigor than we usually do, not less. Before the boxes move, I want the same things I would want in a design review. What boundary is this trying to make cheaper? What is the seam we are accepting in exchange, because there is always one. Which interfaces become cross team on Monday that were internal on Friday, and who owns each of those contracts by name. What we expect to see in six months if this worked, stated now so it can be wrong.
The reorg that skips those questions is not neutral. It is a large architectural change, shipped without review, to a system that cannot be reverted.
Designing both at once
The strongest version of this is to stop sequencing the two. Most orgs decide the structure, announce it, and then ask engineering to produce an architecture inside it. The better move, when you have the standing to make it, is to bring the two decisions into the same room and let them constrain each other.
In practice that means the architecture proposal carries a staffing shape, and the staffing proposal carries the seams it creates. If the design needs one component to stay coherent, that is an argument for one team owning it, and the argument belongs in the org conversation rather than the design doc where nobody with headcount will read it. If the org is set for reasons that outrank the architecture, which happens and is sometimes correct, then the design should be chosen to survive that org rather than to fight it.
This is also the part that transfers. The domains I have built platforms in look nothing alike: content at Yahoo, data and seller experience at Amazon, mobile payments at PayPal, connected devices and enterprise applications at Bosch, an e-pharmacy in its early years at Netmeds, wealth management at AG|Delta. The vocabulary changed every time. The relationship between who reports to whom and which interfaces survive did not change once. That consistency is the reason I trust the pattern more than I trust any particular diagram, and it is the same argument I made in Platform After Platform.
What this asks of you
If you are a senior engineer, it means your design doc is incomplete without a sentence about who owns each boundary. A design that ignores the org is a design that will be renegotiated without you in the room.
If you run an org, it means you are doing architecture whether or not you think of it that way. The question is only whether you are doing it deliberately, with the tradeoffs written down, or accidentally, and finding out from an incident review two quarters later.
Conway's observation is nearly sixty years old and still lands as a surprise in most review rooms, which tells you something about how rarely the two conversations happen together. You do not have to treat it as a law you are subject to. You can treat it as a lever: decide the communication structure you want on purpose, and the architecture you wanted becomes the cheap one to build.
Haseeb Afsar