Team growth without lowering the engineering bar
The goal of growth is not the number itself, but the ability to solve business problems: increase the flow of customers, deliver functionality faster and maintain system predictability. Lowering the requirements for the sake of hiring pace seems like a shortcut, but after six months a weak team will be left with an architecture that is difficult to add changes to.
When there are ten people, the manager knows the context of everyone and personally sees the gaps. At a hundred, it turns into a bottleneck if it doesn’t build a structure of teams and leads. Responsibility shifts from direct control to the selection of strong leaders, shared boundaries and communication between areas. The teams can be different: the frontend lives through stable APIs, the backend is more deeply responsible for critical systems, the data department needs a broad technological outlook.
Distribution, hiring and cultural transfer
Fintech development is already distributed between the central office, regional centers and partners. Time zones complicate communication, so agreements cannot be left only in personal conversations. Onboarding begins at the interview: instead of an exam, the candidate receives an honest description of the tasks, process, interactions and constraints. After the release, there should be people nearby who helped choose it and are able to explain not only the code, but also the reasons for the decisions made.
An experienced beginner inevitably brings his own practices. A useful answer is not to prohibit discussion and not to remake everything for everyone, but to have fixed solutions and a way to propose a change with arguments. In a small group, culture is transmitted through daily interaction. As it grows, it has to be made reproducible: principles must be articulated, important agreements documented, and examples shown. Otherwise, autonomy quickly turns into incompatible local rules.
Engineer, team lead and architectural solution
The role of the team lead depends on the company context, but he is responsible for the team’s results and connects several levels. It influences the “what” question through understanding the business process and the quality of the requirements. The “how” is answered through the development process, architecture, testing and infrastructure. He does not have to personally make every decision, but he must create an environment in which engineers understand the goal, can argue on the merits, and record the overall choice.
In large organizations there is no one ideal role model. Somewhere an architect is a separate position, somewhere this work is shared by leads and strong engineers; Some teams are cross-functional, others are organized around a competency or platform. A comparison of Tinkoff.ru and CFT shows a general principle: the structure is useful when it corresponds to product boundaries and makes ownership visible. Conferences are valuable as an opportunity to compare such decisions with someone else's context, without copying the entire practice.
What to take away
- 01Team growth is justified by business results; lowering the hiring bar creates a deferred architectural and organizational cost.
- 02At scale, the manager works through leads, boundaries of responsibility and general principles, rather than personal control.
- 03A distributed team culture requires fair hiring, explicit onboarding, and written engineering agreements.
- 04Roles and structures cannot be copied without context: it is important that they reflect real product and system boundaries.