One of the most mentioned perks of introducing microservices is autonomy. Each service is independent from any other service, only providing a well-defined (and hopefully versioned) public API. To the outside world it does not matter which technologies or even programming languages are being used internally, which gives a lot of freedom to the developers writing the services.

Despite the ongoing hype, microservices are not for everyone. The complexity they add usually outweights the benefits for a single small development team, which might be better off by focussing on separation of concerns on a lower level to facilitate a later refactoring to microservices when needed.

For larger teams though, breaking down your application into loosely coupled components can be a real game changer – not only for technical reasons, but also because it allows you to apply the same pattern to your developers. Instead of having one large, hard to manage team, you could split it up the same way you split up your application!

No autonomy without alignment

The idea of splitting up your core application into multiple services can also be applied to your team setup: in theory, every team could have “their” microservice, since the only thing they need to agree on with other teams is the public API.

This also means that you could easily end up having services written in different languages. Maybe team A implements a new service in Go just because they heard about it on a conference and wanted to try it, while team B uses PHP 7 along with the Phalcon framework. What you will get are highly specialised teams, and conventions like collective code ownership or even the most basic coding guidelines will not be applicable anymore.

There are certainly several ways to avoid this, but one very efficient one is setting de-facto standards that every team commits to. This should not only be a set of languages to be used but also conventions like coding style or CI processes. By establishing these standards, it will be a lot easier for developers to switch teams, as they can focus on learning details about the domain instead of fiddeling with technical differences or even having to learn a new programming language.

Loosely coupled, tightly aligned

Achieving team autonomy is great and can give your company a huge productivity boost, but it also requires a great deal of alignment across teams in order to keep going into the right direction. As always, communication is the key to success.