Interview with Alexander Polomodov

Igor opens with a line borrowed from an Oxxxymiron rap battle — I just want to talk about books — saying he had found on Alexander's Medium blog the fifth part of a review of one book, linking back to four earlier ones. Alexander explains where the thoroughness comes from: he writes them for the Code of Architecture club at Tinkoff, which meets every Thursday at 18:00 over architecture books. A big book is split into episodes in advance, chapters allocated by length and topic count, so before the season starts everyone knows there will be, say, five meetings: two chapters in the first, three in the second. By Thursday he reads his three or four chapters and publishes an article with five to eight pictures; on air he returns to them to show that three hundred pages fit one diagram. One episode per book does not work: skimming a whole book at a gallop leaves nothing to discuss.

Guests change the discussion. The club spent four or five meetings on Vlad Khononov's book, then brought the author in from Boston for a final broadcast to answer viewers' questions collected over those episodes; with foreign authors that rarely works out. Last Thursday a colleague came — Igor Maslov, who heads the core technologies division, and who had complaints of his own about the book. Usually at least two people have prepared each episode; those who did not finish the reading still comment. Alexander has complaints too: the authors of the current book, he says, pick only the pieces that interest them, never close the whole picture, and look at some with a bias, fitting the answer to the concepts they sell to clients as digital transformation consultants. So he tops it up with references to other literature — Khononov's decision tree, for instance, leading to a choice of business logic approach, architectural style and testing approach.

In parallel Alexander reads four to six books, and the mix depends on his state: before a conference, when his head is loaded anyway, he picks something for pleasure — a comic book about how cinema works, full of film references and explanations of the techniques. He calls himself an introvert: reading rests him from talking to people, one to one with an author. His notes go into a Telegram channel called the Book Cube, some five months old at the time; before that he wrote on Google Plus, which disappeared, then on Facebook. A Telegram post takes him five minutes and a Medium review far longer, so the short posts come out nearly every day, including on books he disliked. Translations are a particular trigger: in one he counted five places where the meaning had been turned into its opposite, and he blames the economics — translators are paid little, so texts are machine-translated and edited by someone with no knowledge of the subject.

It goes the other way too: Alex Petrov, by Alexander's reckoning, had a hand in translating his own book, and the result came out fine. His Database Internals is probably the club's next pick: the first part, on how databases store data and build indexes, struck Alexander as too heavy for general education, while the second, on distributed systems, goes far deeper. He has two reading lists. The first grew out of a neighbouring division head's request to mentor a man made technical leader over a whole set of teams: Alexander started not from where the man was but from where he wanted to end up, and over lunch mentioned books — on visualising work, on the language to use with the business, and Michael Lopp's Managing Humans, which has a sequel on how leadership changed for him as a manager, a director, a vice president, and a head of engineering. That evening he assembled a list with notes on what to take from each; on LinkedIn it drew around fifteen thousand views. The second list is an article on how to level up at system design: sixteen books with short summaries, read some fifty thousand times.

The word architect triggers Alexander: too much of a halo has been built around it, and it is never clear which architect is meant. Enterprise architects get a blunt question about their usefulness — he has not seen useful ones: beautiful presentations and ideas sold to top management, then implementations that drift apart and a sad ending; he thinks some of the colleagues on the large committee he sits on hold that opinion against him. A solution architect he considers a working arrangement: in a company with a huge landscape of systems, such a person, often an analyst who levelled up, knows both the landscape and a business domain, maps a new product's requirements onto existing building blocks and gathers the people responsible for them; the company has such people too. Strong engineers he would rather call senior engineering grades: the word engineer keeps the expectation that the person still solves hard problems and has impact on a large company. In his talk he describes such a person as a paladin — in the thick of the fight rather than directing from a distance.

Officially Alexander is technical director of a 600-person division responsible for the mobile bank and the API for retail customers; what he keeps for the soul is architecture questions, system design interviews, and an internal chat of 850 people where members increasingly answer each other without him. The manager track, he says, is forced in many organisations: there are no senior engineering grades to grow into, but there is demand for a manager, so people get squeezed into it. That happened to him ten years ago: he was taking over a system from a contractor, the contractor missed the deadline, he was left alone with it, hired a team and launched the woman.ru project — started in 2013, live in 2014, a year after he arrived. It was then that it became clear his people would not be promoted, and he left to be a team lead elsewhere. Asked about delegation, he says growth is tied to pain: until you become the bottleneck and miss deadlines, you will not tie your own hands, and perfectionism is cured by a packed schedule — either you ship something merely good enough or you never ship.