Growth starts with trust: An interview with Vlad, Deputy VP

Junior. Middle. Senior. Lead. Head.

That’s usually how career stories are told: through job titles and new lines on a LinkedIn profile. But Vlad’s story doesn’t quite fit that pattern. His journey is about something else: the moments when you're trusted with a little more than you were yesterday. Your first team. Your first product area. Your first decisions that impact not just your own work, but the work of dozens of other people.

We spoke with Vlad about trust, growth, and why, five years later, he still genuinely enjoys what he does.

By the time I came across 01.tech, I had already spent years in iGaming. I had solid experience and offers from several major companies.

But the decision turned out to be surprisingly easy. After interviewing with 01.tech, I knew this was where I wanted to be. I turned down the other offers almost immediately, without giving it much thought.

The conversation itself.

The questions, the way people communicated, the topics we discussed. It was obvious that they knew exactly what they were talking about and genuinely cared about what they were building.

We talked about real challenges, not abstract scenarios. Nobody tried to oversell anything or paint an unrealistic picture. After that conversation, there really wasn't much left to think about.

It actually exceeded them.

I could see the company had a system that actually worked, and that was genuinely compelling. But what really hooked me were the technical challenges: interesting architecture, meaningful scale, the kind of work where there's always room to grow and where what you build actually makes a difference. And the company was already a serious operation by the time I joined, but it still had that startup feel.

Those were probably the most intense years of my career. I joined as a Senior Node.js Developer. After successfully delivering a few projects, I was entrusted with a system that needed significant improvement. It was one of the most challenging areas of the product, and I got the opportunity to take ownership of it and drive it forward.

You could say that's when I accidentally became a Team Lead. I started rewriting the system module by module rather than all at once. Some parts made it into production fairly quickly. As I got deeper into the project, it became obvious that there was far more work than one person could handle.

That's when I started building a team.

That project became a major turning point for me. More teams followed. Each team owned a different part of the product. Eventually, I found myself responsible for the entire product as its CTO.

Later, when I moved into the Deputy VP role, additional product areas were added to my scope. Today, I oversee several product directions at once.

It wasn't a sudden decision where I thought, "That's it, I'm moving into management."

Over time, I simply realized: as an engineer, you're ultimately limited by your own time and capacity. You can be an exceptional developer, but eventually you'll hit the ceiling of what one person can accomplish. As a leader, however, you start influencing the system itself and that ceiling disappears. One well-designed process or one great team can create more impact than a hundred personal commits.

Your perspective shifts. I used to think, "How do I solve this problem?" Now I think, "How do we build a team that can solve problems like this without me?"

Over the years, my teams rewrote major parts of the backend, supported the company through multiple stages of growth, and built numerous internal systems. But for me, the most valuable part wasn't the technology itself. It was that shift in mindset.

Balance.

I care about how teams operate, whether people are burning out, whether they have enough resources, where we're losing momentum, and why.

You learn to make decisions that won't pay off tomorrow, but a year from now. You learn when it's worth investing in architecture today and when technical debt can be intentionally left alone to avoid slowing down the product.

The hardest part is finding balance between speed and stability, between giving people enough freedom to make mistakes and grow, while making sure the product remains reliable.

At the same time, my interest in technology never disappeared. In fact, I have a personal rule: before introducing or approving a technology for our teams, I first make sure I understand it myself. That's the only way to properly evaluate what we're gaining and what we're paying for. Leadership decisions are simply too expensive to make blindly.

For me, growth has always been driven by people.

You can read articles, watch conference talks, and learn new technologies on your own. But the environment around you determines the pace at which you grow.

One of my favorite things is our tech talks. People come in and share things they've actually built. They showcase interesting solutions, talk about discoveries they've made, and explain what they've learned along the way. There's always something valuable to take away.

That's also how I've developed skills that no single course or book could teach: building teams, creating processes, communicating with the business side, developing roadmaps, and balancing technological progress with product stability.

Very realistic.

It starts with onboarding. New hires aren't left alone to figure everything out. There's a structured onboarding process supported by HR and regular feedback sessions where people can openly discuss what's working and what isn't.

From there, growth is supported by specific tools: individual development plans, performance reviews, and honest conversations about strengths and growth opportunities.

Helping each other and sharing knowledge is part of the culture here. People aren't left to figure out their growth on their own. There's always someone willing to help, guide, or point them in the right direction.

I'm grateful to the company for gradually giving me more and more responsibility. For me, that has always been the biggest source of motivation. When you know people believe in you, you naturally want to do more and keep proving that trust was well placed. You clear one bar, and another one appears. It keeps you moving forward.

Over time, I also realized that trust matters in both directions. I like being the kind of person people can come to with a problem and know with complete confidence that I'll help solve it.

That doesn't come from a title. It comes from the reputation you build day after day.

Not really.

I regularly review metrics, logs, architectural decisions, and deployment processes. I don't want to lose touch with what developers are actually dealing with. And whenever I get the chance, I still enjoy sitting down and writing code myself. I genuinely love it.

And honestly, we think that's exactly why people choose the places where they want to build their careers.

Not because of impressive titles or another line on a resume, but because of the people around them, the challenges that keep them engaged, and the feeling that they're exactly where they're supposed to be.

If that's what you're looking for, take a look at our open positions!