In the world of IT management, each project is a unique challenge, especially when it comes to working with international teams, changing requirements, and new technologies. We spoke with Alexey Chernega, Senior Project Manager at Magora Systems, who has encountered a variety of situations in over 30 completed projects: from urgent changes in architecture at the final stages to intercultural conflicts in distributed teams. Alexey shared his working methods for adapting to changes and explained which skills will remain in demand for Project Managers in the age of automation.
— Please tell us, from over 30 of your projects, which one required the most adaptability? Describe a situation when the client radically changed the requirements at later stages. How did you reorganize the team's work, and what lessons did you learn?
— The most difficult case occurred during the development of a platform for a European logistics operator. We were literally on the verge of delivering the MVP when the client unexpectedly demanded to add a completely new route calculation module that takes into account driver behavior and warehouse loading. It felt like rebuilding the foundation of a house that was almost finished.
We immediately convened an emergency meeting with the client's technical director. In two hours of intense discussion, we managed to identify the truly critical components of the new functionality. At the same time, I restructured the team's work: part of the developers continued to prepare the current release, while another group began to work on the new module through a series of quick research cycles.
The temporary board in Jira turned out to be especially useful, where we noted how each change affected the overall progress. When we showed the client an alternative option with a partial implementation of new features, he was able to assess all the consequences for himself and make an informed choice.
In the end, despite the scale of the changes, we delivered the MVP with only a week and a half delay, implementing 80% of the new functionality. This project taught me that even at later stages, it is possible to find a way out by shifting from defending one's positions to collaboratively seeking solutions.
— Let's talk about mistakes in managing distributed teams. Surely, no PM can avoid them. Please share what typical mistakes managers make when working with multicultural teams? How do you avoid communication problems, especially when part of the team works remotely? Perhaps there is an example where a difference in mindsets led to a misunderstanding, and how you resolved it.
— One of the most illustrative situations occurred in a project with a team from three countries. Our British designer proposed an unconventional interface solution, the Georgian developer responded with "I'll think about it," while the Egyptian tester simply remained silent. It seemed like an ordinary work discussion.
But a week later, it turned out that the developer actually considered the proposal unrealizable, the tester was waiting for my official approval, and the designer was convinced that everyone agreed with the idea. We ended up losing a whole sprint over this misunderstanding.
After this incident, we introduced a strict rule: if something about the task is unclear, it must be stated in writing within a day. The most significant change in work after this case was the appointment of a specific technical owner for UI solutions. Now all disputed interface issues went through one person, which significantly reduced the number of misunderstandings.
— Let's move on to trends in IT management. There is a lot of talk about hybrid methodologies and AI for planning these days. What trends, in your experience, actually work, and which are just hype? Please provide an example when the implementation of new tools or approaches yielded a tangible result.
— In one of the recent projects with an international team, we decided to experiment with modern tools. We set up GPT to process client voice notes—now the artificial intelligence transformed the stream of thoughts from audio into a structured draft of the backlog. For documentation, we used Notion with automated reports that were generated daily. All tasks were tracked in Jira, with metrics specially set up to analyze the time from the emergence of an idea to its implementation.
The result was surprising—the time for processing requirements decreased by 35%. But the main thing is that the client began to better understand our processes because they received information in a convenient, readable format, rather than in the form of "jira overload."
At the same time, I remain a skeptic about those who believe that AI can completely replace a project manager. Yes, it handles routine tasks excellently, but strategic decisions, managing expectations, and resolving conflicts still require human involvement.
— How do you support the team when changes in requirements force you to redo work? What methods help prevent burnout? Share your experience of when you were able to maintain developers' motivation under tight deadlines.
— I clearly remember the project for a fintech startup when, a week before the demo, the client completely changed the product concept: from B2B to B2C. Imagine the state of the team that realizes that weeks of their work are essentially going to waste.
The first thing I did was gather everyone for an honest conversation. I didn't sugarcoat it: "The situation is really tough. We can spend time worrying, or we can find a way out together." Then we broke the work down into small, but achievable stages—literally 2–3 days each. After each mini-stage, we marked progress on a special "victory board" in Notion.
Surprisingly, just three days later, the developers themselves began to suggest optimizations and improvements. Instead of giving up, the team mobilized. As a result, we delivered the project with only a four-day delay, and the participants later fondly recalled this "hellish sprint."
The main takeaway I got from this experience is that people are willing to work in challenging conditions if they understand the goal and see their contribution to the common cause. It is important not to hide problems, but to openly discuss them and seek solutions together.
— You mentioned that you developed a mentor support system. What skills do you consider most important to pass on to new PMs? How does it help in challenging situations?
— When a company is growing rapidly and teams are distributed, standard onboarding for PMs is no longer sufficient—especially if the newcomer immediately lands in a hot project with a demanding client and intercultural nuances. That's why we created a three-level mentoring system at Magora: adaptation (analyzing real cases instead of dry theory—for example, how we saved a project when deadlines were missed), support (bi-weekly reviews of complex situations in a safe format where PMs can openly discuss problems), and growth (personal checkpoints where we talk not only about tasks but also about psychological well-being).
Key skills that I try to convey: managing client expectations without pandering, maintaining calm in uncertainty (when requirements change daily), building trust within the team—because Jira can't replace real human connection—and balancing honesty and diplomacy in communication with stakeholders.
For example, when a young PM encountered a demanding client from the UAE, we analyzed his communications together—it turned out he was using uncertain phrasings too often. In two weeks, we prepared scripts for complex negotiations and taught him how to show the consequences of changes in numbers. As a result, he not only stabilized the project but became a mentor himself after four months.
— How do you work with clients who constantly change their requirements and refuse to accept the real constraints of the project?
— Toxic client behavior is usually driven by fear of losing control or money. In one project for an international B2B service, the client changed the core functionality for three weeks straight: first demanding real-time reports, then emphasizing visualization, and then changing the concept again. During the demo, he accused us of "straying from the goals," even though he himself changed the requirements four times.
At first, we tried to explain the problem gently over the phone—it only made the situation worse. Then I prepared an infographic with a timeline where each change in requirements was reflected in terms and efforts. I invited the client's financial director to a meeting. And instead of saying "we can't," I offered three options: MVP on time without new features, full implementation with a delay, or a hybrid option. The client chose the compromise, and two months later, we started a new project with them.
— What are the key differences in working with clients from the USA, EU, and the Middle East? Or is the 'internal kitchen' of business processes the same in any country?
— Working with international clients, I realized: each region is not just a different language, but a completely different culture of decision-making and communication. In the USA, speed and results are valued—there, a PM must show initiative, and open objections are considered engagement. In Europe (especially Germany and the Netherlands), processes and document flow are more important; transparency is more important than speed here. But the most challenging are projects in the Middle East (MENA), where decisions are made hierarchically, and openly saying "no" to a client means jeopardizing the relationship.
In the UAE, we encountered an interesting situation: the client said "No need to worry" to our warnings about the risks, but expected to meet the original deadlines. Instead of a direct refusal, I offered three scenarios presented as options: a basic MVP, a full version with a delay, or an intermediate option. This helped the client save face and allowed for a compromise. In the USA, in a similar situation, one can speak directly about the issues, while in Europe, the emphasis is on processes and documentation.
— If you could give only one piece of advice to those starting a career in IT management, what would that advice be? What skill or principle has become the most valuable for you over the years?
— The most valuable skill is managing uncertainty. Don't be afraid to admit you don't know something, but be the one who finds the answer. Your task is not to control every step, but to create clarity where there is none. Once, I saw an experienced PM "read" the problem just by the way the designer was silent during the meeting. That's the level—noticing what is not said and turning chaos into a workflow. A Project Manager is not about control. It's about meaning, clarity, and sustainability. Everything else is just tools that you will gather over time.
ⓒ 2025 TECHTIMES.com All rights reserved. Do not reproduce without permission.
