Tinkoff, People Management, Teams, and Meaning

Alexander has been at Tinkoff for almost seven years, and the company has a federated structure: business verticals, platforms and service lines, a split that runs through business and technology alike. Autonomy lets investments, or the servicing platform used by support operators, follow their own plans, but it needs something holding the pieces together.

He owns how the company shows up for clients: the client interfaces — mobile app, web, authentication and authorisation; marketing, external and internal, with ad automation, a refer-a-friend programme and a partner scheme for bloggers; and engagement — media projects such as Business Secrets magazine, and game mechanics inside the mobile bank.

Credit and debit product teams sit in their own verticals; Alexander owns the platforms that set shared rules. The aim is to maintain a relationship with customers after issuing a card. At the time of the interview, his two directorates have around 950 people; the target structure has three.

Over seven years, the company grew from three partly occupied floors to needing more than ten. The bank was already digital but relied on purchased software and in-house integration logic. Alexander says it now sees itself as a developer of its own systems.

The org chart was functional then: an IT department with units of Java, Scala and JavaScript developers and a matrix allocation of people to products, where the balance of authority varied with the people involved, ties to the product were weak, and the work was often run by someone without technical competence.

What set the company apart was its notion of technologists — clever people willing to design a process from scratch; that gave a real edge, but as complexity grew their solutions became what people internally call Swiss cheese: the process works, yet changes and dependency tracing become difficult.

The host asks how managed decentralisation is held together: everything is autonomous, yet hundreds of teams avoid duplicating the same work and the code base does not grow in proportion. There is no perfect answer, Alexander admits. Business synchronisation exists: strategies, plans and metrics of each direction are compiled at a level of abstraction where top managers can see what the neighbours are doing.

On the technical side the connective tissue is the platform — infrastructure and virtualisation as an in-house cloud, plus ready-made bricks: storage, databases, column stores for analytics. Controlling the bricks and the rules for using them hands teams guidelines and constrains variety at once.

Some architectural principles can be checked automatically, wired into build pipelines: this does not yet cover the whole company, but one platform built such control, flagging unreliable services and teams that were not addressing reliability. In the mobile superapp, with around six hundred engineers and more than sixty teams, compliance with platform rules is reviewed by hand.

What if a new team wants its own stack — you like Java, I will use something else? You can build an MVP, Alexander answers, but load will come, compute will be needed, and the request for resources becomes the control point: you must explain why the platform option does not fit.

The platform must offer documented technologies that teams can adopt easily. If a team has highly specialised requirements, it should agree an exception in advance.

He treats an architecture board as a synchronisation point where everyone freezes waiting for someone else's verdict, so decisions are pushed to the level that can take them: directorates keep their own architects, boards and chats, and teams are helped to write blueprints — documents with the problem, the options, the comparison criteria and the reasoning for the choice. Only what touches everyone goes up: replacing the retail authorisation system with an industry-common model such as Google Zanzibar.

Of the older decisions he is still pleased with the visual builder that let designers assemble website pages themselves — micro-frontends there predated the word. A full equivalent never emerged in the mobile app: screens could be configured dynamically, but earlier failed attempts made it harder to revisit the idea.

His rule for judging decisions is to examine what was known at the time, not just the eventual outcome. An architecture decision log preserves that context.

Asked who does not last at the company, Alexander turns to culture. Discussions with colleagues updating the company values helped him identify three principles. The first is a focus on results: engineers understand whose system they are building, why it is needed, and what their work will change.

The second is a drive to improve the work and develop professionally. Tinkoff Growth shifts the initiative from manager to employee: open competency matrices explain expectations, and more demanding tasks provide evidence for a promotion application. The employee agrees the application with their manager before a community of engineering discipline leads reviews it.

The third is cooperation rather than politics: people do not use information as a weapon or expand their territory at a colleague’s expense. Working merely to tick boxes, repeating mistakes without learning, and playing politics make someone a poor fit. Alexander gives the same reasons when asked why he would dismiss an employee.

The host recalls a panel in Belgrade that Alexander missed: after an hour discussing how to measure development effectiveness, its participants had found few clear answers. Alexander explains the limitation of a project approach: measuring whether a deadline was met is easy, but it encourages cutting corners that make later changes harder. Tinkoff therefore uses Kanban by default, improving the flow of value by reducing delays in handovers between analysts, developers, testers, and security engineers.

Speed needs to be assessed alongside quality. Failures will happen; recovery time and the number of failures following releases also matter. An internal tool tracks task movement, lead time, and cycle time. Separate checks show whether services meet their agreed service levels.

Asked whether seven hundred people could do the work of a thousand, Alexander argues that cuts would demoralise the team. He prefers closing projects that no longer justify the effort and moving people to more important work. He qualifies this proposal: managers who equate their importance with headcount can make such moves difficult in practice.

He describes a strong team through Google’s Project Oxygen on managers and Project Aristotle on teams. In his account, the key factor is the freedom to discuss mistakes and bad news without punishment, allowing the team to learn and improve.

Asked about companies with interesting engineering cultures, he names Yandex, while noting differences between divisions, and Avito. He knows less about VKontakte but singles out the scale of its problems and engineering organisation.