How I Work

I work from the problem to solve, not from a solution decided in advance.

Whether I’m working on a focused backend engagement or as a Fractional CTO, I follow the same approach: understand the context, make decisions explicit, get to a useful outcome, and leave the team able to carry on.

Understand before proposing¶

I start by understanding what is driving the need to act: the problem you’re facing, its impact, what has already been tried, and the constraints we need to work within. The goal is also to define what should have changed by the end of my engagement.

I don’t assume a backend problem calls for a rewrite, that Go is necessarily the right answer, or that a team needs a Fractional CTO.

Know where you’re going¶

For a backend engagement, we define the expected outcome, the scope of the work, and the conditions that will let us call it done.

I prefer working this way to simply selling a number of days: the time required is mine to manage, while the agreed outcome is our shared point of reference.

A Fractional CTO role works differently: I reserve capacity over time to carry an ongoing technical leadership responsibility. Structural decisions around architecture and organization need follow-through, adjustment, and continuity.

Working with the team¶

Technical problems are rarely only technical. So I work with the people who hold the context that matters: developers, product, SRE/operations, leadership, or internal users, depending on the topic.

I favor direct communication, explicit decisions, and as little ceremony as possible. I work remotely by default, with on-site time when it adds value: kicking off an engagement, workshops, working sessions with the team, or important decisions.

Over seven years at Molotov, as I moved from backend engineer to tech lead and then Engineering Manager, two things stood out to me: strong relationships between teams and sustained attention to developer experience. They are less visible than an architecture decision, but they matter enormously when both systems and organizations have to evolve over time.

Start from the problem, not the tool¶

My core expertise is in Go, backend systems, infrastructure, and production, but I don’t start from the assumption that your problem needs any of them.

I’ve seen generative AI tools introduced very broadly before the problem they were meant to solve was clearly identified. The outcome did not justify the effort involved. Since then, I’ve kept the same rule: start with the problem, then choose the tool.

I use generative AI when it provides a meaningful benefit, within the client’s security and confidentiality constraints. If the context requires working without it, I work without it.

The tool should serve the problem, not dictate it.

Seeing it through, then handing over¶

On a delivery engagement, my work doesn’t stop at a recommendation or at code: depending on the topic, that may mean investigating, building, evolving an existing system, and verifying the outcome in production. My aim is to get to an outcome that is genuinely usable in practice.

Finally, I’m not trying to become the only person who understands what was built or decided: important decisions should be explainable and documented, the system should have been tested under real production conditions, and the team should be able to take it forward.