Alexander Polomodov and Kirill Zuev: Studio CFT live @ CodeFest 2019

Alexander introduces himself as head of development in acquisition, a large unit that owns the unauthenticated part of the site, the admin panels for managing content, including part of the content of the mobile apps, the tooling that automates acquisition channels, and the personalisation and testing system used to check hypotheses. The host translates that into business terms: everything that increases the incoming flow of customers. The unit now has around a hundred and twenty technical people; two and a half years ago there were ten. Hiring, for Alexander, is work with the market: HR pushes the brand, the company publishes articles on specialist sites, joins conferences and sends speakers, but the main thing is to show a person a goal and a challenge and explain why it will be interesting here. While the team is small you find strong people one by one — the market is not that big and you know them personally. As it grows your own circle stops being enough and word of mouth is switched on, with your engineers asked to communicate outwards more.

The host asks straight out whether there was a moment when he wanted to lower the bar and take everyone who reached an interview. Alexander calls that path far too dangerous. The goal is not headcount but solving business problems: a flow of new customers of a certain scale within a budget, with the teams grown to make that process simpler and more predictable. People who are too weak ship features faster at first, but six months later you get a system you can barely fit those features into, so you balance on a thin edge between speed and team quality. A technical rebuild ran in parallel: the monolithic backend system responsible for configuration and part of the mobile content was rewritten from its first version to its second, and the frontend got a lot of attention. In places Alexander plays the architect himself and improves the systems piece by piece — a revolution is impossible: the business cannot stop and expects the systems to keep working and gaining features.

Growth changes the manager's own job too. With about ten people you are across everything and know exactly who is missing; beyond that you build a management structure beneath you or become the bottleneck, and looking back you no longer recognise everyone: you know the key ones and talk to them. The trick is not to slide entirely into management. There are roughly four units, Alexander says, and they differ a lot; he covers three in detail. The frontend barely touches the backend: it has a set of APIs and lives inside its own competencies. The backend demands far more, so the hires there are those who can be trusted with the systems the Tinkoff.ru site and the mobile apps depend on, and they are checked thoroughly across a range of areas. The third unit is effectively their big data: online data, user segmentation and tests. The zoo there is wide — the Hadoop ecosystem, Java, Scala, C++ and more — with about twenty people, each knowing three or four languages, so you look at breadth of outlook and at the knowledge that unit needs.

Regional development centres began opening a year and a half or two years ago; contractors and outstaffers came earlier. Some teams are spread out geographically, the frontend one especially: six or seven of its thirty developers sit in the central office, and two testers out of seven or eight, with the rest across the country and one team in Novosibirsk. A four-hour gap hampers communication, but they cope; the host notes his own spread across time zones is much the same, and they manage too. A new joiner need not be a junior: a senior with a rich background and his own idea of how to do it better may turn up. Alexander, who gave a separate talk on hiring and motivation, starts adaptation at the interview — not an exam but a discussion, with technical and soft questions, where you hear how the person ended up opposite you while explaining the process, where tasks come from, who they will talk to and who they report to. So the candidate decides on the doorstep whether the format suits him.

The joiner then lands in a team, possibly with the very people who interviewed him. Usually there are no problems, but holy wars do happen, and the unit arrived at a simple order of business: a series of discussions on the contentious question, then a shared decision that gets written down. A new person is shown what was agreed before he arrived — however handsome and expensive you are, we are probably not redoing all of it, though you can propose targeted changes if you justify them. Culture, the subject of a separate talk by Alexander, splits into three parts: what we do, how we do it and what sort of team we are. A team lead has almost no influence on the what, which is company strategy, but he can get into the business process, see its steps and bottlenecks and demand properly worked-out requirements instead of abstract ones. The how is the development process, architecture, testing and infrastructure; there the lead sees the problems and fixes them from his own position.

Technical people, Alexander is convinced, need to enjoy their work: they spend so much time writing code that without understanding what they are doing they cannot judge their own results. Culture shifts as the team grows: a small team gets by on one-to-one conversations, while a large one without agreed approaches has everyone solving things their own way, so culture must be passed into the teams at least in words. Asked about team leads, Alexander argues for engineers in acquisition being across how the business works: traffic is bought in a channel and must convert into customers, the frontend builds pages, forms and special projects, and everything is countable — from money lost while a broken form was down to money earned by a percentage point of conversion. The engineers who pull data from the ad systems, Facebook and Instagram among them, built those integrations, but the effect only showed once reports were built on that data and decisions followed. Hence the rule: explain in advance why it is all happening, and give feedback on the result, ideally in money.