Managing engineering teams has always required a careful mix of technical depth and people skills. But as artificial intelligence reshapes how code is created, that equation is changing. Leaders now face new questions. How can they integrate AI tools to improve quality—especially since a recent study found that experienced developers can take 19% longer to complete tasks when using popular AI assistants? How should they grow teams in an era of automation? And how can they prepare young engineers for a future where their work may be handled by machines?
For Mikhail Vaganov, Director of Engineering at Yandex—one of Europe's largest internet companies—these challenges are part of daily reality. Over 13 years, he moved from experimenting with Node.js as a front-end engineer to leading major infrastructure projects. During that time, he also grew his team from 60 to 130 professionals. In this interview, he reflects on his journey, shares his management philosophy, and explains where AI is already helping developers—and where it still falls short.
— You've been with Yandex for around 13 years. How did your journey begin?
— I joined Yandex 13 years ago as a frontend engineer. I landed in a fantastic team and spent the first couple of years building up my experience—learning frameworks, understanding how business processes worked, and sharpening my technical skills. One of the most memorable projects at that time was migrating the frontend of Yandex's real estate classified to Node.js. Back then, it was a brand-new, promising technology. The whole IT industry was looking for fresh approaches but hadn't yet figured out how to apply them.
We decided to take the leap and make a strategic bet on innovation. Today, frontend developers have countless frameworks at their disposal—and even AI tools to help with coding. But at that time, there were no ready-made solutions. We had to build everything ourselves from scratch.
That experience paid off: we cut the time-to-market for new features and gained a first-mover advantage in modern web architecture. It also helped with hiring—young specialists were eager to work on cutting-edge technologies, and our project proved Yandex was the place to do it.
I was one of the lead developers on that project, and it really set the tone for the rest of my career. It taught me to look at technology and its potential with optimism.
— What led you from frontend into infrastructure?
— After a couple of years, I began thinking about my next step and decided to grow professionally in infrastructure. Unlike frontend, it requires deep technical expertise. You're not only designing high-load microservices, but also operating them yourself—setting up logging, alerts, and monitoring. To do it well, you need a full understanding of how the cloud works.
Eventually, I started leading a group responsible for part of the Yandex Search runtime. Under my leadership, the team expanded its scope and took on more critical projects. One milestone was a microservice we built to support the entire Search frontend. It proved so reliable, fast, and convenient that it was scaled across other solutions of the company.
Manually maintaining dozens of such services was grueling. Developers ended up waking up at night to fix issues. Naturally, we started asking: "How can we automate this?" In the end, we wrote an infrastructure layer for configuration management. And this was done by just five people. With such a small group, we went from building a microservice for one team to delivering instances of it to twenty.
— How did that path ultimately bring you to your current role as Director of Engineering, and what does the job involve today?
— I've never been someone who sits still—I'm always looking for ways to improve. My higher-ups noticed that and supported me. I moved from team lead to manager, and direct reports weren't writing code anymore; they were overseeing other people. So my focus shifted from technical expertise to leadership. From there, I kept growing "by inertia" until I reached the Director of Engineering role.
Today, I'm responsible for four major areas. First, the technology stack behind a product that enables other companies to process transactions, including backend, frontend, and SDK. Second, the IT infrastructure for the solution that connects businesses to Yandex's fiscal data operator. Third, the frontend of Yandex's internal payment system, one of our core products. And finally, I focus on enhancing the developer experience and integrating AI into workflows.
Over the past year, my team has grown from 60 to more than 130 people, with expertise spanning backend, frontend, mobile, testing, and operations. I believe a good engineer should be able to dive into any of these areas, and that's a principle I try to instill in my colleagues. As a result, we've built "star squads" that can take on any project the company needs and deliver.
— What helped you scale your team so quickly without compromising on quality?
— I usually explain it with three simple rules that I follow myself and try to pass on to every manager I hire.
The first rule is: find your successor. As soon as someone takes charge of a team, they need to identify a person they can start training as their replacement. There are two reasons for this. First, because no one knows what tomorrow will bring. And second, because without a reliable backup, you can't grow as a leader—the whole structure would simply collapse if you stepped away.
The second rule is: make yourself unnecessary. A manager should build processes so that the team can run smoothly without them being pulled into every task or meeting.
And once those two are in place, you move to the third rule: spend at least 25% of your time on hiring, even if you don't have open positions at the moment. That was one of the keys to our rapid growth. We never froze recruitment and always stayed in touch with potential candidates. I kept a pool of people I wanted to bring over from other departments—or from the market—when the timing was right.
I'd also add that managers need to learn how to let people go and stop seeing it as something terrible. Not everyone will be the right fit. Sometimes a strong technical specialist doesn't mesh with the culture. Sometimes, someone who excels at interviews turns out to be unable to write solid code. If it doesn't work out, part ways. This also means you shouldn't be afraid of hiring mistakes—they happen, and that's part of the process.
— What concrete steps helped you bring in so many specialists in such a short period?
— We show up at every event where there's even a chance to meet potential candidates. Even at internal stand-ups, two or three people from my team will go on stage, crack a few jokes, and collect contacts.
I also encourage everyone to build strong relationships with recruiters, beyond the formal job description. If an HR specialist asks us to help another business unit, we always say yes—because we know that during our own hiring sprints, we'll need that goodwill and support in return.
And finally, we invest heavily in students. Several of my teammates give lectures a few times a week on programming, cybersecurity, and other topics. They spend a lot of time with students and eventually bring the most promising ones in as interns. It is the best way to test someone in real working conditions. For us, young talent is everything.
— Do you personally take part in interviews?
— I haven't run technical interviews for quite some time, but I do occasionally lead the final round. At that stage, my focus is less on hard skills and more on spotting potential red flags. The conversation is centered around motivation, and I usually ask a very simple—even somewhat banal—question: "Imagine you've joined the company. Where do you see yourself in one, three, and five years?"
Even senior candidates often struggle with this. Most don't have a clear plan beyond the first year. The question forces them to pause and reflect. It also opens the door to more personal discussion, which helps me understand them better. For instance, one intern once shared a 10-year plan: she wanted to spend some time in IT before moving into another field to reach her next goal. She ended up being one of our best hires—and if she ever chooses to return, we'd welcome her without hesitation.
— You mentioned you're bringing AI into the development process. How does that work in practice?
—One of my main goals is to make developers more comfortable and help them move faster. We've built internal tools powered by our own neural networks. For example, given the description of a ticket in the tracker, the system can identify what needs to be changed in the codebase and even generate a commit for verification. Reviews are partly automated as well: an AI agent scans the code and flags obvious issues. These tools are proving to be quite effective.
Prototyping is another strong use case. Imagine a product manager who needs an application for a demo, even though building software isn't part of their job. With tools like Cursor AI, they can sketch an idea—even on a napkin—and ask the AI to generate an iOS app from it. We've already had a success story where an employee went from nothing to a working prototype with several useful features in just two and a half hours. While it wasn't production-ready, it was impressive enough to present to the team.
We also use AI for everyday tasks such as summarizing chats. Instead of reading through 20 comments on a ticket, a manager can review a concise summary and save time. Beyond that, we are experimenting with models that generate code from natural-language requests. To be honest, these systems often behave like stubborn interns: they make mistakes, fix them when prompted, introduce new ones, and test the patience of senior developers. Whether such solutions will ultimately prove truly effective remains an open question.
— There's a lot of talk right now about AI replacing junior developers. What's your view?
— Universities have traditionally lagged behind industry trends by 10 to 15 years. And today, the pace of change is so rapid that knowledge can become outdated within a single year. As a result, many graduates leave unprepared for real-world work. The most motivated—those with genuine curiosity—eventually adapt and catch up. But those who rely only on formal education often leave with limited skills: some basic technical knowledge, sometimes only theory, and very little practical coding experience. And if they've been relying on GPT to write their essays instead of learning to think critically and articulate ideas, the gap is even greater.
So, what's the solution? In my view, we need to place much greater emphasis on internships—not just three or four months, but a year or even two. Senior engineers don't appear out of nowhere; if we stop hiring juniors, we cut off the pipeline entirely. AI tools like Cursor can take over certain tasks, but that doesn't replace the need to bring in young professionals, train them, and invest in their development. That, I believe, is the more sustainable path forward.
— More broadly, what do AI agents still lack to be truly useful to users?
— The first gap is skills. Take Perplexity's Comet Browser as an example. It can schedule meetings, write emails, and generate summaries—but only in certain apps. It works with Google Calendar, not Apple Calendar; Gmail, not Yandex.Mail or a native client. The functionality is impressive, but still too limited to handle everyday needs across ecosystems.
The second issue is context. Agents actually know very little about the user—not their payment methods, budget, or even location. I can't just say, "Hey Comet, order me a pizza." It won't know where I am, can't process a transaction, and won't integrate with services like Glovo. The same applies to taxis. And consider this: if a ride is booked through ChatGPT, Uber loses visibility along with the opportunity to promote other services. Would Uber agree to that? Still unclear.
The third challenge is trust. At the moment, there's no guarantee an AI agent will reliably complete a task. I can't depend on it to deliver research results in 30 minutes or to send a daily reminder, and there's no SLA or spending limits to make delegation safe. Without that trust, people won't hand over critical responsibilities.
Most of the "easy" problems have already been solved. Moving forward means crossing into new territory. Everyone dreams of having their own Jarvis from Marvel—a system that can seamlessly design, build, and execute tasks—but we're not there yet. I do think, though, that OpenAI's approach makes sense: release features, test them with users, and see what sticks. No one knows what will succeed until it's tried in practice.
ⓒ 2025 TECHTIMES.com All rights reserved. Do not reproduce without permission.
