Episode Materials: What a CTO Has to Relearn in a New Industry — a Conversation with Fyodor Sukharev (Category #Leadership)
I’ve collected the materials from my conversation with Fyodor Sukharev, former Head of Solutions at Arrival and Head of Technology at QIC Digital Hub. The Code of Leadership livestream took place on September 23, 2026. Fyodor’s background spans billing at CBOSS and Orange, the OTC.ru electronic trading platform, electric vehicles, and insurance. In the announcement, I wrote that what interested me most was how the very meaning of “the product is ready” changes with such moves. The answer turned out to be concrete: what carries over is the way you work through a problem, while the solution has to be chosen anew each time.
We discussed many interesting subjects. Here is what Fyodor described
1️⃣ A familiar solution versus the economics At Orange, the first impulse was to buy a billing system he already knew, but a cost calculation tipped the decision toward rebuilding the in-house system. Along the way came version control, Jira, and restrictions on developers working directly in production.
2️⃣ Alpha, beta, and gamma for a car At Arrival, the unit of planning became a feature that spans several systems. Alpha is a working prototype: a developer takes a laptop to the vehicle and does not leave until the new piece of hardware works. Beta brings in testing with lenient bug thresholds, and gamma means readiness for operation. Integration therefore starts with the first iteration rather than once every team has finished its own part.
3️⃣ Requirements that stay in sync with tests. Four levels—business, feature, system, component—while Polarion, after a requirement changes, highlights the links where tests need to be rechecked. Separating hardware drivers from the shared control logic helped when priorities shifted from a bus to a van.
4️⃣ What counts as a product in the first place At QIC, the approach was trimmed to three levels, but several months went into the vocabulary: “product” was used for monitoring, the move to Google Cloud, and the mobile app alike. In return, systems without owners surfaced—security kept finding vulnerabilities in them, and nobody was there to fix them.
5️⃣ Microservices for a specific reason Policy pricing, document generation, and validation were moved into Go services out of a monolith developed by another company in the group. Fyodor stresses that the choice was justified by dependence on someone else’s pace of change; he does not treat it as a universal recipe.
Fyodor also ran a mini quiz on where engineering practices came from. On code review, I didn’t quite get it right :) I guessed a doctor’s second opinion, and Fyodor pointed to its industrial roots—Michael Fagan’s formal inspections at IBM in 1976. From there, we discussed how review can serve different goals: finding defects, getting to know the system, keeping the code consistent. If a team cannot name its own goal, review easily turns into a cargo cult.
And there is an honest part about the limits of engineering influence. According to Fyodor, Arrival ran out of funding before reaching production, and at QIC budget cuts stopped some of the projects. Well-coordinated engineering does not, by itself, guarantee that the business survives.
Episode materials 📌 Episode page with timestamps 🎬 YouTube, VK Video 🎧 Podster, Yandex Music, Apple Podcasts 📝 Text recap
If you have moved into a new industry, tell us: what from your past experience proved useful right away, and which familiar solution did you have to give up?
#CodeOfLeadership #Leadership #Management #Career #Architecture #Engineering