IC Track: Grow by Scope, Not Headcount

Chernikov was born in Moscow, but in 1998 he was declared an orphan, his grandmother became his guardian, and he spent the next fifteen to twenty years, by his own rough count, in Kaluga. That year he watched the film Hackers and decided he wanted to be a hacker: he had no idea what that meant and no computer — he drew a keyboard with a stick in the dirt and "played" arcade machines through a shop window. About three years later a social inspector asked what he wanted to become; the fork was short: a soldier or a programmer. He entered the Kaluga branch of Bauman university, which by his own account built his soft skills more than technical ones: only two or three of the thirty in his group became developers, he got hooked on student comedy, and he passed round senior students' homework obtained up to the sixth year — two pills, like Morpheus, and the choice was theirs.

From his third year he worked at a design bureau, drawing SolidWorks models for CNC machines that milled housings for space-bound radio equipment. For his diploma he was handed a stack of quarry-crane drawings: he built an assembly of 3,500 parts and a genetic algorithm that fitted the dimensions to the input parameters. In Moscow a PHP vacancy came up: he learned the language in two months, then repeated the trick to become a middle Python developer once PHP had disappointed him. He weighed Thai boxing, esports and development until he was 26: the prize money for a tournament he won looked laughable next to even a modest salary. Two years into Python the tasks started clicking and a crisis arrived: in the mid-2010s the only answer to "what next" was that plus fifty thousand roubles meant becoming a team lead. That meant fifteen to twenty per cent on a senior salary, and the interviews, he recalls, felt like a wizards' duel from Harry Potter: sprints, story points, and the killer spell — results above processes, delivered at any cost — after which the offer came instantly.

His career then ran in roughly one-year cycles. A startup with a vague product/market fit where the funding ran out; friends' crypto exchange, where he dusted off C# and wrote his first adapters in Go; nine months without production and a visit from investors, after which he "stepped out for lunch" into the neighbouring Moscow City tower — to Ozon. He had been referred as a team lead, but the spreadsheet got mixed up and he joined as a senior; it was his first big tech, and he has preferred it since: a large business survives losses that fold a startup. Having agreed a move into the lead track, he ran into the February hiring freeze and became team lead of himself, a laptop, two monitors and a chair — with no raise: grades and reviews did not exist yet. Wildberries then bought him over with the idea of an in-house private cloud, and three months later asked him to become CTO of the supplier portal.

The cloud was shut down along with everything that made no money; the portal is alive: a huge .NET monolith was carved into Go microservices, the SLA had to rise — the monolith carried transactional and analytical load alike, so a report generation brought it down along with revenue and user experience — and Go engineers had to be grown in-house, the market having been swept clean by others. The host stops on the word transparency: what people want behind it is predictability and delivery guarantees, while tossing a coin is perfectly transparent too. His own advice is to ask on joining what happened to the previous manager. At Yandex Eda, Chernikov was warned never to lose the outstaff experts who had known the system since 2016; he lost all of them in a single day — and the service still works. The host adds his version: people leave not because expertise cannot be rebuilt, but because the level they grew into was never paid back.

Chernikov joined T-Bank as CTO of the ecosystem security centre — the host himself ran the management section of that interview. A year later came another crisis: he wanted trust and full responsibility for decisions instead of directive management, and a scope larger than one feature. The host's deputy Anton Kostyanoy sent him to Pasha Permyakov, the CTO of investments, who said they needed real engineers, and the question "so I can write code?" settled it. He now drives cross-cutting reliability and availability projects without direct authority over a single team. It works because the unit had built an institute of project delivery before he arrived: there is no split into technical and business projects, only a project and its income — a one-pager, a defence at the board, and the money effect calculated with an analyst over three years. His example is incident management: the people on the call and the time to localise are measurable, and the price of downtime is enormous.

Tracing here is a tool, not a goal: propagating context and plugging in OpenTelemetry is not enough, you need attributes and full sampling — and the host recalls how rolling out tracing triggered incidents itself, when traces were shipped one by one rather than batched. Asked by the guest who staff engineers are, he answers through scale: the company builds its own data centres and a lasagne of platforms, and alongside that lives domain complexity — responsibility for money, load spiking by an order or two, bots next to mobile clients, regulation. A new type of tradable instrument runs horizontally through every system, and you need someone whose head the domain fits into. Such engineers carry managers' grades, but there is no predictable ladder: growth comes from the scale of the problem — as with eBPF, where instead of a virtual machine in the kernel the packet filter was extended and the technology pushed through a performance expert at Netflix. The guest's closing advice: no growth happens in the comfort zone, and the illusion of being superhuman is cured by a hard schedule for work, study and family.