How to Build Your Own Management System

Mikhail did not plan his path. He studied materials science and superconductivity, then worked in testing, development, administration, analysis, project management, and led a small company. The business taught him to see the whole operation, but dependence on one client caused a long cash-flow gap and painful departures. After repaying the debt, diversification failed, so in 2013 he chose employment and a new learning environment.

Reputation brought him to Alfa-Bank. Eighteen months earlier, he had recommended three employees; their performance persuaded their manager to find him a role despite having no vacancy. The loyalty project was cancelled three weeks after he joined, while a CRM rollout taught enterprise discipline through prepared workarounds. Moving a cloud loyalty platform on premises later became almost a new build. Mikhail wanted to resign over the loss, but the COO called it bank-funded education, became his mentor, and helped resolve the project. The vendor system ran for about a week before being replaced by the team's parallel build.

Authoritarian leadership helped Mikhail in crises because one person could reduce uncertainty quickly. At director level, it became a ceiling: the organization was bounded by one leader's judgment. His clearest mistake was using preprinted resignation letters to force support for a coordination center. Nobody signed, but everyone was offended. Leaders cannot be ordered to cooperate, and structure cannot simply be announced. They need a shared language for value, dependencies, and work after the change.

After the shift from projects to products, an autonomous team still needed changes across dozens of systems. Putting every capability inside one product created a large, unevenly utilized group, so direction leaders and cross-system coordinators were added above Scrum teams. Domain CTOs took responsibility for technology domains. Mikhail initially celebrated growth from 500 to 1,000 people, but later changed the measure: results with fewer resources matter more. A new team for every change often hides waste, making automation and reusable platforms essential.

Separating product and platform creates a new conflict. Centralization gathers strong engineers but disconnects them from user needs; distribution preserves context but duplicates work. Declaring everyone one team does not resolve the boundary. Mikhail is experimenting with reciprocal benefit: a platform should simplify product delivery, while product teams provide real use cases and contributions. The goal is small, mobile teams testing hypotheses on a common foundation, although the model remains unfinished.

Another boundary separates development from application support. In different verticals, a major incident can fall between responsibilities while each side claims its own system worked. Mikhail wants the CTO to own the outcome regardless of where the technical cause began. CTO Dialogues extend that wider context: peer sessions let leaders compare reality without a marketing façade and avoid known mistakes. Collaboration among technology consumers does not erase product competition, but turns engineering learning into a shared resource.