Ownership Before Title

On our Business Accounts platform at Xsolla, several applications shared similar code, but keeping that code compatible as each application changed was becoming difficult. Moving it into versioned packages gave us a clearer way forward. Getting teams to adopt those packages was a separate piece of work.

That experience made ownership more concrete for me. The responsibility extended beyond implementing a solution to helping other people use and maintain it.

I had encountered a similar lesson in project engineering: completing an installation did not necessarily mean the next team could proceed. Dependencies, coordination, and handoffs still mattered. In software, those concerns took a different form.

Start by making the problem clear

Platform work brought questions that crossed application boundaries: how teams share behaviour, organise authentication, release shared code, and investigate production failures.

Those questions often arrive before there is a well-defined implementation task. My first contribution is usually to write down the problem, constraints, options, and decisions we need to make.

Then I break the work into deliverable pieces, agree responsibilities with the people involved, and document the reasoning. An architecture note or migration guide gives teammates enough context to make decisions without repeatedly returning to the same conversation.

The plan is a starting point. As implementation exposes new constraints, I expect us to revisit it. What matters is that the team can see what we believe, why we believe it, and what still needs an answer.

Stay with the problem through adoption

I raised the compatibility concern early. When I returned to the platform work and saw the issue creating friction, I asked to take ownership of addressing it.

I designed an approach around versioned shared packages and clearer platform boundaries. I documented the proposal, discussed it with engineers across locations, worked through their concerns, and helped align the team on a direction. I then drove the migration of shared functionality into packages that applications could adopt by version.

That established a clearer mechanism for evolving shared code. It did not mean every application had adopted the packages or that compatibility no longer required work. By September 2026, six business accounts were live against a broader plan of approximately 25; shared-library adoption was still in progress. Those are platform figures, not a count of migrated SDK consumers.

There was also a trade-off in what we shared. Publishing pages that looked universal reduced copying, but meant a product UI fix could depend on a platform release. The next direction was to keep shared contracts and capabilities in the library, while giving products more ownership of their pages.

That was a useful reminder: removing one bottleneck can create another. A cleaner package structure still needs to work for the teams using it. Helping them integrate and upgrade is part of the work, as is revisiting a boundary that gets in their way.

The Business Accounts project covers my scope and the adoption status. I go deeper into the technical approach in Stop AI-syncing the starter.

Create room for other people to lead

For roughly six months, there was a gap between tech leads on my team. My official title remained the same, while I took on planning, technical direction, coordination, reviews, and helping teammates move through blockers.

A useful contribution during that period was often a clear plan, a resolved dependency, or a decision that let another engineer continue.

I also learned to distinguish taking responsibility from becoming the point through which every detail must pass. If a teammate needs me for every implementation decision, I look for missing context, unclear boundaries, or an opportunity to delegate more effectively.

Mentoring junior engineers and five Xsolla School graduates reinforced that lesson. My aim is to give people a clear area to own, enough support to make progress, and room to develop their own judgment.

Follow the evidence beyond your own code

Production work is another place where ownership becomes concrete. A merged change can still leave a user with an unreliable experience.

On the platform, I took responsibility for frontend and backend observability using Datadog RUM and OpenTelemetry. In support investigations, I followed errors through backend spans when the evidence pointed beyond the frontend, helping identify infrastructure or database issues for the teams responsible.

Following an investigation across boundaries does not mean taking over another team's service. It means collecting enough evidence to make the handoff useful: what failed, where the trace leads, and what needs checking next.

That is a practical way to keep the user’s problem in view while respecting who owns each system.

Make the useful path easier to follow

Working on a shared platform also changed how I think about developer experience. Documentation is necessary, but repeated setup steps are an opportunity to improve the platform itself.

I worked on tooling for scaffolding business accounts, validating configuration, generating common structures, setting up localisation, and guiding upgrades and migrations. Encoding those steps helps teams avoid rediscovering the same requirements each time they start or update an application.

The same principle applies to communication. A migration creates work for other teams, so its purpose, assumptions, and trade-offs need to be visible. I want engineers who will live with a decision to be able to challenge it before it becomes expensive to change.

A habit I want to keep building

Before committing to a solution, I try to ask a few questions:

• Who needs this, and what problem are we solving?
• What would a useful outcome look like?
• What can fail, and how will we notice?
• Who will maintain it after release?
• Can another engineer understand the decisions later?

I still find these questions useful for both small fixes and platform work. They bring the discussion back to who will use the result, what they need, and what remains unresolved after the code is merged.