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

Alexander opens with his own path: one of the country's leading technical universities, work at large internet companies, the launch of woman.ru with his team, the people's ratings at banki.ru, a small advertising startup — and, at the end of 2016, Tinkoff.ru and its customer acquisition unit. His remit covers the unauthenticated part of the site with its home page, the admin panel that configures the web and other systems, the automation of every acquisition channel, and a personalisation system with hypotheses checked by tests, so a prospect sees a relevant product. Then the company as a whole: since 2013 many products appeared, each needing new clients, so in 2016 acquisition was set to be automated far more seriously. Alexander's metaphor: from the inside the company is a city where business verticals are skyscrapers on a shared platform with a private cloud and a slice of public ones — together, the ecosystem. The growth exists so any direction can launch relatively painlessly, and repeatability needs processes, not just a platform.

Acquisition repeats the company's structure in miniature, and Alexander splits his approach into three facets: what we do, how we do it, and with which team. A team lead, by his account, influences strategy and the product-and-process approach only indirectly, yet has to understand both. He offers four questions: can you explain the company's strategy in plain words; can you judge the health of the business — by the share price for public companies, by market share for private ones; do the top managers have a vision that reaches employees and the market; is there still time to think about strategy, or does day-to-day churn swallow it. For the details he points to the book Managing Humans and its separate chapter on the health of a company and a team. The product approach means running any product, external or internal, as a product with goals and requirements — hard in a hierarchical structure, where edges between departments get in the way, and where ideas always outnumber the teams that could take them on, so it is worth understanding how the ones that go into work get picked.

The first item a lead influences directly is business processes. Development is rarely an end in itself: a company earns by automating a process effectively, and the quality of that automation is how a team is judged. Hence the tasks: work out which processes belong to your team, document them yourself or with an analyst, see which links drop out of the automation, and check whether effectiveness is measured at all — at least by applications processed and processed successfully. If automation is too expensive or slow, the link goes to people outside development, content managers for instance. The second item is requirements: the quality you put in is the quality you get out. Alexander recalls requirements written by business customers rather than analysts — one line saying to create a brands section, Vasya knows what to do, estimated at a month, after which nobody could tell what had happened. In a new team the lead looks at how tickets are formatted rather than their substance, brings in templates for a task, a bug and an epic, agrees on recording meeting outcomes, and sets criteria for sufficient documentation.

Which development process is chosen — waterfall, Scrum, Kanban, XP — matters less to Alexander than the recurring failures: nobody designed the process, it simply turned out as it did; there is no visibility inside the team, so when a problem arrives you cannot tell whether it is the people or the process; there are neither process nor outcome metrics, so nothing compares with earlier periods; and good practices from neighbours go unused, even when story points instead of hours work well for them. Behind that usually stands the absence of anyone personally responsible. Architecture he calls one of the key items: often there is no design stage, a prototype suddenly becomes the production solution, and you live with it afterwards. The most troublesome legacy system is not a frozen one but the one the business keeps adding features to without planning technical development. No architect will fly in by helicopter with a ready architecture: the lead audits the systems himself and builds a technical roadmap — in acquisition Alexander does that personally.

Alexander calls speed of delivery to users the key competitive advantage, and it runs straight into testing. The anti-patterns: the reactive habit of writing code first and covering it with tests later; separate development and testing departments tossing the system back and forth; manual testers and automation engineers who do not get along inside QA itself; and hiring test engineers on low rates because testing is thought easier. He recalls one development team writing tests in one framework while the automation testers used another: some scenarios were covered twice and some not at all, until everything moved onto a single framework. Infrastructure is the foundation of the rest, and the obstacles here are the barrier between development and operations, which has no motivation for frequent releases, the lack of deployment automation, and internal services with no clear SLAs. Responsibility he divides so: the development team owns its services end to end, operations the SLAs of the services those rely on.

The facet of with which team comes down, at a lead's level, to hiring — where the vacancy also has to be sold — onboarding, developing people (a lead has arrived if his people really grow), and everyday support down to lighting and ventilation. The conclusion: culture has to be shared and to run through the whole company, or the pain appears at the seams between departments, while a lead can settle a great deal at his own level if he takes the initiative. The roles of head of processes, testing and infrastructure were introduced at some point so leads were not left alone with all this. In the Q&A Alexander described teams dividing like an amoeba: the content management system with thirty-odd internal customers was cut from the monolith into microservices, and teams split across banking, insurance and investment products. Other answers: a hundred-odd interviews in two years, after which you feel like the team's coach rather than its hostage; selling changes through an estimate of cost and effect in money; and the fashion for doing away with leads, which, by his account, did not take everywhere at Booking.