The Scale Trap - A Portfolio Risk View of Games Industry Consolidation

When a games company grows, it is quite reasonable for someone to ask whether all its studios need to do everything separately. Could they share quality assurance, platform support or legal advice? Could a larger group help a small team with work it has never had the money or time to organise properly?

In many cases, the answer will be yes. I have no desire to argue that every studio should build its own finance department just to prove a point about independence. There are good reasons for organisations to grow and for teams to share expertise.

What interests me is what happens when the benefits we expect from one kind of scale are assumed to apply to everything else. A shared localisation service may be useful to several studios. That does not automatically mean the same approval process, creative direction or production rhythm will suit all of their games.

The question is not simply whether a company is getting bigger. It is what is getting bigger, what the change is supposed to achieve and what might be lost along the way.

Some things are easier to share than others

A larger organisation may be able to provide expertise that a small studio would struggle to maintain on its own. Platform submission, localisation, compliance and specialist testing are obvious areas to consider. Shared support can give teams access to knowledge and capacity that would otherwise be out of reach.

That does not make centralisation automatically successful. If a shared QA team is supporting several games, someone still needs to agree how work is prioritised, how the testers learn what matters to each game and what happens when two projects need help at once. The service may be larger and still be harder for a particular team to use.

Creative work presents a different problem. A group can provide funding, access to players and people with excellent judgement. It cannot guarantee that every game will be original or successful simply by adding more studios to a portfolio. Creative direction depends on the people involved, the decisions they make and the conditions that allow them to work together.

There are different kinds of scale mixed up in these discussions. Operational scale concerns the services that support work. Financial scale concerns investment and exposure across the business. Network scale might involve access to platforms, audiences or partners. Creative scale concerns how the organisation supports multiple games and teams. Each can bring benefits, but each also introduces different dependencies and decisions.

What happens when a shared service meets a real project?

Imagine a fictional group with several studios. It decides to create a central QA service so that teams can draw on a wider range of testing experience. On paper, the plan is sensible: studios can get specialist help without each building the same capability from scratch.

One studio is approaching a milestone and needs a particular set of tests. Another has a release candidate arriving at the same time. Both have been told the service will support them, but nobody has settled who decides between the requests or how much flexibility the teams have if priorities change.

At project level, the first producer sees a testing delay. At programme level, the shared service has a capacity and prioritisation problem. At portfolio level, leadership may still see the centralisation as a saving. Each view contains part of the picture. Unless those conversations are connected, the apparent saving may be difficult to judge against the effect on the games it was meant to support.

This is not an argument against central QA. It is an argument for deciding how the service will work, what happens when demand exceeds capacity and how the people using it can raise a problem. Those details are rather important if the service is supposed to make production easier.

The project, programme and portfolio view

I find it useful to look at a proposed change from more than one level. The original table gives a starting point:

Those signals are prompts to investigate, not proof that scale caused a problem. A game can miss a forecast for many reasons. A shared service can encounter delays because it is underfunded, because its priorities are unclear or because the original plan was unrealistic. The useful work is to understand the mechanism rather than put every difficulty down to the size of the organisation.

The flow of information needs to work in both directions. Teams should be able to explain where the new arrangement is helping or slowing them down. Leadership also needs to explain changes in funding, priorities or expectations while the teams still have some ability to respond.

What are we trying to protect?

When a group acquires a studio, it may be buying intellectual property, technology and the chance to make future games. It may also be interested in a team whose trust, working relationships and judgement have developed over years. Those things are rather less convenient to list in a transaction, but they can be important to the work the buyer hopes to support.

If integration removes the people’s ability to make the decisions that made the studio effective, the group should at least understand that risk. The answer will differ by studio. Some teams may welcome more support or a clearer approval process. Others may need particular freedoms to protect their creative work. Neither independence nor standardisation is a substitute for finding out what actually helps.

I would also want to know what happens if the financial forecast behind the plan is wrong. Is there time to adjust investment or scope? Can a shared service be changed if it is not helping? Who can intervene before the organisation is left with a much narrower set of choices?

Questions to ask before scaling

The original article included this assessment. I still think it is a useful set of questions, provided the answers are discussed rather than simply filled in and filed away.

A smaller organisation might answer these questions in a conversation and a short document. A larger group may need more formal records. The right amount of process depends on the decision and the people affected, not on how impressive the resulting pack looks.

Growth can provide resources, resilience and opportunities that individual studios would struggle to create alone. It can also introduce dependencies and distance between the people who make decisions and the people making the game. Both possibilities deserve attention before a restructuring plan is treated as a success.

For more on the project, programme and portfolio approach to risk, see my book, Risk Management for Video Game Professionals, and the Studio Risk Management course.