The CTO is responsible for organizing their teams optimally to maximize results. To be effective, he must do so by considering the following remark, made by Melvin Conway in 1967 (over fifty years ago).
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
This statement, known as “Conway’s Law,” has been empirically proven and demonstrated in rigorous studies.
Products are “mirrors” of the organizations that produce them. (MacCormack, Rusnak, and Baldwin)
The practical implication of Conway’s law is that the way we “think” our organizations has a direct impact on the systems we develop. It is not possible to design microservices in an organization with a monolithically organized team.
If we want loosely coupled and efficient components, we need to have teams that operate this way. Autonomous but unaligned teams produce loosely coupled components that do not work well together.
Improved communication between the components of a system is a direct consequence of improved communication between the teams that develop them. If two components in a system are overlapping, then there are two overlapping teams in the organization.
We recently started helping a midsize organization that wants to break down its solutions into microservices so that the various products use them in a shared way.
We immediately observed that the current structure of the development teams around the products would make it impossible to achieve this goal. As long as the teams are organized by product, their roadmaps will be driven by the development of these products.
If the organization’s desire is to develop independent services and compose products from these services, then there must be teams organized “by service”, “composing products” from these services.
It is CTO responsibility, regardless of the organization, to identify the desired characteristics for the systems that the company develops. So, ensure that the structure of the teams in a way compatible with these characteristics.
Don’t dare to dream about microservices if all you can manage is a monolithic team. Do not dream of cohesive, loosely coupled services if your management is pure command and control.