Why Leaders Return to Coding

Nikita grew up around engineering: his father assembled computers, the family had a Spectrum, and mathematics and computer graphics later showed him a direct connection between his own actions and a visible result. Graphics led him into mobile development. His first interest in leadership came from wanting autonomy and believing he knew best. When a second programmer joins a project that previously had only one, the first can become a technical lead almost automatically; he now considers that early move premature. Later, in Berlin, he told a new manager that he wanted the manager's job. Rather than ending the conversation, the manager pointed out a lack of self-awareness and suggested asking colleagues whether they wanted him as their leader. Honest feedback and help from HR changed how he understood his behavior. He added a daily BeKind reminder to his calendar: pause, breathe, and then speak. Helping others grow became a reason to lead, including people with whom he had difficult relationships.

Initially, Nikita trusted employees, explained a direction, and expected them to ask for help when necessary. Following through on outcomes was the weakness: the same freedom did not suit everyone. A beginner needs guidance and support, while an experienced, self-directed engineer needs room to make decisions. Polomodov describes situational leadership as adapting the interaction to the person and circumstances. The distinction became concrete at Playrix, where Nikita took responsibility for the technical side of Gardenscapes and reorganized a large technical group around different missions. Engineers working on low-level optimization could find valuable problems themselves; they needed help removing obstacles and resolving conflicts. The team handling quality, releases, and CI/CD needed rotations, processes, and fast triage of incoming bugs. One job title therefore covered very different modes of leadership. Nikita measures the role through responsibility taken off other people's shoulders: if delegated problems constantly require leadership to intervene again, the responsibility has not yet been fully absorbed.

An early signal from language models came at AutoScout24, when an early version of ChatGPT found a bug an engineer had spent hours trying to locate. Scripts and internal tools followed. At Playrix, adoption became a management project: teams moved to Cursor and recorded the results of their attempts in Asana to understand where work actually became faster. Some of the strongest programmers adopted the tools later than others. Nikita attributes this to their high baseline: if an engineer spends a long time thinking through a difficult problem and writes the code quickly, faster code generation changes little. Automated bug triage offered a more substantial opportunity. Working with an engineer, he designed a system and encountered invented answers, unpredictable quality, and slow processing. It became usable when they constrained the uncertainty through a state graph, connected the stages to tools, and ran them in an isolated cloud environment. The project demonstrated both what agents could achieve and how much control they required; the initial idea alone was insufficient for dependable operation.

A personal turning point came when Gemini in Firebase Studio began building a website for Nikita's collection of stories. He saw a product emerge without the familiar amount of manual effort. That raised a practical question: how could he lead these teams without even understanding their new problems? Returning to engineering became a way to update his own model of software production. After completing a transformation at Playrix, he agreed to leave, stopped pursuing management roles, and explored independent consulting. Bluefish offered a new domain and responsibility for adopting AI in the development process. His management experience still mattered: finding the owner of a subsystem, asking for help, fixing a bug quickly, and aligning on the next change. He distinguishes his prediction about fewer management layers from an established fact. Smaller autonomous teams might need fewer managers, but he does not present this as the inevitable design of every company. Prioritization, focus, and leadership remain valuable in his view.

Bluefish serves large enterprise clients, so its development process must reflect trust, contractual obligations, and responsibility for data. A client needs an understandable process and a named person who will resolve problems. Engineers remain personally accountable for changes to the core system; a model's suggestion does not remove that obligation. Meanwhile, client-facing employees build their own tools with Claude. Banning experimentation would leave them with the same workload, while eliminating the employees could undermine relationships clients are paying for. Nikita proposed shared infrastructure: a repository, quality criteria, security checks, and checks against requirements. The engineering organization is also working toward common criteria for agent design and self-review. An autonomous workflow already handles small Jira tasks through an SQS queue: it validates inputs, builds a plan with postconditions, implements the change, and opens a pull request. Its scope is minor bugs and technical debt. The engineering manager still decides whether a task should be done.

Autonomy also runs into the economics of verification. The client team had accumulated roughly sixty tools without sufficient descriptions, tests, or behavioral checks. Nikita brought them into a repository and used an agent to add the missing structure. It produced more pull requests than he could review carefully; his personal capacity was about five or six a day. Adding a Codex review agent helped, but individual correction loops reached sixty iterations. Once the accumulated tools had been processed, he disabled that naive workflow. Subsequent systems need limits on spending, elapsed time, and repeated reviews. Before selecting a model, he asks which smallest adequate model can do the job and whether a model is needed at all. His closing advice is for engineers to consciously take responsibility for product outcomes and for managers to understand systems deeply. Polomodov adds a condition: technical investigation needs an appropriate communication style, so better questions and new understanding do not turn into micromanagement.