Topology: who sits with whom, who owns what

Conway's law is one of those observations that sounds like trivia until you realize it is describing your roadmap. Systems mirror the communication structure of the organizations that build them. A team of three squads ships software with three seams in it, whether or not anyone drew those seams on purpose. The practical consequence is uncomfortable: your org chart is already producing an architecture right now. The only open question is whether you chose that architecture or inherited it by accident.

Most people meet Conway's law through its inverse, the move where you shape the teams first to get the architecture you want. That is real, and it is a genuine lever. But the inverse maneuver makes it sound like a tool you reach for occasionally. The constraint is always on. Whether you are designing a team, splitting one, or leaving one exactly as it is, you are choosing an architecture. Topology is the name for that choice: who sits with whom, and who owns what.

Watching the same seam move three times in one company taught me that this choice is never settled.

Early on, when the org was small, we did the obvious thing. We split the tech group in two: Product on one side, Engineering on the other. Inside Engineering we split again by platform, into Backend, Android, iOS, Web, QA, and DevOps. The logic was divide and conquer, and at that size it worked. Product thought about the product, and Engineering built it. Everyone knew which room their problem lived in.

Then we scaled, and the first seam hardened. The line between Product and Engineering stopped being a convenience and became a border with two sides. Tech debt quietly became an Engineering problem, something Product did not have to look at. New features quietly became a Product problem, something Engineering received rather than shaped. The work that needed both sides at once, the work that did not respect the border, kept falling into the gap between them. Nobody decided that gap should exist; the structure decided it.

We were not done manufacturing borders. As the platform teams grew, a second seam opened inside Engineering, this time between the platforms themselves. Backend and the frontend platforms started to feel like different tribes. And because any real feature touched several platforms at once, every feature now needed a coalition to ship. A thing that belonged to four teams belonged, in practice, to none of them. Ownership dissolved exactly where the most important work lived.

So we reorganized. We stopped slicing by platform and started slicing by outcome. We built cross-functional pods, each one pointed at a theme the business actually cared about, things like average revenue per user or discoverability. Each pod held the people it needed to move its outcome end to end, and each pod owned that outcome rather than owning a layer of the stack.

It worked, and it was the right call. But the we-versus-them did not disappear; it moved. The friction that used to live between Product and Engineering, and then between platforms, now lived between themes. The pod that owned one outcome and the pod that owned another still had a border, still had work that fell in the gap between them, still occasionally treated the other side as someone else's problem. We had not removed the seam. We had relocated it to a place we could afford, because owning outcomes was what the business needed next.

That is the pattern, and it is the whole argument: you do not eliminate the seam by reorganizing, you move it. Every way you slice a team draws a line, and every line is also a wall. The coordination friction is conserved. Reorganizing does not delete it, it relocates it, and the leadership act is choosing where it lands.

This is why topology is two decisions rather than one, and why the second one matters more. Who sits with whom is the org chart, and the org chart is the cheap half. Anyone can redraw boxes. Who owns what is the real artifact, and it is harder, because ownership is not a label on a diagram. Ownership means the team that builds a thing also runs it, answers for its failures, and lives with its cost. A name on a chart can sit on top of a service it has no authority to change and no expertise to fix. That is not ownership. That is an assignment, and assignments are what fall into gaps.

If the seam is unavoidable and ownership is the thing that actually breaks, then the skill is deciding where the line goes. There is a shared vocabulary worth knowing here. Team Topologies, the framework by Matthew Skelton and Manuel Pais, gives most teams their words for it. It sorts teams into four kinds:

• Stream-aligned teams own a single flow of work end to end, and most teams should be this kind.
• Platform teams take load off everyone else by paving the common paths.
• Enabling teams coach other teams through a gap in skill, then step away.
• Complicated-subsystem teams hold a part so specialized that only a few people can work on it.

It also names three ways those teams interact:

• Collaboration: two teams work closely together for a defined stretch to figure something out, accepting the overhead while they do.
• X-as-a-service: one team consumes what another provides like a product, with little back-and-forth.
• Facilitating: one team helps another get unstuck or learn a new skill.

It is useful shared language, and that is all it is. These labels do not tell you where your line goes. The framework's own answer is to cut along a system's natural fracture planes, the boundaries it already has, like the edge of a business domain or a sharp difference in how fast two parts change. That tells you where the lines tend to fall, but whether a given line is the right one is what these three tests decide.

The cognitive-load test

Can one team hold everything it owns in its head? Not on a good day, but routinely, across the domain it works in, the technology it runs, and the operational reality of keeping it alive. A team that owns the app, the API behind it, and the data pipeline feeding it can look perfectly coherent on a chart and still be drowning, because no human on it can reason about the whole surface at once. When a team is cognitively underwater, the line is in the wrong place however clean it looks. Team size is the other side of the same limit. Team Topologies keeps teams small, roughly five to nine people, and long-lived, because the trust and shared context a team runs on have a ceiling, the limit Robin Dunbar studied on how many close working relationships a person can hold. Grow past it and a team spends its day coordinating with itself instead of building. This is also the honest justification for platform teams: they exist to take load off the teams shipping to users. Tidiness on the chart is not the point.

The ownership-clarity test

Pick any outcome that matters, or any failure you would lose sleep over. Ask whose name comes up. If exactly one team's name comes up and nobody argues, the boundary is doing its job. If you get a shrug, or worse, an argument, you have found a gap, and the gap will swallow work the moment things get busy. A useful artifact here is brutally simple: every outcome metric you care about should map to exactly one accountable team. If two teams share it, neither owns it.

The seam test

This is the one I had to learn the hard way. Before you draw a line, ask what becomes someone-else's-problem the instant it exists. Every boundary makes something fall off the far side. Name that something out loud. Then ask whether you can afford to have it fall there, and whether the friction you are about to create serves what the business needs right now or fights it. The cognitive-load test tells you if a team can carry its side. The ownership-clarity test tells you if the sides are clean. The seam test tells you whether the wall is in a place you chose or a place you will regret.

None of this means you should hold structure still and admire it. Orgs are not static. Priorities shift, the company grows or contracts, and a topology that fit last year can quietly stop fitting. There is a contrarian line that treats every reorg as theater, motion performed to look like leadership, and it is half right: a reorg with no signal behind it is exactly that. But the conclusion that you should therefore avoid reorganizing is wrong. The job is to read the signals and act when they are real.

A reorg is due when the evidence shows up; a turning calendar is not evidence. The signals that count:

• The seam has hardened into an ownership gap, the way ours did.
• The strategy has changed and the structure still serves the old one.
• Growth has pushed a team past the load it can carry.
• Every meaningful change now needs three teams in a room, which is Conway telling you the architecture and the org no longer match.
• Work is chronically blocked across a boundary because the boundary sits across the flow of work instead of along it.
• Ownership has concentrated into a single person whose departure would take the system with them.
• There is no surface left for good people to own and grow into.

Against all of that sits a real cost, and you have to clear it before you move. Reorgs are not free. They disrupt knowledge, reset everyone's context for a while, and churn ownership in a way that measurably raises tech debt, because the people who understood the code end up outside the team that now owns it. So the signal has to be worth that bill. Reorganizing to perform motion, or to dodge a hard conversation with one person by rearranging forty, costs all of that and buys nothing.

Which leaves the actual move, the one I wish I had understood the first time. Match the slice to what the business needs now. Then say the trade-off out loud: this structure serves this priority, and the price is this seam, in this place. You are not looking for the structure with no seam, because it does not exist. You are choosing which seam you can afford to live with, putting it where it costs the least and serves the most, and giving yourself permission to move it again when the priority moves.