Leading in an Unfamiliar Field — Leonid Chernyy

Leonid’s career developed around curiosity about unfamiliar work. While employed as a system administrator at the Academy of Sciences, he found part-time work testing applications for Cybiko handheld computers through people he knew. Payment for discovered bugs led to a staff position and responsibility for a group of testers. His area included the SDK, although his previous understanding of software came primarily from the user’s side. He had to ask developers how the product worked and what needed checking. This established a recurring approach to entering a new field: build on a familiar part of the work, acknowledge gaps, and learn from nearby specialists. Professional connections opened the door, but usefulness in the new job still had to be demonstrated.

At Nival, that experience helped him organize game testing. In his account, developers, designers, and artists had previously performed checks themselves. Leonid worked on Silent Storm while a colleague took Blitzkrieg; the initial testing groups included school and university students working part-time. After roughly two months, he was asked to take responsibility for testing processes across the company. He pictured the desired outcome and worked backward to identify steps toward it. The eventual result differed from the original picture but became a functioning system. Later, in release management, similar skills supported coordination between development teams and publishers: explain the expected output, assess deliveries against clear criteria, and give substantive feedback when the result falls short. A new role needs a working system around it. Appointing a manager is insufficient without shared expectations, ways to assess results, and someone responsible for maintaining those agreements.

International publishing introduced constraints absent from the familiar market. Launching Allods Online in Japan and South Korea meant working through intermediaries and responding to local requirements for the product itself. Korean partners wanted the game’s world and mechanics adapted to cultural references their audience understood. In Japan, Leonid recalls having to change the economics of in-game prize chests. Local requirements therefore affected the game’s economics as well as its presentation. Knowing how to release a game did not establish how another country’s audience would receive it. Localization extended beyond translating text into content, coordination, and commercial design. The management task was to discover which earlier decisions remained useful and which needed reconsideration with local partners.

At Yandex, the unfamiliar element was the technology and the product itself. After eleven years in games, Leonid had to learn about search, user intent, and connections between services. The query “pizza” illustrates the challenge: one word can express a wish to order food, buy it, or cook it. Yet understanding intent and returning relevant results does not guarantee adoption. He recalls comparing search results with people in a Turkish café: participants preferred Yandex’s unbranded answers but then saw no reason to leave their familiar Google search. Better internal metrics did not offer enough perceived benefit to change a habit. The speakers also discuss the opposite constraint: adding services to an ecosystem can obscure its central use case. Later, relaunching Rambler Top 100 connected Leonid’s product experience with behavioral data and advertising infrastructure. This created an interest in data, but did not provide ready answers for managing enterprise warehousing and machine learning in telecom.

At MegaFon, Leonid joined an established team responsible for a data warehouse, machine learning, data quality, and data architecture. He describes three initial priorities: build personal relationships, learn the subject, and teach people to disagree with him. In his view, a specialist who sees a manager making a mistake has a responsibility to raise the concern before the decision, rather than after a failure. Discussion still has a boundary: after hearing the arguments, the manager chooses a course and takes responsibility for execution. Making that possible requires changing habits in a hierarchical environment. Leonid argues that managers can shape their department’s culture even without controlling the whole company, while shielding their team from outside pressure. Alexander adds a limit from his own experience: when a protective manager moves on, employees may encounter organizational politics and rules they were previously insulated from. Protection should therefore coexist with preparing people to operate independently beyond the team.

A separate risk for a chief data officer is the gap between responsibility and authority. Leonid observes that companies use the CDO title for markedly different functions: policies, warehouse development, commercial machine-learning applications, or responsibilities shared across several people. The title does not establish which decisions its holder can influence or how the expected result will be achieved. He therefore asks specifically about authority during interviews. Moving to oneFactor brought more process work, while Uzum offered the chance to help build a large business at an early stage. He describes Uzum’s approach as moving from e-commerce toward financial services and connects the appeal of that work with building something new. At the time of the conversation, he mainly consults and is considering a return to consumer products at the intersection with data. His closing advice returns to management fundamentals: relationships and professional connections matter, and difficult decisions cannot be postponed indefinitely. A knowledge gap can gradually be closed; refusing responsibility undermines the purpose of the role.