Code, Cars and Insurance: What a CTO Must Relearn

Fyodor began at MEPhI and through an internship at CBOSS. After an early assignment parsing formulas, he worked on integrating billing systems and deploying the result for overseas operators. A trip to Indonesia turned abstract code into a visible business: call-centre staff, a server room and finance colleagues requesting reports showed him who depended on the software. Building a technical centre in Vietnam brought a different lesson. While hiring people and transferring products into their care, he discovered that his assumptions about motivation did not match theirs. Given a choice of extra pay or additional leave for round-the-clock availability, staff readily chose the money, whereas he had expected the leave to appeal. Even within telecoms, transferring experience required understanding people and working conditions. That distinction recurred throughout his career: experience provides ways to investigate a problem, but cannot supply another company’s answer in advance.

At Orange, which he joined in 2010, a small team faced a long queue of requests from internal customers. He consolidated the work and showed management delivery scenarios with the existing team and with additional developers; the company approved two positions. Billing was the next obstacle to new products. His first instinct was to buy the system he knew, but the cost comparison led the team to rebuild its own. They also introduced version control, Jira and restrictions on developers working directly in production. The roughly nine-month project enabled new commercial offerings. What transferred was knowledge of billing and software delivery; the company’s economics determined the size of the solution. OTC.ru subsequently added experience of growth: two developers, two testers and an external team eventually became an internal technology organisation of more than fifty people.

Fyodor joined Arrival as Head of Solutions, responsible for automotive architects, control software engineers and integration testers. Some engineers came from turbines, aviation and other physical systems. Their MATLAB Simulink models became firmware for hardware the company also designed. Temperature, vibration and electromagnetic interference directly affected the result. The management challenge was to connect these specialists and make the vehicle work as a whole. Planning centred on features that typically crossed several systems, with explicit readiness levels. Alpha produced a working prototype and knowledge about the hardware interaction. Beta introduced testing, with relatively permissive defect thresholds. Gamma meant readiness for production use under stricter quality requirements. Integration therefore happened in an early iteration, followed by improvements in quality. The prototype did not count as a finished product, but revealed whether systems could cooperate before every contributor completed their own part.

Requirements formed four linked levels: business, feature, system and component. Commercial needs and regulatory constraints both supplied inputs; descriptions of acceptance tests helped the team interpret the latter. Feature leads coordinated work across specialties. As the technology organisation grew beyond 650 people, Confluence with a plugin became insufficient, and the team adopted Polarion. Fyodor particularly values its ability to flag links after a requirement changes, prompting checks of related tests, lower-level requirements and consistency with upstream constraints. A shared release plan in Jira gave other teams visibility. If a supplier delayed a component, the dependent feature moved and available engineers could work elsewhere, with the change communicated to everyone. When priorities shifted from the bus to the van, separating hardware-specific drivers from common control logic supported reuse. Engineering coordination nevertheless could not guarantee commercial survival: in Fyodor’s account, Arrival ran out of funding before reaching production, while repeated priority changes dispersed its resources.

Fyodor worked as Head of Technology at QIC Digital Hub from April 2025 to July 2026. Insurance brought unfamiliar domain knowledge but familiar integration and regulatory complexity. The team kept the approach to requirements while reducing the hierarchy to three levels; a separate component level was unnecessary. Agreeing on products and responsibilities proved harder. Different teams used the word product for an observability system, a move to Google Cloud or a mobile app. Fyodor and the analytics lead spent several months clarifying definitions and separating the levels involved. Shared criteria supported decisions to introduce or consolidate products and assign system owners. The exercise also exposed older systems with no responsible team: security staff reported vulnerabilities, but nobody owned the fixes. Clarifying vocabulary thus addressed an operational problem by making responsibilities lost during growth visible again.

The main technical project addressed dependence on a legacy monolith developed by another company within the group. Changes took longer than sales needed. The team therefore chose to extract frequently changing core insurance functions—policy pricing, document generation and validation—into services written in Go, while preserving the necessary integration. Fyodor stresses that microservices suited this particular situation; he does not turn it into a universal prescription. A parallel move to Google Cloud involved commercial negotiations as well as technology. The conversation also returns to the purpose of familiar practices: code review can find defects, spread knowledge or maintain consistency, so a team needs to state its objective first. The end of Fyodor’s time at QIC provides another reminder of external constraints. He attributes budget cuts and paused projects to deteriorating business conditions. Even a considered technology transformation depends on the market and the company’s decisions.