Relationship between team organization and application architecture

This relationship is known as Conway’s law, which was made by Melvin Conway in 1967 and reads as follows: “Organizations that design systems […] are limited to producing designs that are copies of the communication structures of these organizations.”

Communication within the team is frequent and fluid, with regular planning meetings, dailies, retrospectives and demos. This allows the team to have a high level of alignment and agile coordination, which is fundamental to the development of a component. If you suddenly decide to split this team into 2 teams, there is a disconnect in communication. Communication with other teams is much less frequent, as one of the ideas of teams is to isolate them from externalities so that they can focus on their scope. This reduction in communication between teams makes the task of maintaining a single component more complex. In these cases, there are two options: 1) Split the component into 2, one per team, this allows the teams to decouple and work more autonomously. 2) to keep a single component, which implies setting up a series of coordination mechanisms and meetings between the teams, with the overload that this entails. In addition, the teams are interdependent, which reduces speed and autonomy and affects productivity (since they have to work so closely together, we could almost say that for practical purposes there is still only one team).

Traditionally, team reorganization is often done from the top, and not always by people with a deep knowledge of the application architecture. Time and time again, I saw teams being reorganised around customers, so when a new customer came in, a new team would be created. And in some cases we ended up forking the code as a solution for the new team to be independent and agile. With all that entails: duplicating the code, with all its bugs and technical debt;

In order to make a more architecture-sensitive reorganization that does not negatively impact the application, there is what is known as the reverse Conway maneuver. This consists of organizing the team in such a way that it mimics the architecture of the application to be achieved. To design this type of reorganization, it is essential to count on the collaboration of software architects, who will help to design it using software architecture principles. Teams can be seen as a system, with different components with their responsibilities and whose communication is done through well-defined interfaces.

If you are more interested in this topic, I recommend the book Team Topologies, by Matthew Skelton and Manuel Pais. And if you need help or advice on how to approach a reorganization you can contact me here.