Service Boundaries Should Follow Team Boundaries

What I learned splitting and un-splitting a service nobody fully owned, and the six questions I now bring to architecture reviews.

A few years back, I sat in a war room at 2 a.m. while three engineers from three different teams argued about whose service had broken. The customer-facing failure was clear. The path through the system was not. Somebody on the call kept saying, "I can see the message land in our queue, I cannot tell you what came in before that." Somebody else said, "We own the schema, we don't own the producer." A third voice, quieter, said the producer team had been reorganized two months earlier and nobody on that team had written that part of the code. By the time we found the broken hop, the customer had already escalated through the support line into the executive sponsor's email.

I had pushed for that split a year earlier.

That was the night I started taking team boundaries more seriously than service boundaries.

The conventional wisdom of microservices says you decompose the system by function. Bounded contexts. Domain-driven design. Each service should do one thing well. All true, in a vacuum. The trouble is that "one thing well" assumes someone is around to do that one thing. In an org chart that shifts every eighteen months, the diagram outlives the people who drew it. The service stays. The team that understood it disperses.

Across several organizations, I have watched the same pattern play out. A senior engineer or architect maps the domain. The map looks clean. They cut the system along the joints. Then they hand a service to whichever team has the spare capacity that quarter. The team accepts it because they have to, builds shallow familiarity, and ten months later that team is reorganized into something else. The service still runs. Nobody really owns it. When something breaks, the on-call rotation rotates strangers through unfamiliar code, and the recovery time gets measured in hours instead of minutes.

The thing the architecture diagram cannot show is who answers the page.

There is a position I have been more willing to defend over the years. Ownership matters more than output. The team that decides what changes and carries the consequences when it breaks is more valuable than the team that produced the original artifact. A service is an artifact. A team's understanding of that service is the actual asset. The moment those two diverge, the service drifts toward the place where every legacy system goes. The place where everyone agrees something needs to be done about it and nobody does it.

So when the next architecture review comes around, I no longer ask "what is the natural seam in the domain?" first. I ask "who is going to live with this in three years?" first. And then I draw seams that match the answer.

The split I mentioned earlier had been clean on paper. We had a payments orchestrator that had grown to about forty thousand lines, and the senior engineers wanted to break out the merchant-side contract handling from the consumer-side payment flow. The bounded contexts were obvious. Two services, two clearer codebases, two faster build times. I signed off, and we shipped the split over a quarter.

What I had not stress-tested was the ownership question. The merchant-side service ended up with a team whose actual roadmap was checkout. Checkout was their performance metric, the thing they were judged on. The merchant contract code was a tax on their roadmap. So they did the rational thing. They kept it running, fixed bugs as they came in, and did not invest. Over twelve months it accumulated about a year of soft entropy: stale dependencies, undocumented config flags, a test suite with about a third of the coverage of the consumer-side service.

When the contract format changed for a regulatory deadline, nobody on that team had the depth to make the call quickly. We pulled in two engineers from the original orchestrator team to consult. Then we pulled in a third. By the end of the project we had effectively rebuilt the team that had owned the original orchestrator, with the overhead of two services to deploy instead of one.

A year after the split, we merged it back. Not because microservices are bad. Because the team boundary we had drawn around it did not exist.

This is the shape of the mistake I see most often in mid-stage architecture decisions. The team is treated as a placeholder you can fit around the system later, like wrapping a gift. But teams are not interchangeable. A team is a particular set of people with a particular set of skills, a particular history with a particular codebase, and a particular thing their manager is being measured on. You cannot ask them to own something that does not fit that shape and expect ownership to actually develop. They will run it. They will not think about it.

Conway's Law gets cited a lot in these conversations, usually as a kind of fatalism. Whatever you ship will look like your org chart, so good luck. I have come to read it the other way around. The org chart is the part of the system you can actually change. If you want a different architecture, change the team structure first. Decide who you want to own what, give that team the time and the mandate, and the right service boundaries will start to suggest themselves. The diagram will follow. It almost always does.

What I would tell my past self at the whiteboard that quarter: stop drawing the services first. Draw the teams first. Then ask which services those teams should plausibly run for the next three years given their current size, their current skills, and the part of the roadmap they are accountable for. Where the answer is "no team would naturally own this," do not split it. Either give the parent team the mandate to keep growing, or invest in building a team that will eventually own the spinoff before you make the cut.

Here is the short version I now bring to architecture reviews. Six questions. Less about diagrams, more about who gets paged when it breaks.

1. Who is on the on-call rotation for this service in eighteen months? Not which team in the abstract, which named role. If you cannot say, the boundary is wrong. 2. What is that team's primary roadmap commitment? If the service is a tax on that commitment, you are about to underinvest in it. 3. How many engineers on that team have read the code end-to-end? If the answer is fewer than two, the team does not own it yet, regardless of what the org chart says. 4. When the regulatory or business context shifts, who has the standing to make the call without escalating? Ownership without decision rights is babysitting. 5. If this team disbands in two years, what is the migration path? "We will figure it out" means the service is going to enter the orphan list. 6. Does the proposed split create at least one service nobody in the room can name a clear owner for? Then it does not exist as a service yet. It exists as a future incident.

None of this means microservices are wrong, or that bounded contexts do not matter, or that you should never split a system. It means the cut should be made along a line where a team is ready to live on the other side of it. If that team does not exist, build it before you cut, or do not cut.

The cleanest architecture I ever inherited was one where the previous director had spent a year reshaping the org before touching the code. By the time the engineers started moving services around, the people were already in the right rooms. The work felt obvious because it was. The seams were already in the people.

The diagram does not decide. The on-call rotation does.