The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

“The goal is to foster an environment where engineers don’t just go, ‘Okay, this is built, let’s push it to production.’”

As customers’ expectations evolve, companies have to keep up with them or risk getting left behind. Nowhere is this more evident than in the gaming industry, where companies regularly poach employees with domain knowledge from one another.

Coming in with vast industry experience, Cristina gave us valuable and tested advice on how to:

• grow specific domain knowledge even when it’s nearly impossible to hire people with relevant industry experience,
• empower employees to learn and grow themselves, and see the value of cross-functional collaboration.

About Cristina

First full year at Casumo

Eric Ignasik: Hello, Cristina. You joined Casumo back in 2023 – what has been your experience so far?

Cristina Turbatu: Hi, Eric, thanks for having me.

I joined at a turning point for the company. We had to make a lot of tough choices quickly and with little information, to ensure that the company was on the right path financially. It was difficult for everyone, especially the employees that had to be let go, and I did my best to be respectful towards them. Having a transparent and helpful team of C-levels with experience in growing turnaround companies helped a lot.

We left the danger zone, and 2024 was stable – no more scaling down. We focused on building a strategy to move forward. We looked for the most optimal organizational structure, technologies worth investing in, and ideas for security and platform engineering. 

Now, in 2025, we’re executing based on the foundation for growth that we built last year.

As CTO, one of the big questions for me was, “how can we make sure that everyone at the C-level and on the board sees what our department does?”. I think many CTOs have this challenge. 

It usually starts with technical KPIs. However, it’s not clear how they affect the bottom line, and they don’t help to explain why you sometimes change priorities. You need to have separate KPIs that make it easy to translate your decisions to people without technical expertise so you can explain why you took two weeks to find a bug.

Having domain-trained developers may help in translating such decisions for the rest of the organization.

In your interview from Andersen’s event in Malta, you said that some companies might opt for talented developers without domain experience and invest in training them on the job. When is this the right approach? 

The competition for talent with industry knowledge is fierce. Poaching is a regular occurrence. If you want to grow, you’re usually left with one option – bring in people with the right attitude who are willing to challenge themselves. You can look in other highly-regulated domains with similar challenges, like crypto, finance, or healthcare.

With 100% gaming experts on board, it can be harder to innovate. A diverse team with knowledge about different industries can expand your perspective and generate more disruptive ideas.

This approach doesn’t work for people who design your architecture. They should come with experience in gaming. You have high volumes of players to deal with, but also spikes that happen when you run a promotion, when people receive their salaries, or around major events that drive usage. The architecture needs to be both flexible and robust to handle such performance challenges.

Product-oriented development – the concept

Let’s talk about product-oriented development and the impact that domain knowledge has on the process of building software products. Ideally, all stakeholders – including developers – should collaborate and not just reside in their respective silos. 

Visibility, transparency, and borderless cooperation seem vital these days, would you agree?

Definitely, silos don’t work anymore. Customer expectations have changed. People have less patience and are used to things working on the spot. At Casumo, we structured robust teams that have ownership over entire player flows. This helps them understand and care about the bigger picture.

The visibility has to go both ways. Tech needs to transparently explain what they’re building and what they care about, and so should other parts of the organization.

It should be easy to understand the KPIs of all departments, why they’re important to the business, as well as the restrictions they’re dealing with, so that everyone can contribute to moving those KPIs.

You need to measure KPIs, too. This way, the business can see what KPIs your actions are influencing. It also provides engineers with a sense of pride because they know exactly how their work is affecting the entire company.

Growing product knowledge – the mindset

It feels like you treat cross-functional collaboration very seriously. Can you go into more detail about how it works at Casumo?

The goal is to foster an environment where engineers don’t just go, “Okay, this is built, let’s push it to production.” We want them to consider things like content overhead, promotions that they might interact with, marketing initiatives they should be aware of, other teams they should inform, and so on.

Likewise, if marketing is running campaigns to bring in new players, we want developers to know early on so they can prepare for spikes and scale the system.

It’s important to create that culture now, while we’re still a moderate-size company.

I know about your Voice of the Customer initiative, which seems relevant to creating that very culture. Can you tell us more about it?

Voice of the Customer is a monthly report created by our customer service department. It provides visibility into customer feedback, requests, complaints, and praise. Everyone is made aware of direct customer feedback. We all learn from it and it helps us improve the products, services, and support we deliver.

Quantitative metrics aside, our users are driven by emotion, so it’s like our emotional KPI. Understanding how players interact with our product, the friction they experience, how the changes we make affect them – it’s very beneficial.

Growing product knowledge – the practices

Let’s discuss specific practices. I talked to a manager of a company from the healthcare domain that had their developers actually sit in an ambulance to learn more about the product they developed.

I know that you use various methods at Casumo, too. Do you apply similar methods?

At this moment, we’re in the process of brainstorming ideas. One of them is to create company-wide self-audits where people from different departments would use the platform and document their interactions for us to learn from.

To better understand the player experience, we’ve implemented tools such as synthetic monitoring or automation tests. We’re currently working on real user monitoring to detect and solve issues before they even reach customer support.

Another thing I’d love to implement at Casumo is to have people from other departments spend some time working on support tickets. I’ve done it as a QA automation specialist at other companies, and it was an eye-opening experience. You see what it’s like to deal with frustrated customers, and understand exactly how a buggy release affects them.

To this day I remember opening my laptop and seeing 20 messages with complaints. They just wouldn’t stop coming in. It takes a unique type of person to handle the stress of dealing with it day in, day out. It’s humbling and educational for people from other departments to experience it. 

Letting employees do someone else’s job for a day helps them see how their work influences others, it doesn’t have to be limited to customer support.

Once you have the data, what methods do you use to integrate it directly into your work and the product?

We try to keep things simple. However, we’re a 12-year-old company that started by doing one thing very well and expanded into many others at high speed. We operate in a lot of markets, so we need some processes to handle all the different regulations.

One of them is an ideation process that allows people from different departments to bring product ideas. We involve stakeholders from all environments and make sure they’re listened to. 

Then, the product team defines their needs more precisely so we can evaluate them at a high level and see how much effort they require. We prioritize all the ideas through this process, it’s part of our roadmap planning. If something can’t happen in this quarter, it goes back to the prioritization process for the next one.

Speaking of cross-functional cooperation, the idea of an internal single source of truth as a way to keep everyone on the same page comes up a lot in our interviews. Do you see value in that?

One of the solutions we explored as a proof of concept was an intranet for HR and documents. With remote employees in multiple different countries, a lot of questions come up that could be handled in one place.

We keep exploring new options. Just yesterday, I found out that some companies are building well-integrated AI intranets for similar purposes.

With generative AI and agents on top of role management systems, you can have a solution that understands the context of the user and provides them with answers in a secure and personalized way.

I’m looking forward to such solutions becoming mainstream because they could save a lot of time – especially during onboarding since it’s all about teaching employees and answering their questions.

That’s an interesting idea for the not-so-distant future, but what about the present? When onboarding new hires, does knowledge exchange happen organically, or does it take a specific process to handle?

There’s no perfect solution because everyone is different. Especially in engineering, people are often not great at communication. I used to be one of them – when I first moved to Western Europe, I believed that asking questions made me look stupid.

What we do have is a great system between tech leadership, QA, and HR. When we onboard someone, everyone knows what they’re supposed to do because we have a simple manual to work with. It’s called The Manager’s Handbook, and it outlines proven steps to onboard new hires as quickly as possible. 

We also assign everyone a buddy for onboarding. Shadowing more experienced team members helps new hires learn how to deal with the pressures of maintaining the platform.

During the first month of onboarding, we also have presentations from all departments where they explain their inner workings and ways of contacting them.

What about people who find it difficult to work with other departments? What kind of feedback would you give them, and how would you help them adapt to cross-functional collaboration?

Sometimes you have a superstar that delivers immense value, but prefers to work alone and avoids teaching others. This can be good for a smaller company, but in our situation, we need to mitigate risk. Having just one person who understands a crucial part of the product is a big problem for us.

We do our best to show people that working with others is an opportunity to develop themselves, grow, and become even more valuable. It’s about visualizing the domino effect of benefits they can generate for the whole company if they open up more. What works best for us is showing how much less stress and burnout they will feel if they collaborate more.

A lot of people struggle with delegating because they want things done exactly the way they’d do it – but, just because something is done differently, doesn’t mean it’s bad.

Empathy is important, because this process can lead to people leaving the organization. When that happens, at least you can be sure that you did all you could to create a healthy working environment for that person.

When the process succeeds, you get to a moment when it clicks, and these employees become true superstars that have a positive influence on the entire engineering team.

Let’s go back to technology. I know that you believe that AI can create a more personalized experience for platform users in the igaming sphere. Do you think that the data processed by AI will soon become essential in understanding user behavior and becoming truly customer-centric?

100% yes.

There was a time when not everyone had a website, not everyone needed an online shop, and it was fine for a while. Now, if you don’t have a website or social media presence of any kind, it’s as if you don’t exist.

I can’t predict exactly how AI will change the world even in the next five years, but I’m confident it will become essential. At some point, you will either create intelligent data domains within your company or get left behind – but we’re not there yet.

As leaders, it’s our job to translate changes into tangible benefits for our teams. You want to tell people, “This solution saves you X hours per month that you could spend building feature Y from the roadmap, which you postponed at the moment.” If you can shift the perspective, adapting to new tools will become as important as releasing new features to clients.

General advice

Let’s sum things up. Given all we’ve talked about, what’s your main advice for leaders who want to boost domain knowledge within their organization?

I always tell everyone that investing in your people is important. After all, we all spend most of our weeks at work.

You don’t want people to dread the moment when they’ll have to open their laptop again on Monday, you want them to be excited to start the week. If you create such an environment, your team will be happy and eager to learn new things.

I also recommend fostering a culture of transparency and communication. I’d rather over-communicate than spend time deciding whether person X really needs to know data point Y. Communicate, learn their interests, foster those interests, and set your people up for success. 

Both complaining and good vibes are contagious. When you find what makes someone tick at work, the enthusiasm that comes out of it is very rewarding to you as a leader, and it benefits the entire organization. 

Resources

One last thing. What resources (podcasts, books, websites, etc.) would you recommend to leaders who want to grow specific product knowledge in their organization?

I highly recommend Tech Manager Weekly, which aggregates a large amount of information from various sources. CTO Academy is great for a growing CTO or one that is transitioning into a more strategic role. For keeping up with all the daily details, I recommend Hacker News.

I also follow some other interesting CTOs on LinkedIn that I admire or can learn something from. One of them is Irina Stanescu.

What’s next? 4 tips for CTOs to grow domain knowledge

Cristina knows how hard it is to only hire people with specific domain knowledge in software development. Throughout her career, she has developed a unique approach to gaining domain knowledge in a particular industry in other ways:

• understand which roles require new hires to come with domain experience, and which don’t – having a diverse team with experience in different industries is an advantage, but roles like System Architects should have domain expertise from the get-go.
• break down silos and create two-way visibility – it should be easy for engineers to understand the goals and pains of other departments and vice versa.
• don’t overlook qualitative metrics like customer feedback – regularly making everyone aware of direct customer feedback helps all departments understand the customers and improve the product,
• create space for all departments to bring product ideas – prioritizing the needs of different teams is difficult, and you’ll have to make some ruthless choices, but it ensures that the needs of stakeholders from all areas are heard and seen.

Remember, it’s better to overshare than to hide information from your employees. Lead with transparency, make your work visible to all, and request the same approach from other departments.