A Hundred Books a Year, a Day Hour by Hour, and the Path to CTO: the First Subscriber AMA

Balance, as Alexander's wife jokes, does not really exist: he gets carried away by things. He spends about eight hours at work, while mornings, evenings, and a few weekend hours when he is lucky go to self-development: books, conference videos, and papers on distributed systems and management. Add an hour of LeetCode problems and a couple of hours of reading a day to the working week, and the brain's active time easily exceeds twelve hours a day. He has read since childhood and gets through a hundred-plus books a year; the home library holds several thousand volumes, and the choice depends on his mood: a graphic novel to rest, astrophysics to contemplate, or a book on trustworthy A/B testing because his company is building a similar platform. There are no speed-reading techniques: he checks the table of contents and the introduction, then reads page by page, sticks bookmarks in, and corrected the clumsy Russian translation of the third edition of Tanenbaum's Distributed Systems right in the book.

The summary comes a few days after finishing: Alexander sets the book aside and rebuilds its structure from the bookmarks, which often turns out to be surprisingly hard. Once the summary is written, a mental checkbox appears: the book is indexed and ready for conversations and arguments. The Telegram channel and Medium serve as external memory. The day runs by the clock: up at six, a walk with the Australian Shepherd around Khodynka or Berezovaya Roshcha with a conference talk on, and by seven a post, a coding problem, or a book while the children sleep; at half past eight the office near Belorussky station. Then three or four recurring meetings, one interview slot a day, reliability metrics and reports, a meeting with direct reports, sometimes the gym instead of lunch. By seven the nanny hands over the youngest, at nine the children go to bed, and after half past nine an hour or an hour and a half goes to problems, articles, and chapters of his own book, which is going slowly.

Asked how much remains to be read on architecture, Alexander answers that the more you know, the clearer how little that is. Books are a lagging source, written once a topic is no longer new, so he prefers papers and white papers. Start with the classics: GFS, Borg and Kubernetes, Amazon's Dynamo and Aurora. Among recent ones he singles out Deployment Archetypes for Cloud Applications by a Google Cloud vice president and a Google Technical Fellow: fifty pages on distributing an application across zones, regions, and the whole planet. LeetCode is there to keep the coding hands alive: when you have not written production code for a long time, they forget, and he remembers that feeling from returning to development after a stint in systems analysis. Every three years he reviews what is new in cloud infrastructure, retakes the Kubernetes administrator certification, and assembles an application on GCP or AWS: six months of preparation refresh the picture and remind him that things are smooth only on paper.

He calls the LeetCode system design course good but notes that without a book behind almost every two-minute segment the concepts would not have landed. Start simple, and above all change the system with your own hands. His design and troubleshooting skills grew sharply ten years ago at woman.ru: twenty million unique visitors a month, 200 to 300 requests per second, about two gigabits of static content, and five or six servers which he and a friend ran personally. He splits the question about the most captivating math book in two: the hardest is Charles Petzold's The Annotated Turing, four hundred pages dissecting a single paper, while for pleasure he names Petzold's Code and popular science; the most useful math at work turned out to be mathematical statistics, which he disliked at MIPT. Now the company calls itself data-driven, and without a methodology for hypotheses and experiments statistics turns into fitting the desired result; so he advises reading the Russian translation of the book on trustworthy A/B testing with the original at hand, and the experimentation platform sits in his area of responsibility.

As a child in Severodvinsk everything came easily; he had to learn to work at the lyceum and MIPT's correspondence school, where a physics teacher valued diligence over talent. At MIPT's Department of Control and Applied Mathematics the first year was easy, in the second Alexander nearly dropped out over academic debts and online games, and by his fifth year he had straight A's. Hence his formula: curiosity, diligence, and the luck of being in the right place, rather than innate talent. At MIPT there is always someone smarter, and what matters is to steer by your own trajectory. The career followed the usual ladder: developer, analyst, developer again, team lead, acting CTO at a startup, and a move to Tinkoff for a position with less money but more prospects. When you solve problems instead of creating them, responsibility grows on its own, from five or ten people to dozens; change itself is what interests him, and without a challenge he gets bored. A staff engineer is defined not by a list of skills but by experience: having been through complex cross-team stories and being likely to repeat the success.

He gives no figures for a bank CTO's income but explains the mechanics: the higher the position, the larger the share of bonuses and long-term incentives, anchors that keep a person in place. Compensation often exceeds the market because knowledge of how the company works is worth more inside than outside, and a golden cage appears; holding several jobs at once he considers a tactic that contradicts a long-term strategy. Both tracks lead to CTO: at a startup the technical director needs deep expertise in the subject, while in a large company the management path is simpler, yet a manager without technical grounding loses the engineers' trust. Engineering productivity after the MTS True Tech Day talk is moving from surveys to process and DORA metrics, and he is handing the topic to another leader, an example of giving away a responsibility. SRE in big tech is a mix: platform teams own operations themselves, while product teams get a separate layer of engineers. In three to five years he sees not a C-level seat with a board of directors but books on engineering management and strategy, a PhD, and new episodes.