How an Engineer Learns to Reach Agreement

Sergey started building infrastructure as a student: he automated coursework, joined a company run by his lecturer, and became its director in 2006. The team grew from roughly ten to twenty people, building a learning management system, websites, and business applications in Java while also supporting servers. Conferences introduced him to stronger specialists and more demanding problems. Feeling that he had reached a technical and organisational ceiling, he moved to St Petersburg. Rather than continuing directly in management, he took a lead engineering position on a project for the medical laboratory company Invitro, giving himself time to relocate his family. Yet his management experience remained visible: he began organising the work around him and effectively became the technical lead. Returning to code did not erase his ability to take responsibility and bring a shared effort to completion.

He joined Yandex as an engineer in 2013, building systems to evaluate search quality: collecting metrics, running evaluation pipelines, and eventually launching test search systems. These had to start quickly, fit limited resources, and leave production search undisturbed. His next move followed a company strategy change. Fragmented infrastructure needed consolidation, first into an internal cloud and then into a public offering. At Yandex Cloud, Sergey launched services including a container image registry and demonstrated how they worked with Kubernetes. Customers wanted a working scenario, not a technology in isolation. That also placed a limit on perfectionism: the useful target was a level of quality worth paying for. He applies a similar test to management. Build a team that can operate without you, and be willing to hand it to another part of the organisation instead of keeping every decision dependent on yourself.

In 2023, MTS Web Services invited Sergey to turn his internal infrastructure experience into a dedicated development platform team for a new cloud. He spent the first six months assembling its core. Writing the initial code himself was possible, but scaling required people he could rely on. Hiring then became a shared capability: he designed interview tasks, conducted the first interviews, trained colleagues, and built an interviewer community alongside recruiters. His target was five working days from first contact to an accepted offer, which the team achieved in some cases. This process served other teams as well as his own. Platform engineering also happened alongside product work. His engineers joined product teams to help build control systems, using those concrete problems to develop and test shared tools. A solved problem made the platform’s value visible.

Sergey describes four areas: foundational Go code, Kotlin tooling for control systems, service deployment, and a common API. The last includes OpenAPI conventions, generation, and access gateways, not merely libraries. Product engineering leads meet to discuss what their teams need. Separate conversations involve the teams responsible for Kubernetes, identity and access management, observability, and CI/CD. Not all of these teams report to Sergey, so technical building blocks alone cannot create shared rules. Acceptance requires understanding colleagues and talking before decisions land. Meanwhile, the business cares about delivery dates and satisfied users rather than deployment internals. Infrastructure needs dedicated people and clear responsibility, even when those people must resolve the technical details independently. Hiding the cost of compromises creates another problem: technical debt makes each new feature more expensive, while the business keeps expecting the old pace because nobody has explained what changed.

Incident response illustrates the need for shared responsibility. The cloud has an on-call leader in the duty CTO role, checking that problems are resolved promptly and properly and that users receive updates. Excellent engineering work cannot reassure a customer who sees only silence. Product teams handle their own components, while team leads must spread knowledge so that one person’s holiday does not prevent recovery. Teaching everyone everything would be too expensive; a shared platform and consistent deployment processes reduce the specialist knowledge needed for support. Recovery must be followed by a timeline, an explanation of causes, and concrete preventive actions. Important incidents receive an additional review. A promise to pay more attention next time is not a preventive measure. Alexander adds that managers must revisit follow-up tasks: a recorded fix can remain on the backlog for months or be closed without resolving the original problem.

With AI agents, agreements become another platform interface. Sergey’s team exposes its Markdown documentation through MCP and turns coding and deployment practices into agent instructions. He favours integration points and observing how engineers use new tools. Data boundaries still apply: some customer information must never leave the company. Generated code does not replace the organisation needed to maintain it; both speakers reject the scenario in which a manager hands the team something they generated and demands ongoing support. Sergey closes by suggesting that managers also study the team as a system: collect information about its work, understand neighbouring teams, and prepare for conversations with them. When an internal product goes unused, first examine the users’ circumstances, decision makers, and incentives. Alexander frames the management task as building the team that can build the product, then paying attention to its health.