Technical Leaders at Tinkoff

Alexander starts with himself: seven years with the company, currently technology director of the area owning client interfaces, marketing and engagement — the yellow app, the website, advertising and project stories such as the monopoly and five-letter games. He splits Tinkoff's technology directors into three parts: business verticals with their own IT (investments, insurance, the mobile operator, the bank for individuals and the bank for businesses), platform solutions (infrastructure, the development platform, the data platform), and service lines that serve the other verticals. Each part has its own technology director; Alexander sits closer to the platform side and separately owns the company's approach to architecture and process questions. Asked who counts as a CTO, he says a division head certainly does, but past that it is semantics. A division can hold separate products with their own CPO, and then a department's technical head is effectively a CTO too — as in non-financial services, which include the Tinkoff Gorod product and the Travel area, by some statistics the second or third travel agency in Russia.

Such a person is autonomous and outside the company would be called a CTO, yet the market holds a catch: at Tinkoff, platform solutions and corporate functions — hiring, budgeting, cross-cutting processes — absorb part of the pain, while elsewhere their effectiveness suddenly becomes his own responsibility. Alexander unpacks the hierarchy from the bottom: it starts with the team lead, who has a competency matrix. The first grade owns everything happening inside a cross-functional team: delivery and its predictability, management within the team, and engineering practices — service quality, non-functional requirements, controlled technical debt, reliability. The last matters because of an ecosystem effect: people transfer a slip in one product onto the whole brand. Teams are not grown beyond ten people. Above a group of teams in one domain sits a lead of team leads — the exact naming settled on after unifying titles he honestly does not remember — then a department of a hundred to a hundred and fifty people, whose business reviews ask not only about P&L but about delivery metrics, quality and security, and then a division of several departments, sometimes called a centre.

A separate role here is the delivery manager. From 2020 the company moved from a functional split to a product and platform one, and when web developers, mobile developers and operations are merged into one end-to-end team, effects surface that leaders of the old paradigm handle badly: change management, explaining why things will get better, and knowing which metrics to watch after the reshuffle. The example comes from mobile: a very large payments and transfers team of some forty developers and analysts, split in two, while deep back ends built the same functionality. The transformation plan, stretched over a long period, was drawn by the CTO of payments and transfers, Sasha Piskunov, while delivery managers helped organise the end-to-end process inside the newly sliced teams. Alexander insists this is not coaching in the mode of "I told you, implementation is your problem": such people are judged by how effectively the change went and which new bottlenecks it exposed.

The process people love the Kanban Maturity Model — the poster hangs on the glass right beside him — but he prefers turning it into practice rather than religion. An internal tool pulls task data out of Jira and other sources; there is no single process for all, each team picks its own template, so even configuring a dashboard demands some queueing theory: cycle time, lead time, active phases. The team dashboards are meant to cascade up to areas, departments and divisions: at an operational review a manager would then look not at "how are things and were there any failures" but at a team's dynamics against its own past — how many pull requests, how lead time changes. A top-level prototype works, but teams are picked into it by hand, and there are close to a hundred. Engineering metrics — service stability, meeting the SLAs, automated tests — are still kept apart: the obstacle is a metamodel in which the managerial structure, the product structure, repositories and runtime elements do not match one to one.

In the second half the hosts ask how one becomes a technical leader here; Alexander points to his own article and talk and walks through the three team lead interviews. The first covers the language the candidate calls their main one. The second is system design at a deliberately modest bar: a team lead does not design for everyone but must understand trade-offs across layers and act as an arbiter. He illustrates a layered organisation with a dialogue: the back end proposes implementing the logic on the front end, the front end asks for GraphQL so that "magic happens under the hood", and the API author decides that RPS is the database's problem. The third covers running a team: people management, delivery and engineering practices, down to whether the person sees what is wrong with relying on manual testers alone. Higher levels add business and IT alignment, hiring and budgeting, and Alexander runs the managerial interview through the candidate's real situations rather than hypothetical cases; fit interviews with teams follow.

One of the hosts offers his own insight: across several recent recordings with different leaders, the architect is ceasing to be a figure in a distant tower — the role spreads across managers, and architectural understanding is now expected from the team lead upwards, which was not so before; the same expectations, he observes, hold at Yandex, Avito and VTB. Alexander replies that architects exist on his side too, usually not inside a team but attached to a product's technology director: a problem should be solved where there is enough context, not escalated to an overloaded person who hands back a generic solution. It works through an architecture process: a team writes an RFC with the problem, the options and the comparison, and the architect challenges the document and points to who in the company faced something similar. Hence the written culture and a register of architecture decision records — too often "it happened historically" leaves no traces. He closes by advising growth through reflection: an interview quickly shows who has digested their experience and who arrives at the insight mid-conversation.