Today’s guest is Pavel Kostikov, Engineering Manager at Yandex, with more than 15 years of programming experience and 8 years of leadership in team management. Pavel played a significant role in the development of Yandex.Market’s FinTech department, where, within the marketplace, his team developed the share of financial products from 2% up to 45% in 2.5 years. Equipped with solid experience in backend development, project management, and machine learning, Pavel has driven huge initiatives across the Yandex ecosystem, including Market, Maps, Taxi, and the chatbot platform Yandex.SupportAI. Today, we are going to talk about Pavel’s journey, his approach to leading cross-functional teams, and how he navigates the difficulties of building large-scale, impactful products in the tech world.
1. You have worked on so many different projects within the Yandex ecosystem, ranging from Maps to Taxi and including the FinTech division at Yandex.Market. How do you prioritize and balance such vast areas of work?
It may seem like I’ve worked on a wide range of diverse projects, but each transition in my career was very logical and deliberate.
I started out working at Yandex.Maps as a backend specialist when it was fortunate to have an outstanding team of engineers. I realize now, of course, that the hardcore engineering challenges we tackled there-are those very few companies were up to at the time. We have created a sophisticated cartographic data editor and a world-scale traffic forecasting system, solving complex problems of real-time data processing. Further, I was promoted to Team Lead, my first managerial role. That finally gave me the opportunity to step into leadership and understand what it means to be responsible not only for your work but for results and growth from the people around. This was a very challenging experience, though it turned out to be rewarding in many respects.
Having considerable experience in back-end development, I decided to widen my technical expertise. I moved to the machine learning department at Yandex.Taxi and started working as an infrastructure developer. That gave me a chance to work with ML approaches in real project conditions-to see what works and what doesn’t. My background in backend development brought strength to the team in that I worked on the infrastructure challenges and facilitated the collaborations with other teams so the applied ML developers could focus on their core work.
During this time, I joined an internal startup within the ML team called SupportAI: a B2B chatbot platform. I saw the potential therein and joined in as the first backend developer on the team. As we grew very fast with clients, the need for new features started increasing, and thus I had to hire and onboard new backend and frontend developers. In fact, I became something like a CTO, managing everything from coding and architecture design to hiring and team development. Since we didn’t have a product manager, I also contributed significantly to product strategy. The atmosphere was invigorating in the startup environment, and wearing different hats would move success.
My next step was to take the position of the head of a cross-functional development team at Yandex.Market. By that time, e-commerce was showing explosive growth, and leaders with relevant experience were in demand. Fintech seemed very interesting because it was obvious that financial solutions like credit offering in physical stores would become a must in e-commerce. It indeed proved to be so.
This role was quite a big change regarding managerial expectations. The Yandex.Market team was growing fast, restructuring several times, which influenced the processes and morale. One had to balance multiple projects in all this change-quite a challenge, requiring strategic prioritization and adaptability.
2. As the Engineering Manager of the FinTech division in Yandex.Market, you have seen a huge growth in the share of financial products. What were the key drivers for this success, and how did you manage to scale your team’s efforts?
I believe that one of the key drivers of our success in Yandex.Market’s FinTech division was the goal-setting that we had quite precisely set, and I must commend a product team for clarity. Literally every change we did was meaningful and very well-justified from the product point of view, and that led to substantial improvements in key metrics, both in financial product share and overall product impact.
For the engineering team, execution speed was the name of the game. We could literally calculate the monetary value of launching a feature a few days earlier. In this fast-paced environment, clarity and structure in how we worked were essential. We organized our work into projects, each representing a significant change, whether user-facing feature or technical refactor. Every project followed well-defined stages: formulation, design, development, experimentation, and addressing technical debt.
The design stage was pivotal. It’s where we anticipated potential pitfalls and planned for them in advance. We intentionally allocated significant time to this stage to ensure robustness. Projects ran in parallel, with a dedicated engineer responsible for each project, maintaining a clear understanding of its progress at all times. This allowed for efficient parallelization of the efforts and fostered growth for the engineering team by having ownership of projects and giving a broader perspective than a purely development-focused role.
In such a large marketplace ecosystem, where every other product or infrastructure team would work parallel, the challenge wasn’t about writing the code but understanding what to write and how not to get your changes conflict with other teams. It was important to have pretty close collaboration between neighboring teams with respect to aligning the timelines and goals to reduce possible conflicts across projects.
Given the scope of our plans, resources of our team were usually too weak. So, we had to work extensively with adjacent teams, involving external developers in our projects when necessary. That, of course, created some challenges in onboarding-specifically for the developers who joined our domain for the first time. Meanwhile, we have largely improved the process of onboarding and documentation in general; now integrating new contributors into our projects has become easier.
Of course, there were setbacks along the way: notable failures like a complete stop in the processing of payments on the platform for an hour. I believe this is inevitable in such a dynamic environment. However, we treated every launch and mistake as a chance to learn and grow from. The team learned by open discussions during retrospectives and improved toward the goal of not making similar mistakes anymore.
3. In your experience, what are the biggest challenges when building and managing cross-functional teams, especially when integrating multiple disciplines like backend, frontend, mobile, and QA?
Managing a cross-functional team differs significantly from leading a team of specialists focused on a single discipline, such as backend developers. Cross-functional teams come with unique challenges and opportunities that require thoughtful coordination and leadership.
First, specialists aren’t interchangeable. The expertise of every team member for a certain project is so narrow that even the smallest projects require backend, frontend, mobile, and QA professionals to be in tight sync. The more interdependent team members are, the more structured processes and clear communications there need to be. Otherwise, delays and miscommunication can easily double the length of a project timeline. Well-defined workflows are necessary, tailored either to the team or to the project, to ensure efficiency and alignment.
Second, long-term planning and hiring is a challenge on its own. Unlike homogeneous teams, it’s harder to predict workloads and hire into cross-functional teams. Past project heuristics often set guidelines for staffing. For example, a product might typically require one frontend developer for every two backend developers, and one QA engineer for every three frontend developers. While these kinds of patterns help, lopsided workloads across platforms will always be difficult to avoid. In quieter periods, team members can focus on paying off technical debt or working on internal technical initiatives.
A technical lead of such a team would also need to have high-level knowledge concerning the architecture of each platform. This becomes necessary in cases of effective technical debt management and while planning initiatives crossing multiple disciplines. The acquisition and maintenance of such knowledge is continuous work but is aided, for example, by cross-functional architectural meetings where solutions and challenges are shared.
With all these complexities, cross-functional teams excel at delivering quality products fast. This setup aligns well with business goals, as the time to market for new features is competitive. Meeting the demands of different disciplines allows for robust products and adaptable teams.
Managing cross-functional teams is pretty much like trying to solve a dynamic, multilayered puzzle: continuous rebalancing of resources, tracking the progress of the project, and maintaining the overall well-being of the team. Inevitably, changeable requirements raise the stakes, but such work can be extremely rewarding because all this can be nailed with careful planning and open communication. Such challenges provide more opportunities for creating collaboration and innovation.
4. You have led teams in both technical and product development roles. How would you ensure that your engineering team stays aligned with the product vision while maintaining the technical excellence of the product?
Naturally, the tension between product vision and technical vision is there; they usually work independently and sometimes even fight for the same limited resources. In my experience, it’s all about continuous alignment and open communication.
Regular synchronization meetings help to ensure that everyone is on the same page: it keeps them updated about the product direction and technical challenges. Engineers understand both short-term tactical goals and the product’s long-term strategic objectives. They can make informed decisions, such as not optimizing components that are likely to be replaced shortly.
Equally very important is to bridge the gap between product and technical teams: if the product team has a very clear understanding of the system architecture, then it will be able to design functionality that fits with the technical constraints. That makes the implementation easier and reduces edge cases, improving the collaboration across teams.
The tough decisions often come in balancing product and technical priorities. When technical debt directly impacts business outcomes, such as when errors lead to lost sales or delayed time-to-market, the choice becomes much clearer. These cases allow for prioritization based on measurable benefits to the business.
But where the effect of technical debt is less direct, it does require continuous monitoring and clear risk communication. Long-term neglect of technical debt may lead to significant losses; hence, I work on the identification and framing of manageable projects with measurable results. This approach lets them make progress without compromising on the team’s alignment with the broader product vision.
5. It was great how you shared, first, how Yandex.Market used an unregulated BNPL model called “Standard Split” and then weighed other traditional credit solutions, each of which presented tectonic limitations. If you could walk us through identifying these challenges and then coming up with a dedicated credit card solution, “Super Split,” what were some of the strategic considerations on risk management and resource allocation that guided your team’s decisions toward the success of this initiative regarding user experience?
For a long time, Yandex.Market had a product called “Standard Split,” de facto covering BNPL functionality. Because it was an out-of-the-box credit product, it worked outside of governmental regulations, which means there was no need to check a user’s credit history, and in case of a user failure of repayment, it wasn’t possible to collect the debt by legal means. It had at its core a robust risk engine that analyzed a vast amount of user data and ended up with an extremely low default rate.
While this worked well, this approach had some serious limitations. Since the model was unregulated, we could not secure funding through interbank markets at favorable rates, which made the financing cost relatively high. This, in turn, meant that offering longer repayment terms-such as 12 months-either became too risky or economically unfeasible for the platform.
Another option was a regular loan model. In it, users applied for credit for every purchase. Then, after approval, a loan was issued and merchandise was shipped. Actually, that was just an e-version of offline consumer loans available in every electronics store. For some time, we even considered playing the role of a credit broker: sending applications to several banks and offering users the best options available.
This wasn’t ideal for a number of reasons: from the user experience point of view, it was cumbersome to fill out a credit application for each purchase. The conversion rate from click buy button to purchase was low even with pre-filled data. Technically, integration with each bank required lengthy and multistep processes in aligning requirements, synchronized planning, and implementation that led to big development timelines. Moreover, since the banks themselves decided on credit approvals, the marketplace had no control over the results. Due to this very long process, users would often drop off and orders get lost.
These issues led us to consider other options, and the concept of issuing a credit card came about. This resolved the problem of repeated applications, as users needed to go through the credit approval process only once. After that, they could use the card to make purchases multiple times. Also, the card had a pre-defined credit limit, and we were able to indicate the availability of credit early in the user’s journey. As a platform, we could guarantee this limit was approved, ensuring a smoother experience.
Given the previous experience of working with several banks, the decision was taken to work with one bank for simplicity, even though the terms might have been more favorable due to the competition. This considerably simplified the technical implementation.
The credit card model integrated quite nicely with our existing infrastructure. We needed only to create a card issuance process as a separate user flow, and that could be integrated anywhere. Logically enough, we first placed this flow in checkout: after the completion of the flow and the issuing of the credit card, pay using the established card payment rails.
We wanted to make this even smoother for users, so we went a step further. Instead of just communicating the granting of a credit card, we sold it as an “upgrade” to the Standard Split. We explained to users that in exchange for more data, filling out a form, and becoming a bank client, they would have better conditions, such as interest rates and longer repayment periods, offering them access to the Super Split product. While all the required documents were signed, the user experience felt frictionless-almost like magic.
This was a very simple-to-implement-yet-extremely-powerful product. The one-time approval process resonated well with users, increasing adoption manifold. This innovation quickly gained popularity, driving substantial additional sales for the marketplace.
6. To lead the development of financial products, one has to have deep knowledge in both the technical and regulatory aspects of the space. How do you stay informed and ensure your team adheres to best practices in financial technology?
Indeed, financial technology product development is a different kind of challenge that requires knowledge in related fields, especially legal and regulatory compliance. It differs from most other fields in that fintech often has many requirements unrelated to the functionality of a product or the user experience of a customer but are rather required by governing authorities. These varied regulatory demands have far-reaching effects on system architecture, approaches to development, and consequently project timelines.
For instance, in one project, we extensively worked with a legal concept of “Banking Secrecy”. That is to say, some data, such as the balance of a credit card, fell under very strict legal rules depending on which legal entities it concerns-for example, Yandex.Bank or Yandex.Market. Technically, this imposed constraints where some systems could store this data, others could process but not store it, and some could neither process nor store it. The regulatory requirements in this domain were also generally vague, left to interpretation, and very frequently updated. This implied that the changes trickled down all the way into our architecture and development timelines.
We had regular sync-ups with product managers and legal experts to keep abreast of the changing requirements. Other questions, such as whether derived data from banking secrecy was also classified similarly, needed to be duly legally analyzed. In addition to managerial alignment, each and every engineer who worked on features that involved banking secrecy needed to understand the regulatory constraints and where they came from. Compliance is not a point-in-time activity; systems have to stay compliant. For instance, it is tricky to automate and make sure logging does not accidentally store sensitive information, such as banking secrecy. To solve that, we introduced regular audits to positively validate compliance.
Legal language sometimes appears subjective compared to the strict logic engineers are used to. In order to fill in the gaps, we documented all agreements in painstaking detail with very specific language to ensure clarity and alignment across teams.
In a nutshell, regulatory restrictions are a big chunk of developing FinTech; thus, structure and thoughtfulness of process and communications is required.
7. During your tenure in Yandex.SupportAI, you helped grow the paying client base and expanded automation of the customer support processes. What were some of the main strategies harnessed that drove this, and what do you think were some of the big technical challenges?
SupportAI is a chatbot platform, a startup within a large company. The project began with automating the customer support processes of Yandex.Taxi, which employed thousands of operators in call centers responding to routine queries. Given the repetitive nature of such interactions, the automation potential was high. At the time, text classification models were sufficiently advanced to address this task, allowing us to automate up to 80% of Yandex.Taxi’s first-line support.
This success was a precursor to expanding into other Yandex services like Market, Eats, and Lavka. Finally, we got our first customer from outside of Yandex: an e-commerce store selling jewelry. A chatbot was quickly deployed in a prototype phase that marked our entry into the external market and proved that support automation had value beyond Yandex’s ecosystem.
I joined as the first backend developer and later became the lead developer as the team grew. Initially, the business goal was to rapidly onboard clients. However, the technical challenge was huge: every chatbot was custom-made, with absolutely no reusable components, which made development very slow. To solve this, we started building a unified platform, extracting shared components to speed up the creation of future chatbots.
Since we already were a part of the Yandex.Taxi ecosystem, we used Yandex.Taxi infrastructure-microservices framework. It was really easy to create microservices on this platform. It had lots of built-in tools like monitoring, test frameworks, and CI/CD pipelines. The framework had some limitations, but the advantages outweighed the disadvantages, and we could concentrate on domain-specific tasks.
The core domain challenge we faced was to provide a dialog engine for task-oriented bots, which were supposed to solve some specific user problems. Internal bots, for instance, Yandex.Taxi, normally operated on a single-turn model-one user query, one response-but with external clients, the systems were fragmented and required multi-turn dialogs to collect more information for solving user queries. This introduced complexity, prompting us to study competitors, academic research, and open-source solutions, enriching our approach with new ideas and improving the versatility of our dialog engine.
As our client base grew, integration demands increased. Chatbots were not built in isolation, they needed to interact with existing customer systems, such as CRMs and booking systems. Customizing integrations consumed significant time, so we developed a no-code platform to simplify this process. This platform enabled straightforward HTTP-based integrations or parameterized customization of prebuilt connectors, significantly reducing setup times.
This eventually allowed us to reduce the deployment cycle of chatbots from several weeks down to several hours in some cases. In other words, our technical strategy was not to invent yet another wheel, focus on core competencies, and be constantly optimizing bottlenecks in our processes.
8. You’ve worked with machine learning infrastructure and have mentored teams within the Yandex.Taxi ML group. What are some of the most important lessons you’ve learned when it comes to deploying machine learning systems at scale?
Joining the machine learning team, I brought with me seven years of experience in backend development from Yandex.Maps. Knowledge of back-end development reinforced the ML team, while I got very valuable practical experience in implementing machine learning solutions in production services.
Another important learning is on defining what exactly has to be optimized. In other words, identifying the right success criteria is really basic in an ML optimization task: Does the optimization of any particular metric improve the business or not? Basically, defining a metric does not help without establishing how it will be measured. These need not be mere measurements but a recurring process throughout the life cycle of the system.
Another important understanding is that once the ML model is set, data becomes a part of the software. The method through which the gathering and processing of data are performed will be critical. To build a system that will maximize our optimization goals, the way we collect and process data must be in line with those same optimization goals. Bad data practices can quickly nullify the impact of even the best-designed models.
Applying ML in production is very different from competitive tasks, such as those on Kaggle. In competitive settings, challenges like identifying the key metric and preparing the data are usually pre-solved, making the problem much simpler. In real-world applications, these foundational challenges require deep, ongoing consideration, adding complexity and multidimensionality to the work.
Finally, there is infrastructure, which is not only crucial for ML teams but for any engineering team. This means that even for a team of 20 engineers, there are usually two dedicated infrastructure-focused engineers building shared tools and frameworks. This helped leapfrog the work of our ML team very much. On top of the urgency to deal only with tasks relevant to project results, it is also quite easy to neglect the build-up of shared technical debt. Devoting time and resources to infrastructure, however, pays for long-term sustainability and productivity.
9. As a leader in Yandex.Maps, you have participated in rewriting a legacy system and increasing its usability manyfold. How did you ensure that such a complex refactor went well, and how did you mitigate its risks?
One of the key features of Yandex.Maps is showing real-time traffic conditions, where congested areas are highlighted. This is enabled by two major components:. First, there is an automated system for calculation and prediction of traffic congestion, where no human intervention at all is involved. Second, there is a road closure management system where portions of the road are closed for a certain period due to construction. The road closures are kept in a semi-automatic mode, where the operators can manually mark the closure based on some external inputs such as news reports while the system will provide automated suggestions for potential closures.
Given the wide usage of Yandex.Maps in big cities, mistakes in one of these systems notably affect the traffic in the whole city. Once upon a time, the road closure management system was in the worst shape: its tech stack was outdated, there was no documentation at all, and nobody knew how it worked because its developers were gone. Furthermore, it had a lot of unresolved feature requests and thus was both technically and functionally obsolete.
We kicked off this complex refactor by first performing an in-depth audit of the legacy system: to demarcate its dependencies, limitations, and key functionalities. This included interviewing operators relying on the system daily for insights into pain points and unmet needs. We evaluated technical feasibility for migration to Yandex’s primary backend stack in accordance with our long-term maintainability goals. The outcome of this planning stage was a roadmap with detailed steps, first focusing on stability and minimizing service disruptions.
While analyzing the functionality of the whole system, we marked irrelevant or not-needed parts and excluded them from the scope of the refactor. Even by streamlining, the functionality to be rewritten was quite extensive, so we went incremental with the refactoring process.
It involved the creation of a parallel service on refreshed technology, implementing core features while the legacy system remained live. During a transition period, we ran parallel systems to ensure data kept in sync from both the new and old interfaces. Thus, the step-by-step migration of the functionality allowed the testing of the new implementation within the controlled environment in order to provide ongoing feedback for the system operators. The participation of operators is vital in testing, even with several iterative passes through it. Gradually, the requirements would have a complete overlap to where the cutover can be switched entirely to a new system. Therefore, deprecation of the old legacy data model needed replacement on modern stacks.
We chose reliability over speed in migration because we knew that mistakes in traffic management would carry a lot of consequences. An extensive set of tests was conducted to confirm each and every component of the new system. Furthermore, a robust fallback mechanism was set up that could revert back to the legacy system in case of any critical failure during the transition. By moving in a calculated and phrased manner, this was reassurance that the new system would at the very least meet the mark of its predecessor regarding the required level of reliability but improved upon its functionality and maintainability.
10. Finally, coming with over a decade of engineering management experience, what advice are you giving to prospective engineers and managers of engineering intent on delivering impact teams and projects?
I would encourage them to acknowledge the importance of soft skills, which is quite high. Sure, technical knowledge is critical, but how to speak, handle conflict, and get people together in a working relationship can determine the fate of teams and projects. The active listener who can put himself in another’s place and be understood easily can work wonders on technical and non-technical participants alike to build up a trustful, open atmosphere.
Continuous learning of skills and knowledge is another cornerstone of success in our fast-moving industry. Technology keeps on changing so fast; being relevant basically means cultivating a kind of curious, self-improving mindset-from emerging tools and business strategy to people management. In that sense, growth investments are important for both engineers and managers. Helping your team lean into this growth mindset can make all the difference in driving innovative and impactful projects; it’s about professional development.
Balance is key for long-term success. It focuses on a balance between speed and quality, vision and pragmatism, and individual needs and team goals. In practice, engineers will work to solve complex problems without over-engineering solutions, whereas managers will look for a delicate balance between people-supporting and business outcomes. With balance, you will foster a culture where innovation can flourish without well-being or deliverables suffering.
