Tinkoff.ru development culture: transition from a mono-product to an ecosystem

Public Tinkoff.ru participates in the full attraction circuit: receives traffic, displays content, collects applications, supports experiments and returns data to analytics. When there are many products, the frontend ceases to be a showcase of one bank and turns into a platform for product teams. Shared pages, forms, tracking and personalization should be developed as internal products with users, metrics, documentation and a clear quality of service.

It is not enough for an engineer to receive a task in the tracker. You need to understand the business process, the constraint and the expected effect, otherwise a locally correct solution can worsen the entire customer journey. The requirements should allow you to check the result and explain why it is needed. The team leader does not determine the company’s strategy, but is able to connect it with his zone: clarify the process, show the bottleneck, agree on the quality of the production and prevent the team from optimizing activity instead of results.

The development process is chosen according to the context, and not according to the name of the methodology. It is important to make the flow visible: where the task is waiting to be solved, how long the release takes, why returns and defects occur. Metrics are needed to talk about limitations, not to rank people. The architecture sets the boundaries of change. Teams must have clear ownership and a technical plan, otherwise organizational independence will remain a declaration on top of a common monolith and joint release.

Testing and infrastructure are part of the delivery method from the very beginning. Quality cannot be added as a separate step before release: requirements must be verifiable, tests must be automated at appropriate levels, and the team must be responsible for behavior in production. Reproducible environments, CI/CD, observability, and secure rollback transform a release from an event into a routine operation. These capabilities require investment just like custom functionality.

Hiring starts with matching the real environment, onboarding starts with explaining the product, architecture and decision rules. As they grow, verbal agreements stop spreading on their own: they need to be captured in documentation, tools, and examples. This does not mean regulating every step. The goal is to maintain common engineering principles so that autonomous teams can make different local decisions and still remain part of the same system.

The team lead is responsible not only for the execution of the sprint. It links business purpose to process, architecture and people development; notices where the team depends on the hero; cultivates next leads and makes the way of working repeatable. It is impossible to change the entire company from one position, but you can improve your own profile and show the result to your neighbors. Culture scales through working practices and feedback, not through a slogan from above.