Team growth by an order of magnitude

At the beginning, the entire public frontend lived in a common monorepository, on a common infrastructure and with a common release. The small team managed, but its team lead became a bottleneck: he communicated with customers, assessed tasks, did reviews, put together a release and sorted out defects after a general regression. The first change was the project manager, who took over the flow of requirements and the basic organization of work. The team received its own release branch and infrastructure, so it could release changes independently.

The acceleration quickly brought more tasks and people. One team and one lead were again not enough, so the application was divided into banking and insurance parts, and a second team lead appeared nearby. Along with the organizational division, horizontal connections arose between leads, peer review and a knowledge base: if a complex case was explained to a newcomer, he then recorded the solution in the documentation. This way, repeated questions stopped returning to the lead every time.

When there were many teams, they began to solve similar problems independently. Common parts of applications were moved to separate packages and repositories. Product and release managers appeared: the former were responsible for business results, the latter helped set up the process, content and timing of releases.

The last step described was the move away from a common monorepository to individual applications with their own repositories. The reused tools were connected as a dependency and developed according to the internal open source model. The core team and architect were responsible for the general engines, and each product team leader was responsible for their application and technical roadmap. The repository boundary finally coincided with the responsibility boundary: the team could choose decisions and was fully responsible for their consequences.

The role of the lead matures along with the system. At first he personally supervises almost every operation. Then he learns to delegate communications and processes, develop new leads, coordinate technical plans between teams, and manage not individual tasks, but the conditions in which teams make decisions. At the same time, the transition to management does not have to be irreversible: it is useful for a strong senior developer to be given a trial period and a safe opportunity to return to the technical track. In the story told, one of the new team leads moved to tech lead just like that a year later.

The main defense against managerial chaos is to understand the business goal, the current stage of the team’s life and your responsibilities at this stage. Architecture and organizational structure cannot be developed separately: changing one almost inevitably requires changing the other.