Microservices and teams: why a service boundary is a responsibility boundary
Moving to microservices changes not just the architecture, but how teams negotiate contracts with each other.
When companies start the conversation about moving to microservices, the main argument is usually framed technically: independent deployment, scaling individual components, resilience to failures. All of that is true. But what I see most often is that the technical problems during migration turn out to be the smaller part of the difficulty. The larger part is organisational.
A microservice is not just a piece of code separated into its own process. It is a unit of ownership. And if ownership is not assigned, the architecture performs badly regardless of how many services there are.
Where the real complexity comes from
A monolith is, oddly enough, simpler from a coordination perspective. All developers work with one codebase. A change in one place is visible to everyone. Conflicts surface immediately.
In a microservices architecture each team owns its service - which means interaction between teams is now formalised through APIs. That is good when contracts are stable and well-documented. It is a disaster when every team changes its API without telling the others.
I have seen companies where the move to microservices increased the speed of individual teams but broke integration: systems diverged in their contracts and nobody was responsible for architecture at the organisational level.
API contract as an organisational tool
An API contract is not just technical documentation. It is an agreement between teams about what one side commits to providing and the other expects to receive. Changing a contract is changing an agreement, and that requires coordination.
In mature teams the contract is versioned. The old version is maintained in parallel with the new one for a period, so consumers have time to migrate. That is an organisational process, not a technical one.
Without this process, microservice architecture creates an illusion of independence: each team is "free", but in practice everyone keeps breaking each other.
Conway's Law has not gone away
There is an old observation - Conway's Law: the structure of software reflects the communication structure of the organisation that builds it. In the 1960s this was an observation. Today it is a practical design tool.
If you want a certain architecture, check whether the team structure matches it. If a team is responsible for several unrelated services, those services will become coupled. If two services are supposed to be independent but are maintained by one team sharing a backlog, the independence will be superficial.
This does not mean every microservice needs its own dedicated team. It means that architectural decisions should correspond to how real work is actually organised.
Practical questions for a manager
If your company is moving toward microservices or is already in transition, a few questions help assess real readiness:
- Does every service have a clear owner - a team or person who makes decisions about the API?
- How does coordination of API changes between teams currently work - is there a process, or informal conversations?
- Is contract documentation in an up-to-date state, or does it go stale as soon as it is written?
- Who in the organisation sees the full architecture and can tell whether contracts are drifting apart?
Microservices are a mature approach that works well with a mature engineering culture. Without that maturity, they multiply complexity without a proportional increase in speed.