Skip to content
back to the episode
Episode summary2025CTO

Platform: An Engineer with a Product Mindset

The guest of the 46th episode is Vladimir Kalugin, technical product manager of T-Bank's internal developer platform, owning the GitLab, CI/CD and artifacts domain. Alexander walks the whole path with him: from a magazine's only developer to the Spirit platform, whose first identity had to move from the Warhammer universe to a kindly platform spirit.

Code of Leadership · episode #469 min read

This summary is shorter than the full episode; examples and assessments reflect the participants’ experience and views.

The main thread of the material
01

From floppies and PHP to Tutu

Vladimir first used his parents' floppy-disk computer with its blue DOS screen, then got one of his own at the dacha: from games he moved to modifying them, then to asking how they work, hitting the ceiling of a Basic-based tool for building games. He dates the period by the first Need for Speed Underground, around 2003 by the participants' reckoning; in 2008 he entered Bauman university, department IU5.

He learned PHP out of stubbornness: he wanted a fan site about the Warhammer universe, got a white screen because PHP hides errors by default, and heard from a bearded sysadmin on a forum: "What makes you think we will help you here?" He took offence, bought a huge book, and is grateful to him today.

In his third year a car magazine's representative walked into the lecture hall: they needed a programmer to maintain the site. Vladimir caught him in person, skipped the queue of emails and became their only developer; his only technical neighbour was a system administrator with a sweet in every pocket. With nobody to discuss code with, technical books saved him, though many, as he sees now, were translated manuals with linking text between chapters: the second edition of one on writing your own CMS opened with the author admitting no CMS fits every case.

Patterns clicked only when he wrote his own framework and met the problems they solve; Alexander adds that not understanding them is sometimes safer, otherwise they get stuffed everywhere and the answer to "why?" is "I have read GoF, I am practising".

02

Tutu, Go and the Spirit platform

He left the magazine when a promotion turned into advertising duties without doubling his half-time rate, and a vacancy advertising free yoghurt in the office brought him to Tutu, which hired him straight as a mid-level developer for more than he asked: the manager was surprised a lad from a magazine talked about patterns and databases. Then came five golden years at the company, beginning on the PHP monolith selling railway tickets.

The culture was real: newcomers got Tony Hsieh's Delivering Happiness as compulsory reading and an album of company rules, and a book you read earned about five per cent of salary, one a month at most, with a list and reviews in Confluence. Alexander notes that explicit principles let you check decisions against them; without them a growing company argues through implicit assumptions.

Vladimir considered himself an introvert, yet kept pestering his team lead with process questions, and became first a half-time scrum master and then a team lead with no right to refuse: a line manager of all backend engineers in the rail-travel business, running one-on-ones and voicing promotion opinions with no administrative authority.

Multimodal travel, where a trip was assembled from a plane, a bus and a train, brought Go into the company: Vladimir's team rewrote the search in it, it became several times faster, the unified results page launched, and Kafka arrived too.

The multimodal project worked technically but was undermined by covid and sanctions, while Vladimir was undermined by boredom and burnout, whose symptoms a course on burnout and energy helped him name; after a holiday he resigned in a single day.

He looked for the next place by an amusing criterion: nothing like Tutu with its endless agreeing. At what was then Tinkoff the recruiters kept him waiting a fortnight, so he agreed to come only if all three stages ran in one day; the last two were run by Igor Maslov, the head of the platform. He set that offer aside for another company, but checked its history — by the accounts he found, everyone there had once been dismissed in a single day — and joined the platform at the end of 2020.

03

The platform, MTS Travel and DevEx metrics

The platform was then a separate GitLab installation where everyone kept only developer rights, with roles and settings living in the platform itself; Vladimir's first tasks were about authorisation on the open-source Ory stack, to which he contributed service-account support. Then came a quota engine, a GitOps engine and an API manifesto so that integrating teams entered by one rule set; Alexander notes that such a central point has to be designed right away, and Vladimir confirms the approach paid off: there are now more integrations than the platform can track.

At some point the platform identity changed: the harsh nod to Warhammer 40,000, which risked questions from Games Workshop, gave way to a kindly platform spirit, and the rebrand brought a turn from directive development towards developer experience.

Tutu's former CTO, who had left to launch a travel product at MTS, pulled Vladimir out: a line manager for all backend, a team and an architecture from scratch. A deadline before shareholders was already set, and the outsourced architecture could not cope: a search request took 30 seconds because of an N+1 in subqueries across two or three dozen attributes.

The date moved, the architecture was rewritten and they launched during the mobilisation days; work on two consecutive days off followed an honest conversation: double pay, and a promise that refusing would cost nobody anything; everyone but one agreed.

GraphQL imposed by corporate architects was fought off with "we are not Netflix".

Content was a separate challenge: the booking systems the team connected returned only a name and a tariff, without photos or service descriptions, and the same hotel is named differently across systems.

Dima, who had not given up for two years, called him back. MTS Travel closed a year after Vladimir left.

The technical product manager role, he says, has not settled on the market: abroad it connects a product manager with the technical team, while the company argues between a product manager who understands technology and, in the platform, an engineer with product skills; Alexander, who oversaw system design, finds the second a better fit for dev-to-dev products.

His first task was SPACE metrics: surveys and system metrics are collected together, the free-text field produced the most insight, and the dashboard is open by team, department and company.

DORA's lead time is covered to about 40 per cent: on a landscape where every team deploys its own way, linking a commit to production is hard.

AI on a platform whose basic problems are unfixed is, in his words, a plaster for a torn-off leg.

Takeaways

What to take away

  1. 01Vladimir's advice is not to skip the fundamentals: knowing the base lets you compare technologies by their principles; Alexander adds that otherwise a tool gets picked because it is fashionable or turned up on Twitter.
  2. 02A technical product manager on a platform is an engineer with product skills rather than a product manager with a technical prefix: that is the reading Vladimir describes and Alexander supports.
  3. 03DevEx needs both surveys and system metrics: responses can reflect cognitive biases, while telemetry does not reveal the whole context. In Vladimir's experience, the free-text field yielded the most new insights.
  4. 04Someone else's solution without your own problem does not work: GraphQL pushed down by corporate architects was fought off with "we are not Netflix", and before such initiatives Vladimir advises a census of what teams already run.

Sources