A talk on how reporting lines, on-call rotations, and team boundaries become the dominant constraint on what software you can actually ship.
This is an expanded version of a talk I gave internally in late 2025. The core argument: the decisions you make about how to organize people are also decisions about the latency of your engineering system. Most organizations do not treat them that way.
Conway's Law is not a metaphor
Melvin Conway observed in 1967 that organizations that design systems are constrained to produce designs that are copies of the communication structures of those organizations. This is called Conway's Law, and most engineers have heard of it.
What fewer people act on is that the inverse is also true. If you want your system to have a particular architecture, you need your organization to have the communication structure that makes that architecture natural. You cannot organize teams one way and expect software to flow a different way.
I have seen this mistake made many times. The most common form is trying to build a microservices architecture with teams that are organized as monolith teams. The services end up tightly coupled because the people who own them are tightly coupled. The coupling is in the org chart before it is in the code.
Latency in a human system
When I use the word latency in a software context, I mean the time between a request and a response. In a human system, the equivalent is the time between a need and a decision.
If a team needs a decision made by another team, the latency of that interaction determines how fast they can move. If the two teams share a manager, the latency is low — the manager can make the call in a hallway conversation. If the two teams report to different VPs who have to align before anything moves, the latency is measured in weeks.
This is not a cultural problem or a process problem. It is a structural problem. The org chart is the architecture of your decision-making system, and like software architecture, it has throughput and latency characteristics that are mostly determined by design.
How this shows up in practice
I managed a platform team that was a shared dependency for six product teams. Every time a product team needed a platform capability that did not exist, they submitted a request. The request went into a backlog. The platform team triaged it in a weekly meeting. If it was prioritized, it got scheduled for a future sprint.
The median latency from request to delivered capability was eleven weeks. That was not a process failure. The process was working as designed. The problem was the design: a centralized platform team creates an architectural bottleneck with deterministic latency.
The solution was not a better ticketing system. The solution was an embedded model where each product team had a platform engineer who could build capabilities in that team's context, with a looser coordination structure for sharing work across teams. That change reduced the median latency to under two weeks.
The org chart changed. The system architecture followed.
On-call rotations as architecture
On-call rotations reveal your actual ownership model. A team that is on-call for a service owns that service in a meaningful way. A team that is on-call for a service that depends on five other teams' services has a problem that the org chart has not solved.
I use on-call rotation design as a diagnostic. If you cannot assign on-call responsibility for a component without listing five caveats about what that team cannot actually fix, you have a coupling problem in your system that the on-call structure is exposing.
The fix is almost never to improve the escalation runbook. The fix is to reduce the coupling — either by moving the dependency into the team that owns the component, or by creating a clean interface that decouples the on-call responsibility from the upstream dependency.
Team boundaries are API contracts
When two teams have a boundary between them, that boundary is an API. It has a specification (what you can ask for), a contract (what you can rely on), and a latency characteristic (how fast you get a response).
Most team boundaries are not designed this way. They are accidents of organizational history — this team was formed when this product was built, that team was split when it got too large, this group reports here because of a reorg two years ago.
When you design team boundaries deliberately, you ask the same questions you would ask about a service interface. What does this team own? What can other teams ask of it? What are the response time expectations? What is the escalation path when the normal path fails?
Those are not HR questions. They are architecture questions.
The practical implication
If you are building a new system and you have any influence over how the team is organized, spend time on the org design before you spend time on the technical design. The org design will constrain the technical design more than the other way around.
If you are inheriting an existing system with an existing team structure, identify the latency bottlenecks in the human system before you look for the latency bottlenecks in the software. They are usually in the same places.
The org chart is a diagram. It just happens to be a diagram of your communication architecture and your decision latency. Read it that way, and you will see constraints that are invisible when you read it as a reporting structure.
