From a UFO game to special projects
Vladimir grew up in northern Moscow and went to a private school with intensive English: his mother, a Russian-language teacher, decided against a state school. Classes of fourteen and C1-level English were the school's real advantage, he says, while maths and computing were basic. Alexander recalls his own teacher mother and his dislike of being taught; Vladimir says nobody pushed him at home, and his only B was in Russian. Programming caught him at a family friends' dacha: a student from the computational mathematics faculty showed a UFO game he had written himself, and Vladimir wanted the same. For the extra maths entrance exam he prepared in a private group of six, four of whom got into that faculty. At the algorithmic languages department he worked through Lisp, Haskell, Prolog, Objective-C and JavaScript, and came away with the lowest pass mark in operating systems for saying the arguments of a system call can be looked up in the manual.
Management started in a student organisation: they helped people avoid expulsion, secured financial aid, and two years as its chairman meant events run by a hundred people for two thousand participants. Comparing himself with fellow students, Vladimir decided the world did not need another mediocre coder and joined a small digital agency as a project manager. Then came the bank, where a junior specialist could still be hired after a single interview: Alexander sat in on that interview with Kostya Yermakov and Anton Kosterin. For his first six months Vladimir picked an R&D team by its feedback loop — a week against months and a year and a half elsewhere — and built a banner constructor for Yandex's ad network, an analyser of bloggers' organic growth, and the admin panel for a Dota 2 tournament whose final pitted employees against clients. In marketing special projects he planned backwards from fixed dates and invested in templates and reusable blocks so the flow of projects could grow without the load.
The magazine: trust, engine, release train
In media projects, which ran the bank's personal-finance magazine and help service, development was unpredictable and trust lost on both sides: the editorial team remembered a two-month feature freeze for a migration to a new engine of Python microservices that never happened. The site by then looked like archaeology: WordPress, then a custom Django engine, alongside it a second Django monolith for profiles and comments, and React on top, though Django still rendered the pages, calling React for server-side rendering and injecting dynamic blocks into its own templates. Updating an icon sometimes required a joint release of the frontend and the monolith. The monolith was cognitively heavy: even its author no longer remembered what was inside, and the system held five feeds instead of one or two. The core team was nine: a couple of testers, three Python developers and frontenders, with a separate trio on interactives such as calculators and quizzes, whose closest analogue today, Vladimir says, is Telegram mini-apps. Before he arrived, Alexander recalls, he had taken that team to a Python conference to talk about the move from WordPress to Django — Vadim Goncharov, a guest of about episode thirty, and the architect went.
The repair went from both sides: product people learned to cut scope and ship something small but alive rather than long and stale, while developers broke work into iterations and shipped behind feature flags. Vladimir also separated an estimate from a commitment: a couple of weeks in answer to a manager is a figure in a vacuum, and two weeks later the task may not even have started. Technically the release train into the monolith had to be untangled, since tasks arrived faster than testers could look at them and there were no automated tests. A planning system followed, for first- and second-order stakeholders, when Jira held both remove this feed and move it to SSR. The reorganisation, by his own account, went by the book from the first Code of Leadership episode with Stas about Team Topologies: after two years it was some fifty people on three media sites, a mobile app and an in-house LMS.
Travel tech, the committee and advice
After he left, former colleagues invited him to the call celebrating the funeral of the old engine: the refactoring took nearly three years, while the media grew from six to thirty million readers. He left media projects on the verge of platformisation, of carving a shared media platform for the group of companies, and moved to Belgrade, from where combining the job with the bank was hard: the bank has no office in the region and none planned. Travel tech came next, the company known in Russia as Ostrovok: after Booking left the market it grew explosively, and the CTO had no capacity left for the non-core lines of flights, transfers, rail and a new car rental product. The inheritance was experimental: one system in Go, a second in Go and Python, a third a Django monolith. In the flights team everyone had left before he arrived, the tests could not be trusted, and four backend engineers were matched by five testers: the cost of a mistake here is not a lost comment but an unissued ticket with the money already taken.
In nine months the department grew from twenty to thirty-two, took up automated testing and got a technical strategy modelled on the magazine one: services failed at three or four requests per second, so there had to be a target picture and stages, the first detailed, the rest sketched. He left after a change of CTO: Vladimir saw an architecture committee as a centre of competence that people bring their work to voluntarily, while the new manager saw a supervisory body blocking cross-team projects; as far as he knows the committee never met in half a year. Alexander adds his story of a testing directorate that offered manual testers only after the code was written. Vladimir now consults: he built an SSR wrapper over Tilda served through Cloudflare, because ads led to a site that took ten seconds to load; the pendulum, he reckons, has swung back to static generation, again a good answer for many media sites. His parting advice: do not fear responsibility, read the data-intensive applications classic, and try Maxim Ilyakhov's book on concise writing, whose peremptory tone Alexander does not accept.
What to take away
- 01An estimate and a commitment are different things: a couple of weeks is a figure in a vacuum, and two weeks later the task may not even have started.
- 02Trust between an editorial team and developers is repaired from both sides: product cuts scope to a small live release, development splits work up and ships behind feature flags.
- 03Five testers against four developers follow from missing automated tests and the cost of a mistake in money; manual control pays off only with rare releases or right at the start, when there is nothing yet.
- 04Positioning decides everything: an architecture committee framed as a centre of competence attracts projects, while one framed as a blocking watchdog does not meet for half a year.