Team size and dependency

Melvin Conway doesn't refer to software systems alone. For the information technology world, his observation means that the design of a code base gets largely influenced by the way an organisation structures its own teams. You might be wondering as to why we are discussing team structures here. This has to do with certain characteristics of a microservices architecture, which advocates the decentralizing of all things.

Conway's law :

Organisations that design systems are constrained to produce designs that are copies of the communication structures of these organisations.

Traditionally, the choice of technology to be used is decided and applied organisation wide, so you belong to either a Java camp or some other, such as Ruby or Golang. Similarly, the choice of database is influenced primarily by the resource skills and not necessarily by the need of the business. These choices get passed on to the teams, who are responsible for building the solution. This is not necessarily a bad idea, as it ensures that the organisation is aligned to a particular choice and usually has resources that are skilled in the chosen technology. The problem lies in the one size fits all approach, which gets further aggravated in a monolith as different business modules typically get clubbed into a single unit of work. What may have been chosen as a right solution to begin with may not remain right as things evolve.

In traditional monolithic applications, the development team would build a large enterprise application, pass it on to the testers for quality checks, and then push it to operations for deployment and maintenance work. Within a large development team, there can be further silos created as developers are responsible for different modules and they often share libraries built by other developers. Under such conditions, the question of who provides the support and fix when an issue occurs often becomes a challenging one to answer. Here, teams operate on multiple service or projects and are functionally separated. This can be visualized, as shown in the following image:

Greater success can be achieved with cross-functional teams, working on a common goal, than with functional teams with a us versus them mind-set. This small team would include people with different functional expertise such as development, testing, operations, and others, who can promote innovation through collaboration, which can be critical to the success of a business. In traditional organisational structures, work is passed from one large team to another and the responsibility for building and maintaining a project is spread across multiple teams.

Another notion that is promoted in microservice architecture is that of product not project. This implies that the team should consider themselves to be working on a product and owning it throughout its lifetime. A project, on the other hand, is executed and handed over to operations on completion. In the cross-functional team, the onus of building and maintaining the product throughout its lifetime will be on this single team. Having all the necessary expertise in one team makes it highly productive and self-directed. This can be visualized as follows:

Amazon has popularized the term two-pizza teams, for describing the maximum size of a team responsible for a service. The idea being, that your team should be no larger than a dozen people (they did have a large pizza). There will be times when you need to share certain resources, as certain specialist roles need to be rotated. An infra engineer, for example, won't always be occupied for a single service and may be able to contribute more to others. A lead or architect can pitch in on various microservices and doesn't need to be confined within one team. Thus, teams can depend on other specialized teams which comprise of specialists like architects, managers, and others. These specialized teams would probably have leads and in turn can publish standards and perform reviews, to ensure everyone has the broader goal covered. But introducing too many external checks can have a negative effect, as it would hamper the team's ability to progress and deliver fast. Thus, it's important to give people enough control do their job, yet have a sense of balance between governance of teams to help them when needed. A blanket rule for how to build teams cannot be made, as that largely depends on how your organisation is currently structured.