We’re interviewing Dmytro Saiankin, an experienced software architect and engineering manager with expertise in e-commerce, fintech, and AI safety domains. Beginning with EdTech platform development with more than 50,000 students enrolled and moving to cross-border trade system development in Central Asia, Dmytro implemented high-impact solutions as a manager of up to 100 individuals working across various time zones. His current endeavor includes collaborating with engineering teams at Tipalti and developing research toward AI alignment.
How did your early career experiences shape your approach to engineering management today?
My early days of working at RapidSoft as an Enterprise Solution Architect taught me the importance of valuing the business impacts of technology decisions. When I built a bank loyalty program for 17 million customers, I learned that a 15% improvement in churn reduction wasn’t just a pleasing number, it translated to actual revenue and customer satisfaction. It formed part of my thinking that engineering leaders need to see more than just code and architecture to understand how technology drives business impact.
Joining project management at Genix was also life-changing. Getting 50 employees in balance and acquiring a $4 million contract proved to me that technical expertise is not just unnecessary if you cannot communicate value to stakeholders and manage resources but also that you must balance technical debt with business requirements, something that would become critical when re-organizing teams and processes at Profilum and SmartAirKey.
You’ve worked across diverse industries – e-commerce, fintech, EdTech, and IoT. What are the common technical and leadership challenges that transcend industry boundaries?
The underlying problem is always the same: how to create systems that are scalable while being reliable and performant? It might be processing financial transactions, delivering educational material to 50,000 students, or dealing with IoT devices; you’re operating at scale with data and needing real-time response. If we look at RAM-IT, our B2B marketplace had a revenue of $2 million, and at Profilum, we had thousands of schools, both demanding heavy architectures that could sustain growth without collapsing.
From a leadership viewpoint, the challenge is in creating teams that can reconfigure quickly to changing requirements with minimal degradation of code quality. Each industry has their particular compliance and performance requirements, but the underlying principles are similar: clear communication, good process management, and making sure your team possesses the correct technical expertise. Whether it was 7 at Kameleoon or more than 80 at RAM-IT, the solution was always defining those processes with clarity and keeping that balance of structure and flexibility.
Can you walk us through the cross-border trading system you architected in Central Asia? What were the unique technical and regulatory challenges?
That was the most complex project I’ve ever worked on because it was not only a matter of technical design but also handling different regulatory environments, currencies, and business processes in multiple countries. The system needed to carry out currency conversion, differing tax regimes, and multiple methods of payment without compromising on audit trails that were acceptable across different jurisdictions.
Technically, what we had to do was devise a system that could handle the complexities of cross-border logistics and financial transactions without lagging or crashing. We used both SQL and NoSQL databases to handle different types of data, logistics and tracking information needed to be handled with flexible schemas. The system had to integrate with dozens of APIs and payment providers, each with its own dependability profile and rate limits. Taming this chaos yet needing to scale the system to handle our growing number of transactions required some careful planning of the architecture and plenty of testing.
At RAM-IT, you managed over 80 team members across 4 time zones. What strategies did you develop for effective remote team management and communication?
What solved the problem was establishing good communication protocols and ensuring that everyone understood where they fit within the overall plan. I made sure we had solid documentation and async communication channels so work could continue even if other time-zone teams were not on at the same moment. Having regular one-on-one meetings was important, I made sure to get hold of team leads on a weekly basis and individual contributors on a bi-weekly basis at least.
Standardization of the process was required at that scale. We had standard code review processes, defined deployment processes, and constructed full-fledged project tracking mechanisms. I also focused a lot on building team leaders who could make decisions autonomously without sacrificing on overall objectives. This meant investing time in mentoring as well as defining proper escalation mechanisms. The budgeting side was also crucial, coordinating resources in multiple locations and ensuring we had appropriate infrastructure to enable distributed development required thoughtful planning and constant optimization.
Your EdTech platform Profilum served 50,000 students and was ranked in the top 10 nationally. How do you approach building recommendation systems that scale while maintaining personalization?
The challenge in recommendation systems is achieving the correct balance between computational complexity and response. We were working on student profiling for over 3,000 schools at Profilum, so we needed to handle various kinds of data, academic, career preferences, interests, and provide personalized suggestions in an efficient manner. We adopted a hybrid approach that combines collaborative filtering and content-based recommendations along with machine learning models that could be updated incrementally as new data came in.
The key architectural decision was to separate the model training pipeline from real-time serving infrastructure. We used batch processing to update models periodically but maintain response times for student queries to be fast. A/B testing was crucial, we were always testing different recommendation algorithms and ranking approaches to optimize student engagement and learning. The environment further needed to support the seasonal fluctuations of schooling data, with usage fluctuating wildly between school terms and holidays, requiring careful capacity planning and auto-scaling capabilities.
You’ve been involved in AI safety research. How do you see AI safety considerations affecting engineering practices in traditional industries?
AI safety is not just preventing superintelligent systems from overtaking the world, it’s building reliable, predictable systems that do what you intend them to do. From my work in financial systems and recommendation engines, I’ve seen how decisions made by algorithms have concrete real-world consequences. When you’re working with millions of transactions or influencing educational pathways for thousands of students, system reliability and predictable behavior are the top safety issues.
From an engineering perspective, AI safety translates into better testing practices, stronger monitoring, and better explainable models. We have to create systems where we are able to view why decisions are being made and have faith in their consistency. This includes deep audit trails, and building systems that can handle edge cases with elegance. The lessons I’ve learned in AI safety research are directly transferable to developing more robust engineering systems in mainstream industries.
Looking at your experience restructuring teams and processes, what are the key indicators that tell you when an engineering organization needs fundamental change?
The biggest red flag is when technical debt does start affecting business outcomes, when small changes take weeks instead of days, or when outages are the norm. At Kameleoon and RAM-IT, I entered environments where it had become excruciating to introduce new capabilities because of accumulated technical debt and unclear processes. If your team is spending more time fighting the system than building new abilities, that’s a very good sign that restructuring is in order.
Another indicator is the failure of communication, when all the different teams are working in silos without established integration points, or when they are making decisions in a vacuum. Within RAM-IT, when I joined, we had backend, frontend, mobile, and BI teams that were not collaborating particularly well, leading to subpar user experiences and duplicated effort. Reorganization meant not only reorganizing the teams but having established APIs, consistent documentation standards, and daily cross-team interaction. Metrics for success also became an area of attention, instead of just gauging the productivity of a single team, we started tracking end-to-end delivery periods and system dependability metrics.
You’ve managed budgets, led investment preparations, and closed multi-million dollar contracts. How do engineering leaders need to evolve beyond pure technical skills?
Technical acumen gets you in the door, but business acumen keeps you at the table. When I was preparing for rounds of investment in RAM-IT or negotiating the $4 million Genix deal, I had to translate technical capabilities into business value. Investors and clients don’t care about your fancy architecture, clients care about revenue impact, cost savings, and risk mitigation. How to speak in the language of ROI, customer acquisition cost, and competitive differentiation became as important as mastering system design.
Budgeting reminded me that each technical decision has a price tag. When I was overseeing infrastructure expenses, staff costs, and subscription services in several teams, I came to think in terms of total cost of ownership, rather than upfront implementation. This paradigm shifts how you make technical choices, you begin thinking about the cost of maintenance, scalability economics, and productivity effects on teams. The ability to articulate technical trade-offs in business language and to present data-driven arguments for resource allocation was a critical skill that differentiated me from technically oriented contributors.
From your DevOps work at Kameleoon to embedded systems at SmartAirkey, you’ve tackled vastly different technical domains. How do you rapidly adapt to new technology stacks and industries?
The key is to be interested in the fundamental principles, not specific technologies. Whether I was rebuilding a 100TB data warehouse using ClickHouse at Kameleoon or rebuilding keyless access systems at SmartAirkey, the core issues were the same: data processing, system stability, and performance optimization. The specific technologies are different, but the engineering principles remain the same.
I have learned to look rapidly, in whatever new domain, what are the most important performance constraints, what are modes of failure, and where do current systems need to fit in? At SmartAirkey, I had to learn embedded systems and wireless protocols, but the overall challenge was reducing system response time and making it more reliable. The same rigorous process I used on web applications carried over to embedded systems: identify bottlenecks, introduce monitoring, optimize in phases. The LEGO-based test system I created there was merely creative problem-solving transferred to a different environment, the same mindset that worked for me to optimize CI/CD pipelines in Kameleoon.
What trends do you see shaping the future of engineering leadership, particularly as AI becomes more integrated into development workflows?
AI is essentially changing the engineering skills required for engineering teams. We’re moving away from coding to designing intelligent systems, and hence engineering managers need to be aware of not just traditional software architecture but also data pipelines, model deployment, and reliability of AI systems. At Tipalti, I’m seeing how AI is coming in, more and more, into everything from fraud detection to customer service, and that means a different design of the system and team organization is necessary.
The bigger shift is in how we think about system behavior and predictability. Classical software is deterministic, feed it the same input, produce the same output. AI systems are probabilistic, so engineering leaders need to develop new ways to test, inspect, and ensure quality. We need to build teams with experience in classical software engineering and machine learning operations. This is not about the acquisition of data scientists, it is about up-skilling your entire engineering team to interface with AI systems effectively and maintain the reliability and performance standards which businesses rely on.