Reading Time: 7 minutes

At SiGMA Central Europe in Rome, European Gaming Media sat down with Yevhenii Yankovyi, Vice President of Technology and Deputy CTO at RedCore, for a deep look into what truly powers RedCore’s large-scale engineering operations.

RedCore is known for innovating at enterprise level, yet moving with the agility of a fast-growing tech company. In this conversation, Yevhenii breaks down how the organization manages that balance: how engineering teams maintain both speed and reliability, how automation empowers creativity, and why culture must remain a daily practice rather than a one-time achievement.

Can you introduce yourself and RedCore’s approach to engineering at scale?

Sure. My name is Yevhenii, I’m the Vice President of Technology at RedCore and Deputy CTO. RedCore is a large company with many products and projects, so everything we do operates at a significant scale. And when people hear “enterprise-level engineering,” the usual assumption is that scale automatically means slowness: slow decision-making, slow implementation, slow testing, slow time to market.

That’s the mindset we challenge. We don’t believe speed and stability are opposites. In our experience, at this level of complexity, the two actually reinforce each other. When you build the right processes, the right technical foundations, and the right organizational structure, speed becomes a natural result of stability – not something that contradicts it.

We plan for scaling from day one. For us, that’s a fundamental requirement. We build products with the expectation that they will grow, and growth means scale. So we design with that in mind from the very first line of architecture.

But that doesn’t mean disappearing for six or ten months to design the “perfect” system. That’s the common mistake people make when they hear “design for scale.” Our approach is different: we keep the long-term vision in mind, but we move fast, iterate, and make sure the product can evolve without slowing the team down. Stability and speed working together – that’s the engineering culture we build at RedCore.

How does RedCore balance speed and stability in daily engineering?

I will explain this with a simple metaphor: think about a car. Everyone talks about acceleration and top speed, but none of that matters if you can’t take a corner. Speed alone is not the winning formula – you also need control.

That’s exactly how we look at engineering at RedCore. We want to accelerate, make decisions quickly, and develop fast. But we also need the ability to slow down at the right moment, change direction, and stay agile. Balancing speed with stability is the only way to move at scale.

There are many layers to this – it’s a topic I could talk about for days – but in a nutshell:

at a big scale, you must have strong standards, clear policies, and a high level of automation. We rely heavily on automation: infrastructure as code, CI/CD pipelines, automated testing, and all the tools that remove repetitive, routine work from engineers’ daily lives. When the routine disappears, people can focus on what humans actually do best: creativity, problem-solving, and innovation.

However, automation doesn’t build the software for you. It creates a safety net. It catches mistakes, guards quality, and supports engineers when their creativity pushes boundaries. In other words: tools give freedom, and also protect that freedom.

And of course, this includes AI and many other modern tools. We use whatever helps us keep the balance: give people space to think, create, and experiment, while ensuring the system stays stable, predictable, and high-quality.

How does RedCore’s management keep teams aligned yet fast?

First of all, we provide clear goals. As I mentioned earlier, we always design for scale from day zero – but you can only do that if you know exactly what you’re building, for whom, and why. We have a very strong business team that understands the market and what needs to be delivered. The technology team works side by side with them, reinforcing them.

Once the goals are clear, we begin small. If you try to build a huge system from the beginning and get it wrong, you create a nightmare: something no one can support, change, or grow. Complexity grows exponentially, and humans don’t think exponentially; we think linearly. That’s where companies often get lost.

So we avoid that by validating early and validating often. We start with small steps, keep a close eye on every direction we take, and confirm that what we’re building is truly needed by the market. When we see that the direction is right, then we scale – and by that point, the foundation is already in place. It’s like preparing a launchpad so that when the time comes, the team can accelerate immediately.

We build block by block and work in iterations. We take a small team – one, two, maybe three people – and let them experiment for a week. We test the idea fast, get quick feedback, and bring it to the business side: “Do you like it?” If the answer is yes, then we continue, still following all the proper engineering practices before anything goes into production.

This constant loop between business and technology keeps everyone aligned. We give feedback, we receive feedback, and we move together. That’s how we stay both fast and coordinated, always ready to scale when the direction is confirmed.

How does automation empower engineers without slowing them down?

When we talk about automation, we’re really talking about optimization at scale. It doesn’t make sense to over-engineer small things, but at the scale we operate, the cost efficiency and speed gains are enormous. And people often assume that big systems and automation automatically slow everything down. For us, it’s the opposite.

The tools we introduce are not meant to tie engineers’ hands with bureaucracy. We don’t force strict guidelines or heavy processes that kill creativity. Our tools exist to help: to prevent mistakes, to collect feedback quickly, and to give teams the shortest possible path from idea to validation.

Here’s a simple example: we start experimenting with a small feature. We build a tiny prototype to see if the idea works. If it’s promising, the next step is testing, pipelines, deployment – all the things that normally take time. In many companies, engineers would try to do all of this manually because “building the tools will take too long.” But with us, the tools are already there. The infrastructure, the CI/CD, the automation – everything is ready to use. Our engineers are essentially customers of this internal platform that supports fast, safe delivery.

We have many different teams that have different great ideas. If one team tries something new and it works better, great – we learn from it. If another team has a different approach because of product specifics or release schedules, that’s fine too. We give freedom to the teams to work, share their experiences, and then scale.

Of course, there are non-negotiables. When it comes to security and data privacy there is zero tolerance. These are areas where strict rules are absolutely necessary. I always tell the security people: everyone should be a little afraid of you, because these things must be perfect. But outside those critical areas, we don’t impose rules that slow teams down. We experiment, gather feedback, adjust, and keep improving.

We’re constantly researching, experimenting, and customizing our automation depending on the product and the market. But when it comes to system design, we don’t reinvent the wheel. We choose globally recognized tools and industry-validated technologies. So yes, we empower engineers with automation and the right tools, built on a solid, modern foundation.

How does culture work for you – is it an achievement, or part of your routine?

Culture is a critical element in balancing speed and stability. Tools and processes matter, but culture is what truly empowers a team and keeps everything together at scale.

For us, culture starts with giving people freedom: the freedom to experiment, the freedom to make mistakes, and the freedom to challenge ideas. We don’t want engineers to be afraid of trying something new. We build a culture where mistakes are acceptable and manageable. If we try something and it doesn’t work, great – now we know better. We learn, adjust, and move on.

We encourage ideas from every level. Some of our most interesting insights come from developers who notice something while working on a small task. They can come directly to me or to the CTO and say, “I see a problem here.” It’s completely okay. A small detail in one corner of the system can become a huge issue at scale, so we listen. That’s how we avoid blind spots.

We also give teams autonomy. Small teams can make their own decisions and experiment in their own ways. If different teams want to do things differently, that’s fine – as long as they validate everything and share their findings. We want people to help each other and to understand that even top engineers have ups and downs. Even senior management makes mistakes. I constantly ask my team: “If I make a wrong decision, tell me.” It’s not about transparency as a buzzword – it’s about behavior. People observe how you respond, and they learn from that.

The biggest mistake any leader can make is demotivating people. We work with intelligent, educated, passionate professionals. They want to contribute. You just need to give them the space to do it. That’s when you see people shine and bring forward brilliant ideas.

As for the question of whether culture is an achievement or a routine – for us, it’s definitely a routine. People often talk about “building a strong engineering culture” as if it’s a success. We treat it as a routine as a process. Culture is the daily interactions between people in an organization. Those interactions change: people come and go, someone has a bad day, someone disagrees with a decision. Culture is shaped every day by how we communicate, how we argue, how we respect each other, and how we resolve differences.

Going to a colleague in the kitchen and asking, “Hey, what do you think about this?” – that’s culture. Anyone can talk to anyone, openly. And when engineers realize they can make a real impact, that they are heard, that they can influence the product — that motivates them. That’s what keeps the culture alive.

How do you balance standards with creative freedom?

The first thing is that we don’t pressure people. We set strict standards only where they are truly critical for the business. Security, data privacy, stability at scale – those areas demand clear rules. But everywhere else, we try not to push people. And when we do introduce a standard or guideline, we listen carefully to feedback. If the team tells us we made the wrong call, that’s okay – we rethink it and look for better approaches.

The second thing is that as the projects grow, the teams scale as well. Even in the design phase, we don’t start with a huge team. I prefer a small group: one key person who leads the design initiative, plus two or three contributors who constantly review, test, question, and give feedback. If three or four people align in one direction, that’s a good signal we’re on the right track. Then we take that proposal to a larger group – people who might use it or need it.. We refine it again based on their input. The idea evolves, but we don’t need to start from the beginning.

Finally, when we have a strong direction, we present it to the entire tech team. And even then – even if top management already supports the decision – it’s completely acceptable for a mid-level developer to raise concerns. Maybe they’ve seen something before, maybe they read an article, maybe they faced a similar issue. We listen, because at scale, one overlooked detail can cost millions.

So once again, balancing standards with creative freedom is about scaling the processes step by step: we start with a small group, validate in small cycles, and then scale the decision up gradually. This approach protects creativity, ensures high quality, and keeps us aligned. And combined with our culture, it makes the process both fast and safe.

The post Scaling With Purpose: RedCore’s Tech Vision Explained appeared first on European Gaming Industry News.