About

Welcome, I'm Maxim.

I have spent most of my career working in technology, but over time I became increasingly interested in what happens around the technology and how decisions are made.

Questions I regularly ask myself include:

1) Why a technically strong team can still move slowly

2) Why a product that works well can fail to find its market

3) Why adding more people sometimes makes an organisation less capable rather than more capable

4) Why a company can have good engineers, good managers and a clear strategy, and still struggle to turn all of that into consistent results.

These questions have shaped the way I work.

I started as an engineer. I worked close to operating systems, security, low-level software and infrastructure. Later I architected, built products, managed engineering organisations and worked as a CTO, CPO, and worn many hats in between.

The technical depth still matters to me. I like being able to understand how a system actually works rather than relying entirely on abstractions or reports from other people. But technology itself is rarely the most interesting part of the situation.

Technology is a part of a larger system

A technical decision changes a product. A product decision changes a business. An organisational decision changes what a team is capable of building.

What changes all the above how leaders distribute information, authority and responsibility. This is why I find it difficult to separate technology from the organisation around it.

A system may require a different architecture, but sometimes the reason the architecture has become difficult to change is that nobody has a clear ownership.

A team may have an execution issue. But the underlying cause may be that decisions are constantly escalated and people have learned to wait for permission.

A company believes they need more engineers. But the actual limitation may be unclear priorities, too many parallel initiatives or a structure where nobody can make a complete decision.

These are different situations, even if they initially produce similar symptoms. I am interested in understanding which one I am looking at.

I care about how decisions travel through an organisation

One of the recurring themes in my work has been decision-making.

Small teams can make decisions informally. Everyone knows what is happening and information travels quickly.

As organisations grow, that stops working and leadership becomes less about making good decisions personally and more about building a system in which good decisions can be made without leaders.

That distinction matters to me. I do not think strong leadership means being involved in every important action. I think it means creating enough context, boundaries and trust that other people can act independently.

Responsibility grows gradually. People need room to make decisions, including decisions that are different from the ones I would make myself.

The important question is whether those decisions stay within the goals and constraints that were made clear in advance.

A mature organisation should not depend on a leader continuously supplying judgement to it. If removing one person causes the system to stop, the system has not really scaled.

Teams are systems too

I have built and changed teams in very different environments and over time I became less interested in evaluating people only by their current skills.

Skills can be developed. What matters much more is whether someone wants to grow, learn and participate in the change that the organisation requires.

There is a meaningful difference between someone who does not yet know how to do something and someone who does not want to move in that direction. Recognising that difference is one of the harder parts of leadership.

Good teams need clarity about what they are trying to achieve, enough information to make decisions and real ownership of the outcome. Without those things, even very capable people become execution resources and

with them, a team can become significantly more capable than its formal structure might suggest.

I like situations where the answer is not obvious

Much of my career has involved entering situations where there was already a system, a product, a team and a history behind them. The challenge was rarely to invent everything from scratch (however, suppressing intention to do so): much more often it was to understand what is really limiting.

Sometimes it was architecture, sometimes - reliability or security, product direction, team structure, decision making. But quite often several of these things were connected.

I enjoy this kind of work because it requires moving between levels, and I am comfortable doing so levels because I have spent substantial parts of my career working at each of them.

Building is different from operating

There is also a particular kind of work I have always been drawn to: moments of transition.

A product is growing beyond the architecture that supported its early stage. A company is moving from experimentation toward repeatability. A founder needs other people to begin making decisions that previously depended on them.

These transitions are difficult because the practices that helped a company reach one stage are often exactly the practices that limit it at the next one. Usually the harder task is deciding where structure is necessary, where autonomy is more valuable and which decisions must remain close to the people doing the work.

I still like building things

Despite spending many years in leadership roles, I have never wanted to become completely detached from engineering.

I still enjoy technical research, architecture, security and building prototypes. Part of this is simply curiosity while the other part is practical. Remaining close to technology makes it easier to distinguish between something that is genuinely difficult and something that has merely become difficult because of the way the organisation approaches it.

It also keeps my conversations with engineers concrete. I do not think a technology leader has to be the strongest engineer in the room. In a healthy organisation, they probably should not be.

But I do think it is useful to understand the material we are working with.

What I am interested in now

Today I am most interested in work where technology is connected with questions of product, organisation and leadership, because the most consequential decisions often happen at the boundaries between these areas.

How much should we build before testing the market?

Which parts of the architecture actually limit the business?

Where should decisions be decentralised?

What exactly should a leader still control?

Which constraints are real, and which ones exist only because the organisation has become used to them?

When should a team be given more resources, and when does it first need a clearer direction?

These are the questions I tend to spend time on.

I never worked on a universal framework that produces the same answer for every company. Different organisations will need different structures, different teams need different levels of autonomy and different stages of a product require different trade-offs.

What I bring is the ability to understand the system as a whole, identify what is actually constraining it and make the next decision clearer.

That has been the common thread through most of my work, even when the technologies, companies and roles were completely different.