When talking about different management models, it’s common to divide them culturally — by nationality or mindset. The most well-known example you’ve probably heard many times is the difference between “Eastern” and “Western” teams, where the Eastern model is, on average, characterised by higher power distance and higher uncertainty avoidance, while Western Europe tends to have lower power distance and greater tolerance for ambiguity.
However, this is only one way of looking at the issue. In reality, when we talk about different behavioural models, it makes more sense to focus not on nationality, but on stable management patterns shaped by history, market conditions, and the types of organisations involved.
It’s also important to understand that these models don’t have inherent “pros” or “cons.” This isn’t about one system being good and another being bad. It’s about what worked for a particular team in a particular context. Often, the choice of model is linked to short-term versus long-term goals. Both approaches can be effective — the key is the project context.
Today, as dozens of studios shut down and look for ways to reduce costs, teams are increasingly being merged under new titles. As a result, the challenge of successfully blending teams with different management backgrounds has become especially acute.
Why is underestimating a team merge so risky?
Blending two different teams — and failing to do it properly — carries one major risk:
Most blending problems are invisible until metrics start to drop.
In other words, on the surface everything may look fine — people communicate, have coffee together, take smoke breaks, discuss tasks. But the real consequences often appear only two or three months later. And most managers don’t link this to a blending issue, instead attributing it to “performance issues.”
Moreover,
in company mergers, 44% of failed integrations are directly linked to “cultural incompatibility” and friction between teams.
And again, when we talk about “culture” here, we mean a management model — learned patterns of behaviour within a specific system.
That’s exactly why, when blending teams, it’s critical to avoid the common mistakes that tend to occur in this process.
Common mistakes
- Expecting the same style to work everywhere.
- Forgetting that trust and relationships work differently.
- Misunderstanding silence and feedback.
- Different expectations about how decisions are made.
Under pressure from external factors such as releases, milestones, and other deadlines, there is a strong temptation to keep one of the existing models unchanged — effectively forcing one part of the team to adapt to it. Usually the one that delivered results at an earlier stage. This can be a serious misconception.
In such cases, there is a high risk that new team members won’t integrate properly, will start to drop out, and you’ll be forced to hire again, losing both time and budget. For this reason, one of the safest approaches is to build a third culture — derived from the two original ones, rather than simply choosing between them.
The Third Culture
In an ideal world, this third culture takes the best elements from both models and discards what prevents the project from achieving results. But that’s the ideal scenario. In reality, it means something much more practical:
establishing new, clear rules of collaboration within the project and helping all team members on both sides adapt to the changes.
In project management perspective, this is what the third culture looks like. You start with two teams that have different habits, reaction speeds, discussion styles, and approaches to decision-making.
The role of the PM or producer is to invest time in aligning these teams across key indicators — ideally across all of them. Sometimes this means that one part of the team has to consciously give up certain “advantages” — such as speed or a high level of autonomy — in order to align with the other part and reach a shared baseline. Only after that can the team gradually increase pace again, strengthening the whole team rather than just its “dominant” part.
Who is responsible for building the “third culture”?
There are three main levels that can be identified:
n Leadership
At the formation stage, leadership sets new rules of the game. In some cases, it can even be useful to dismantle parts of the old rules — but only if new ones are clearly put in place: defining roles, areas of responsibility, dependencies, reporting lines, approval processes, and decision-making mechanisms. If this isn’t done early on, the project will eventually start to slow down, and the team will begin to “sink” into uncertainty.
HR Department
Their role is to ensure that everyone in the new team — both newcomers and existing members — feels comfortable. This can involve a wide range of tools: welcome packages and relocation support, onboarding sessions, cultural communication training, workshops for managers to better understand each other and align expectations.
Producers/PMs
:::info
Someone may include leads here as well, but I would count them as a part of team
:::
This is the foundational level of team management: day-to-day operations, conflict resolution, and the introduction of new mechanisms and ways of working. It’s this third “building block” that I want to focus on in more detail.
This may sound subjective, but in my experience if there is no day-to-day progress at this lowest level and people don’t know how to work together, efforts from above have limited impact. Stakeholders can change the structure every month, and HR can run any number of trainings — but if basic communication between people isn’t in place, content delivery will stall.
And the opposite is also true: if producers, PMs manage to set up a process where the team can deliver results independently, the project will keep moving even with an imperfect structure above. The team can build temporary workarounds, adapt, find practical solutions — and continue delivering on time.
So how PM can help to “build a third culture” ?
I have a very simple answer –
Give team a task.
Wait, wait — let me explain. I know how it sounds. This isn’t just a task. It needs to meet four key criteria. If your task meets them, you’re on the right track.
A Strict Deadline
Ideally, this should not be an “internal” deadline, but an external one — something that, once announced to stakeholders or players, can no longer be easily moved. For example, an external playtest aimed at measuring specific product metrics (D7, D10, D30 retention) or testing a particular feature.
A Player-Facing Task
This is a crucial addition. In game development, creators want their work to be seen and appreciated primarily by players. Try to choose a task where players can provide feedback — something a developer can later show to friends, point at the screen, and say: “I made this.”
Involves the Entire Team
Regardless of how the team is structured — feature pods, discipline-based teams, strike teams for a specific version — try to find a task that touches everyone and unites the team around a single shared outcome.
Relatively Simple
The task should be simple enough that you could still hit the deadline even with half the team. This serves as a safety buffer in case unexpected issues arise.
The main goal of completing a “not just a simple task”:
Experience of a positive sense of “winning” — completing a shared task together, with relatively low stress, and delivering a result that is tangible in the final build.
Whenever possible, reinforce this with feedback: player comments, metrics, reviews — anything you see, capture it and share it with the team. People need to feel that the work they’re doing is visible and valued.
A Small Example
Imagine you have a department of ten 3D artists:
- 20% from one production model
- 20% from another model
- 40% juniors with no prior industry experience
- 20% experienced specialists, but without experience in the previous models (for example, a lead and a PM)
Here’s what a task for such a team could look like:
Prepare a skin pack for testing a new feature from the META team, where skins are the main reward. The pack should have a consistant visual style and theme, and be delivered to the external playtest master build. The total number of skins to produce is 10.
If conditions allow, try to introduce additional collaboration constraints within the task. For example, split one skin into weapon and body parts: assign the body to seniors and the weapon to juniors. If you have a specialist who usually works on a specific character, don’t give that character to them — give it to a newcomer instead. This creates a natural reason for the newcomer to ask for help, learn details, and seek advice.
Instead of a conclusion
Building a new third culture is a long and often painful process. A PM needs to understand this and account for it in the development roadmap. A producer, in turn, needs to find the right words to communicate this time investment to leadership and explain why it is critical for the project’s goals. Without collaboration at this level, the process simply won’t work.
Most importantly, as a PM, it’s essential to remember that your team is not a set of numbers and graphs in Jira. These are people who will experience stress. At some point, you need to step away from the position of an observer of processes and become part of the process itself. You cannot build a “third culture” without people.
Instead of standing above the team, stand alongside them. Yes, this will take time, and it may feel like “wasted time.” But it pays off fully: if the culture is established correctly, the team will be able to work independently, and you won’t have to constantly put out fires. Based on my experience — everything I’ve described here would have been impossible without the people on my team: their willingness to talk and work through misunderstandings together.
