Hi Martin,

Thanks for taking the time to read and respond to the article. I definitely appreciate it.

Short answer to your question is “no”. Even if we say team autonomy isn’t the reason for building microservices, a core services team will almost certainly lead to teams that are tightly-coupled both at design time and at runtime.

With that said, team autonomy is about things like decoupling, independent deployments, etc. But it encompasses the team members themselves as well as the service(s) they own. In other words, autonomous teams have neither design-time dependencies on other teams, nor runtime dependencies on other services.

There are indeed many other reasons to utilize microservices, and you make a good point that they might differ between a smaller, one-team company (for which, to be fair, a core services team is probably irrelevant) and a larger one migrating from a monolith (where my experience lies). So maybe reframing the idea is in order, to something like:
• When moving from a monolith to a microservices, one of the biggest benefits your org can potentially see is the decoupling of your teams, and the large productivity gains that follow
• If not done thoughtfully, however, your move to microservices might exacerbate teams’ dependence on each other

I do want to address the notion that “microservices don’t actually allow teams to be autonomous because invariably a new feature will require changes in multiple parts of the system owned by different teams, and these teams need to work together to release the feature”… it’s actually not invariable. And that’s what I’m getting at here. If an organization is thoughtful about how it organizes teams and doesn’t bake in inter-team dependencies, then carefully coordinated design and release of features can be avoided.

Again, I appreciate your bothering to respond and challenge what I’ve written. You’ve given me something to think about.