Code, Cars, Insurance: What a CTO Must Relearn — Fyodor Sukharev

Fyodor Sukharev compares moving between telecom, an electronic procurement platform, automotive engineering, and insurance. At CBOSS, implementation trips connected code with the work of a real business. At Orange, that experience helped him create a shared work queue, justify additional hires, and rebuild billing to support new products. Buying the familiar vendor system was too expensive: domain knowledge and ways of organizing work transferred, while the solution needed a fresh decision. OTC.ru then added the experience of scaling an early product and its team.

At Arrival, working software had to prove itself inside a vehicle, where electronics, temperature, vibration, and interactions between systems affected the result. Architects, control software engineers, and integration testers coordinated their work around individual features. Alpha, beta, and gamma maturity levels distinguished a working prototype and newly acquired knowledge from progressively stricter quality checks. The approach separated experimentation, tested functionality, and production readiness while aligning contributions from dependent teams.

Four requirement levels connected business needs, features, systems, and components. Polarion linked requirements to tests and flagged affected relationships when something changed. Feature leads coordinated work across systems, while a shared Jira plan exposed release contents and supplier dependencies. Separating common control logic from hardware-specific drivers helped reuse work when priorities shifted between a bus and a van. A discussion of where engineering practices originated returns to their purpose: even code review should be judged by what it supports, whether quality, consistency, or learning.

At QIC Digital Hub, the same principle needed a simpler structure: three requirement levels were enough. The team agreed on definitions of products and systems and identified systems without owners. Frequently changing insurance functions—policy pricing, document generation, and validation—were selectively extracted from an inherited monolith into Go services. Fyodor stresses that this choice addressed a specific dependency on another team’s pace. The conclusion also marks the limits of engineering influence: financing, market demand, and budget decisions can stop the work. By the time of the conversation, he had left QIC and was open to new opportunities.