About

A short account of how I got here, and what I have learned to pay attention to.

Most of what I know about engineering, architecture, and leadership, I taught myself by doing the work and paying attention to what happened. I grew up in a family that did not start from a position of stability. There were stretches when the basics were not a given, and the habit of staying calm when things broke was not a personal virtue so much as a baseline condition. I carry that habit still. When a company loses funding, when a startup collapses, when a restructuring produces a layoff — each of which has happened in my career — the question I reach for first is not how I feel about it but what we do now. That is not performance. It is the shape of a childhood applied to a career.

How I think

A few convictions I have come to hold strongly. Developers are people before they are resources, and organizations that forget this pay for it eventually — usually in retention, sometimes in outright collapse. Architecture should be honest about what it actually does, rather than about what the diagram claims it does; the gap between those two is where most late-stage problems live. Process is a tool, not a religion, and the moment an organization is spending more energy on process than on work, the signal-to-noise ratio has already collapsed. Technical leadership detached from the codebase drifts quickly into politics, regardless of intent. I try to stay close enough to the work that my opinions have ground underneath them.

I have not stayed in any single industry long enough to become a specialist in that industry specifically. I have worked in adtech in Paris and Moscow, chat-commerce in Tokyo, cloud infrastructure in Hannover, geospatial SaaS in Paris, mobile AI commerce in Nice, and cross-border payments in Luxembourg. Each time I entered a new domain knowing very little about it, and each time what I found was the same thing: the surface changes dramatically between industries, but the underlying work — designing teams, establishing delivery rhythm, recognizing when an architecture has begun to lie to the organization that built it — is almost identical everywhere. That observation is the core of nearly everything else I have come to think about this field.

At the moment I am leading a fifty-five-person delivery organization on a confidential cross-border payments program. In parallel, I build open-source tools for the AI era — Approva, Rhodd, and Codencer — each of which came out of a specific friction I hit often enough to stop ignoring. I co-founded an adtech startup for Telegram Mini Apps, Nygma Ads, where I lead the engineering side of the product. I mentor engineers and leaders on h.careers, partly because I believe the transparency problem in career growth is real and partly because helping other people find the map I did not have is something I cannot seem to stop doing. I am finishing a book on that topic. I also play guitar and have a progressive metal project, I read widely, I spend a disproportionate amount of time on things that look unproductive from the outside, and I try not to let any single dimension of the work compress the rest of me.

How I lead

I still write code most weeks. Engineering leadership without technical context turns into a version of management where people are moved around as if they were interchangeable units, which they are not, and where decisions about architecture get made by people who have not actually read the code in months.

I grow engineers deliberately. For example, at Zeals, five engineers on my team advanced into leadership roles during my time there; one eventually became VP of Technology. The mechanisms I use are standard — competency matrices, development plans, regular 1-on-1s, honest feedback — but none of them work without the thing underneath, which is a credible path and the trust that if someone walks it, they will actually get where they are being told they could go.

I design process to help people move, not to give managers something to point at in status meetings. The distinction is small but decisive. An organization running lean Scrum with real retrospectives and honest planning is a very different animal from an organization running ceremonial Scrum where the ritual is the point.

I tend to be most useful when something has drifted — when the architecture no longer fits the business, when the team structure is creating more friction than it resolves, or when everyone looks busy but nothing of consequence is shipping. Those situations are diagnostic problems first and execution problems second, and you cannot fix them by running faster.

What is changing

I have used LLM-based coding agents as part of my daily workflow since early 2023—not as a novelty, but as a core engineering practice. This shift has changed everything: how code reviews work, how architecture is defined, and how trust is assigned between humans and systems.

After a few years in this workflow using tools like GitHub Copilot, Claude Code, and Cursor, it has become obvious that the most interesting problems are no longer in the models themselves. The models are already "good enough." The real challenges are one layer up, in the infrastructure of agency:

Who approves a risky action an agent is about to take?
Who tracks what was actually done versus what was requested?
How does an architecture survive when the ratio of generation-to-review inverts?

Approva, Rhodd, and Codencer are my attempts to answer those questions concretely. They are specific—and in an industry moving this quickly, specificity is the only useful starting point.

What I am not trying to be

01A few things this site is not. It is not a brand exercise, and if it reads that way in places, I have failed at the register I was aiming for.
02I am not optimizing for titles — CTO, VP of Engineering, Head of Engineering are roughly interchangeable to me; the problem, the team, and the question of whether I can make things genuinely better matter much more than the label on the door.
03I have a limited tolerance for process theater and for engineering organizations where the main shipped artifact is a PowerPoint rather than a working system.
04I try to express that disagreement by building better rather than by complaining about worse.

Beyond work

A lot of what I do outside work is not optional, even though it might look that way from the outside. I play guitar and write music for a progressive metal project. I read widely — psychology, strategy, leadership, philosophy, literature, long-form technical essays. I cook and travel when the opportunity arises, and I lift weights because the feedback loop is honest. It is the reason I can still think clearly after sixteen years in a field that tends to compress people into narrower versions of themselves. The industry rewards specialization and continuous availability. I resist both, and I resist them on purpose.

Timeline

Now since 202501

Leading a fifty-five-person delivery organization on a confidential cross-border payments program. Building Approva, Rhodd, and Codencer. Co-founding Nygma Ads. Mentoring on h.careers. Finishing a book on career growth in IT.

202402

Led platform redesign at Echo Analytics in Paris, including a mid-project architectural pivot in response to a budget cut.

202303

Built a B2C mobile app and a B2B cross-platform SDK at YoloPrice in Nice. Started mentoring on h.careers.

202104

Built the software engineering function from scratch at go2cloud in Hannover after the company acquired a French VDI startup.

202105

Led engineering growth at Zeals in Tokyo, from four people to twenty-five across ten countries. US market launch.

202006

Led engineering for a mission-critical banking platform at Sberbank, which generated approximately thirty percent of the department's revenue.

201807

Built the SmartIndex ML analytics platform at OneFactor from zero. First team in the company to ship on Kubernetes.

201108

First product engineering role at Stroyportal — roughly one million monthly active users.

200909

Started freelancing in Volgograd. jQuery, PHP, Django.