A lot of companies talk about game development as if a studio is a container full of talent. You put enough designers, programmers, artists, producers, writers, and technical specialists into the container, give them a valuable IP, and eventually a game comes out. If costs become too high, you remove some people from the container. If production slows down, you replace them with contractors. On a spreadsheet, this probably looks reasonable.
The problem is that game studios do not work like containers. They work like systems. Every discipline depends on another. Every proprietary tool carries years of accumulated knowledge. Every pipeline is held together by relationships, undocumented decisions, technical compromises, and people who know why something was built in a particular way. When those people are removed, the company does not only lose headcount. It loses connections.
That is the real concern behind Microsoft’s latest Xbox restructure. Xbox has announced plans to eliminate approximately 3,200 roles throughout the 2027 financial year, including around 1,600 immediate cuts. Leadership says the goal is to create a flatter organisation built around the people making games. However, developers who spoke anonymously to Game Developer argue that many of those makers, and the knowledge connecting their teams, are the people being removed.
A Studio Is Not A Headcount Problem
Headcount is one of the easiest things to measure inside a company. You can see how many people work at a studio, how much they cost, and how those numbers compare with revenue. What headcount does not show is how those people connect. Two teams containing the same number of developers can have completely different production capabilities depending on the experience, specialisations, and relationships inside them.
A technical artist who has spent six years working with an internal engine does not only possess technical-art knowledge. They know which tools are stable, which import problem appears under very specific conditions, and which innocent-looking pipeline change will break twenty other things. A designer responsible for enemy AI does not only understand AI. They understand how it connects with combat, animation, level geometry, encounter design, difficulty, and performance.
Removing one of those people does not remove one isolated unit of production. It changes everything that depended on them. This is why a studio reduced from 300 people to 200 is not automatically two-thirds as capable. Depending on which connections are lost, it could be far less capable than that.
Headcount vs Production Capability
| Headcount View | Production System View |
|---|---|
| Five positions were removed | Five networks of knowledge were disrupted |
| Another developer can fill the role | A replacement may require months of training |
| The design department still exists | Critical design specialisations may be missing |
| The project remains in production | Scope, quality, and schedules may have changed |
| Contractors can cover the difference | Contractors still need tools, context, and support |
The number of people left inside the studio does not tell you whether the studio still has the connections required to make the game.
Insider Tip: Before removing a role, map the tools, systems, decisions, and people that depend on it. A position can look isolated on an organisation chart while sitting at the centre of the actual production pipeline.
Institutional Knowledge Is Part Of The Technology
Studios often think of their technology as engines, repositories, tools, documentation, and source code. Those things are important, but the technology also exists inside the people who understand how to use and change it. An engine sitting in a repository is not the same as a team capable of maintaining it.
Game Developer’s report contains serious claims about the impact of the cuts at id Software. Sources alleged that engine support, technical art, VFX, AI, and gameplay-design knowledge had been heavily affected. Microsoft disputed one characterisation of the id Tech team, stating that dozens of people continue working on the engine across multiple locations. That clarification matters, but it does not remove the wider risk created when specialists with years of experience leave at the same time.
A new developer may understand programming, art, design, or production extremely well and still need months to learn the particular logic of an internal engine. They need to discover how the tools behave, where the exceptions are, and why earlier decisions were made. Some of that knowledge can be documented. A lot of it only appears when something goes wrong and one person in the room remembers dealing with the same problem five years ago.
Visible Technology vs Institutional Knowledge
| Visible Technology | Institutional Knowledge |
|---|---|
| Source code | Why the code was structured that way |
| Engine documentation | Which documented processes no longer work |
| Art pipeline | Where assets regularly become blocked |
| Design tools | Which changes create unexpected consequences |
| Production schedule | Which dependencies make the schedule possible |
A company would not delete random parts of its build system and assume production could continue because most of the files were still there. Removing institutional knowledge creates the human version of the same problem.
Insider Tip: Treat specialist knowledge as production infrastructure. If losing one person makes a tool, pipeline, or system difficult to maintain, that dependency needs to be identified before a restructure begins.
Good Work Needs A Visible Consequence
A coherent system teaches people how their actions affect outcomes. If a player learns the rules, develops a strategy, and performs well, the game needs to acknowledge that behaviour. The reward does not always need to be victory, but there must be a readable relationship between the action and the consequence.
Workplaces create the same kind of relationship. Developers are asked to ship successful games, improve metrics, solve production problems, support their teams, and develop specialist knowledge. The implied rule is that this behaviour contributes to the future of the project and the stability of the team. When people achieve those goals and are removed anyway, the rule becomes difficult to understand.
Bethesda previously described Doom: The Dark Ages as the biggest launch in id Software history after it reached three million players. The reported layoffs arrived around the launch of a major expansion, with affected workers claiming they had not been given clear criteria explaining what success would have looked like internally. That is how one developer reached the brutal conclusion that “good work is not going to save your job at this company.”
Readable Success vs Unreadable Success
| Readable System | Unreadable System |
|---|---|
| Teams understand the goals | Success criteria remain unclear |
| Performance affects investment | Performance appears disconnected from security |
| Metrics have visible consequences | Metrics are discussed but do not protect the team |
| Problems can be corrected | Teams do not know what they could have changed |
| Leadership decisions follow known priorities | Decisions appear arbitrary from inside production |
When employees cannot connect their work to the consequences they receive, they stop trusting the organisational rules.
Insider Tip: Teams should be able to explain what success means before release. If the definition only becomes clear after a project or team is cut, it was never a useful production target.
Flatter Is Not The Same As Stronger
There is nothing inherently wrong with reducing unnecessary management layers. Game development can become painfully slow when decisions travel through too many people. Ownership becomes unclear, teams wait for approval, and information gets filtered every time it moves up or down the organisation.
In its official announcement, Xbox said some work passed through as many as fourteen management layers. The company plans to reduce that number to no more than five, and sometimes three, while building the organisation around makers, player-coaches, and directly responsible individuals. On the surface, that could create clearer ownership and faster decision-making.
The danger is confusing a flatter organisation with a thinner one. A flatter organisation removes unnecessary distance between decisions and implementation. A thinner organisation removes the implementation capacity itself. If specialists disappear and the remaining developers are expected to wear several hats, the company may reduce management complexity while dramatically increasing production complexity.
Flatter Organisation vs Thinner Organisation
| Flatter Organisation | Thinner Organisation |
|---|---|
| Decisions happen closer to the work | Fewer people are available to do the work |
| Ownership becomes clearer | Responsibility becomes overloaded |
| Unnecessary approval stages disappear | Specialist knowledge disappears |
| Makers gain autonomy | Makers inherit additional roles |
| Communication becomes faster | Teams have less time to communicate |
Removing management layers can improve a system. Removing the people who understand and operate that system can break it.
Insider Tip: Measure a restructure by the decisions the team can now make, not only by the layers that were removed. Fewer managers mean very little if the remaining developers no longer have the capacity to act.
Uncertainty Changes How Teams Behave
Microsoft has said that approximately 1,600 roles are being removed immediately, with another 1,600 reductions expected throughout the financial year. That means people remaining inside Xbox studios may continue working while knowing further cuts are coming. Even if their role survives the first round, they cannot assume the system has stabilised.
This uncertainty changes behaviour. Developers become less willing to take creative risks. People begin protecting their individual positions. Problems may be softened before they reach leadership because nobody wants their project to look unstable. Experienced staff can leave voluntarily rather than wait to discover whether they are part of the next round.
Psychological safety is often treated like a soft cultural benefit. In creative production, it is part of the development pipeline. Teams need to expose unfinished work, challenge assumptions, report failures, and admit when they do not know something. A frightened team hides problems, and hidden problems become expensive problems.
Stable Team Behaviour vs Unstable Team Behaviour
| Stable Team | Unstable Team |
|---|---|
| Problems are raised early | Problems are hidden or softened |
| Developers take creative risks | Developers avoid anything that might fail |
| Knowledge is shared | Knowledge becomes personal protection |
| Long-term systems are improved | Short-term survival becomes the priority |
| Teams plan around the project | Individuals plan around possible layoffs |
A company may save money by reducing its workforce while quietly increasing the cost of every decision made by the people who remain.
Insider Tip: Team confidence is not separate from productivity. If developers are spending energy predicting the next restructure, that energy is no longer going into the game.
The Brutal Truth
According to Maryland’s official dislocation records, 213 positions were affected at ZeniMax Online Studios and another 166 at ZeniMax Media. Both were recorded as mass layoffs with no recall. Those numbers represent people losing their income, stability, colleagues, and projects. That human cost should not disappear behind a discussion about production efficiency.
Companies sometimes need to restructure. Projects end, markets change, budgets fail, and no studio can promise that every role will exist forever. But leadership is still responsible for how those decisions are made, how clearly they are communicated, and whether the production system left behind can actually support the company’s stated goals.
Xbox says it wants a flatter organisation built around makers. Developers claim many makers and implementers have been removed. If the company wants people to believe in the reset, the consequences need to reinforce the message. Otherwise, the organisation is teaching its teams that performance, experience, and specialist knowledge have very little relationship with what happens next.
Insider Tip: A restructure has failed if the spreadsheet improves but the remaining team can no longer explain how the next game will be made.
Final Thoughts
A game studio is a living system. Its games emerge from the interaction between specialised people, technology, experience, communication, and trust. If leadership only measures the visible cost of maintaining that system, it will miss the invisible cost of breaking it.
Great games do not emerge from IP ownership alone. They do not emerge from an engine sitting inside a repository. They do not emerge because an organisation chart still contains boxes labelled design, art, and engineering. They emerge because experienced people understand how all those pieces connect.
Once those connections are gone, rebuilding them is not as simple as hiring the same number of people later. The job titles may be replaced. The institutional knowledge, relationships, and trust will not return so easily. A studio is not a container full of interchangeable talent. It is a system, and systems fall apart when you remove the connections that make them work.
Please like, share, and comment if you enjoyed this article AND…
Need help applying these concepts to your game? Most games don’t fail because of bad ideas. They fail because the systems don’t work together to evoke immersion.
> Work with me:
https://thedesignlab.blog/services/
> Or go deeper into this framework:
Register for my upcoming book – Immersive Design Framework – below and get a second book, now, free!
Grab Myles’ FREE ebook now and find 15 indispensable design patterns that will equip you to craft exceptional Web3 gaming experiences. We’ll also notify you when his new book on immersive design is out!