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, so a team of three squads ships software with three seams in it, whether or not anyone drew those seams on purpose. Sit with that for a second and it turns uncomfortable: your org chart is producing an architecture right now, and 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 it makes the law sound like a tool you take out occasionally, when the constraint is on all the time. Whether you are splitting a team 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.

I watched the same seam move three times in one company before accepting that this choice never settles.

Early on, when the org was small, we did the obvious thing and 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, Engineering built it, and 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, and new features quietly became a Product problem, something Engineering received rather than shaped. The work that needed both sides at once kept falling into the gap between them, and the gap was stable for an unglamorous reason: anything you could file as the other side's problem was work off your own plate, so neither side had any incentive to reach across.

We were not done manufacturing borders. As the platform teams grew, a second seam opened inside Engineering, this time between the platforms themselves, and Backend and the frontend platforms started to feel like different tribes. Because any real feature touched several platforms at once, every feature now needed a coalition to ship, and a thing that belonged to four teams belonged, in practice, to none of them, which parked the ownership gap squarely under the most important work we had.

So we reorganized. We stopped slicing by platform and started slicing by outcome: cross-functional pods, each one pointed at a theme the business 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 so much as move. The friction that used to live between Product and Engineering, and then between the platforms, now lived between themes. The pod that owned one outcome and the pod that owned another still had a border, still had work falling into the gap between them, and still occasionally treated the other side as someone else's problem. We had moved the seam to a place we could afford, because owning outcomes was the next thing the business needed from us.

Reorganizing, it turns out, moves coordination friction around rather than deleting it, and where the friction lands is the part you get to choose. Every way you slice a team draws a line, and every line is also a wall.

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 harder, because ownership is not a label on a diagram: it means the team that builds a thing also runs it and answers for its failures. A name on a chart can sit on top of a service it has no authority to change and no expertise to fix, and that arrangement is an assignment rather than ownership, which matters because an assignment is the first thing to fall into a gap.

If the seam is unavoidable and ownership is the part that breaks at it, you are left deciding where the line goes, and there is a shared vocabulary worth having for that. 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. The 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 lines tend to fall. Whether a given line is the right one comes down to the three tests below.

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, 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, which is also the honest justification for platform teams: they exist to take load off the teams shipping to users, whatever they happen to do for the tidiness of the chart.

The ownership-clarity test

Pick any outcome that matters, or any failure you would lose sleep over, and 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, because a team under pressure triages toward the things it unambiguously owns. One simple artifact helps here: map every outcome metric you care about to exactly one accountable team, since a metric two teams share is a metric neither of them will answer for.

The seam test

This is the test I had to learn the hard way. Before you draw a line, ask what becomes someone-else's-problem the instant the line exists, because 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 first two tests check whether a team can carry its side and whether the sides are clean. This one checks whether the wall stands in a place you chose.

None of this means you should hold a structure still and admire it. Orgs shift under you: priorities change, the company grows or contracts, and a topology that fit last year can quietly stop fitting. A reorg with no signal behind it really is theater, motion performed to look like leadership, and plenty of reorgs are exactly that, but it does not follow that you should never reorganize. A reorg is due when the evidence shows up, and a turning calendar does not count as evidence. The signals that do:

• 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 bill, and you have to clear it before you move. A reorg disrupts knowledge, resets everyone's context for a while, and churns 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 the 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 move 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. Nobody is offering a structure with no seam, so you end up choosing which one you can afford to live with and where it costs the least. Ours has moved three times so far, and I do not expect the current position to be the last one.