In a company where the software is built based on microservices, every single stakeholder needs to be involved in decision making.
Microservices are a huge paradigm shift. Usually, large organizations tend to build software in a very old fashioned manner. Big releases every few months that require days to complete the quality assurance (QA) phase and few hours to deploy.
When a company chooses to implement a microservices-oriented architecture, the methodology changes completely: small teams work on small features that are built, tested, and deployed on their own. The teams do one thing (one microservice, or more realistic, a few of them) and they do it well (they master the domain and technical knowledge required to build the software).
These are what usually called cross-functional teams. A unit of work of few people that have the required knowledge to build high-quality software components.
It is also important to flag that the team has to master the domain knowledge needed to understand the business requirements.
Here is where the majority of the companies where I have worked in my professional life fail (in my opinion). Developers are considered brick stackers that magically understand the business flows without being exposed to them before. If one developer delivers X amount of work in one week, ten developers will deliver 10X. This is wrong.
People in cross-functional teams that build the microservices have to master (not only know) the domain-specific knowledge in order to be efficient and factor the Conway's Law and its implications into the system for changing how the business processes work.
When talking about organizational alignment in microservices, autonomy is the key. The teams need to be autonomous in order to be agile while building the microservices, which implies keeping the technical authority within the team, as follows:
- Languages used
- Code standards
- Patterns used to solve problems
- Tools chosen to build, test, debug, and deploy the software
This is an important part, as this is where we need to define how the company builds software and where the engineering problems may be introduced.
As an example, we can look into the coding standards, as shown in the following list:
- Do we want to keep the same coding standards across the teams?
- Do we want each team to have their own coding standards?
In general, I am always in favor of the 80% rule: 80% of perfection is more than enough for 100% of the use cases. It means that loosening up the coding standards (it can be applied to other areas) and allowing some level of imperfection/personalization, helps to reduce the friction between teams and also allows the engineers to quickly catch up with the very few important rules to follow such as logging strategies or exception handling.
If your coding standards are too complicated, there will be friction when a team tries to push a code into a microservice out of their usual scope (remember, teams own the services, but every team can contribute to them).