Chet Faliszek Says Giant Game Development Teams Don’t Automatically Work

Adding people to a game can sound like the simplest possible solution: bigger worlds, sharper graphics, more quests, faster patches—just hire more developers. Chet Faliszek, a former Valve writer who worked at the company for 12 years and is credited as a writer on Left 4 Dead, does not buy that logic.

In a recent video response to the perennial question of why Valve does not simply hire more people, Faliszek argued that massive development organizations can be counterproductive. His basic position is not that games should be made by tiny groups regardless of ambition. Rather, he believes there is a point at which a growing headcount creates an expensive coordination problem instead of giving a project useful momentum.

“These giant teams just don’t work,” Faliszek said, while allowing for exceptional productions such as Grand Theft Auto VI, where the sheer scale of the undertaking may demand an enormous number of contributors. The key distinction is important: a huge team may be necessary for a particular target, but necessity is not the same thing as efficiency, nor is it proof that every studio should pursue blockbuster-sized staffing.

The real production bottleneck: decisions, not just assets

Faliszek’s sharpest observation concerns why game projects take so long. In his view, delays are often less about a team continuously building things and more about the time consumed by indecision and backtracking.

Backtracking, in development terms, means revisiting work that was thought to be settled. That might involve changing the direction of a feature, rebuilding content around a new design choice, revising systems that no longer fit the game’s goals, or replacing work after a shift in leadership or priorities. The more parts of a game that depend on a decision, the more work can be affected when that decision changes.

That is why raw staffing totals can be misleading. More artists can produce more art, more programmers can work on more technical tasks, and more testers can examine more builds. But none of that automatically makes a team better at deciding what should be in the game, resolving disagreements quickly, or keeping every discipline aligned as the project changes.

Faliszek put it plainly: the factors that consume time are “indecision” and “backtracking,” rather than production itself. It is an argument against treating development like a factory line where output rises neatly with every additional hire. Games are interconnected software, art, design and audio projects. Every extra hand needs clear priorities, usable feedback and an understanding of how their piece fits the whole.

Why fidelity can drive headcount upward

Faliszek also discussed the industry’s pursuit of graphical fidelity. He did not argue that high-end visuals are inherently a mistake. Instead, he noted that chasing that level of detail requires much larger teams and questioned whether the results always provide enough value for the cost.

Fidelity is a broad term in games, often covering the visual detail, animation quality, environmental complexity and technical polish intended to make a world feel more realistic or more richly realized. A higher-fidelity target can mean more unique assets, more detailed materials, more animation work, more lighting considerations and more technical demands. Those needs can ripple across production.

Faliszek recalled an artist at Ubisoft telling him the publisher hired only “top artists,” while the total described was roughly 3,500 people. He also said Valve had experienced its own form of bloat around fidelity-focused work. His concern was not talent; it was whether an organization’s size, expense and complexity were producing enough meaningful improvement in the final game.

That is the practical question behind his “bang for your buck” remark. A team can make an impressive game and still be structured inefficiently. A company can employ highly skilled people and still lose time if those people are waiting on approvals, receiving conflicting direction or creating material that has to be reworked later.

Left 4 Dead 2 as Faliszek’s counterexample

Faliszek’s own reference point is Left 4 Dead 2, which he said was made by 45 people. He does not believe the game would necessarily have been improved by expanding the team tenfold to 450 people.

That comparison does not mean a 45-person group can make any kind of game with the same timetable or scope. It instead illustrates his larger claim: team size should follow the actual needs of the project, not an assumption that larger automatically means better. A focused game with a coherent design may benefit more from a small group that can communicate directly than from an enormous organization built around broader ambitions.

Faliszek still emphasized that games need “oomph” and “weight” when they are released. In other words, he is not arguing for low-effort output or reducing every project to the smallest possible form. He is arguing that impact can come from a tightly coordinated team with a strong shared direction, rather than from sheer personnel volume.

That distinction matters in a period when players often see staffing numbers as an easy shorthand for a game’s expected scale. Headcount can indicate investment, but it does not reveal how often a project changed direction, how much work was discarded, or whether teams were able to solve problems before they spread into multiple departments.

What communication costs look like inside large teams

Large teams face a problem sometimes called coordination overhead. This does not mean people are not working. It means that as more people and specialties join a project, more effort is required to share decisions, review work, resolve dependencies and ensure that each part of the game remains compatible with the rest.

For example, a design change can affect art, engineering, animation, sound, testing and production planning. If the change is not clearly communicated or is interpreted differently by different groups, the project can generate inconsistent work that must later be reconciled. That is the kind of cost Faliszek is describing when he talks about backtracking.

A smaller team does not eliminate these issues. It may, however, allow people to speak more directly and spot misalignment earlier. Faliszek’s preferred setup is people working in the same room, or at least participating closely through a shared call. The point appears to be immediacy: decisions should be visible, discussion should be accessible and contributors should not feel detached from the process that determines their work.

Faliszek’s concern about remote work

Faliszek was similarly critical of remote-work arrangements when they create what he called a “whisper network.” His concern is that informal conversations and fragmented communication can leave people learning about major decisions after the fact. In that environment, he suggested, contributors may feel unheard and become “downwind” of decisions already made elsewhere.

It is worth separating the criticism from a blanket claim that remote work cannot function. The comments presented here identify a risk: communication has to be designed deliberately, especially when teams are distributed. A remote team may use meetings, written decision records, accessible planning tools and clear ownership to prevent vital context from disappearing into private conversations. Faliszek’s argument is that proximity—or an effective substitute for it—helps teams preserve the shared understanding needed for fast, confident decisions.

His point also applies beyond a home-versus-office debate. An in-person organization can still have poor communication, siloed departments and unclear authority. A remote group can still be deeply collaborative. What Faliszek emphasizes is the cost of being excluded from the conversation, whatever form the workplace takes.

Delays show how handoffs can complicate a project

The development histories of Dead Island 2 and Vampire: The Masquerade - Bloodlines 2 show why staffing alone cannot explain a long wait. Dead Island 2 took nearly a decade to launch after moving among three studios. Bloodlines 2 arrived 21 years after the original game and changed developers along the way.

Those examples are not evidence that every delayed game has the same problem. They do underline the broader point that a project can lose time through transitions, changed stewardship and altered direction. When a game changes hands, the incoming team may inherit plans, technology, assets and expectations that must be evaluated before it can move forward. Work can continue, yet progress toward a finished release can remain uneven.

This is why Faliszek’s position is more substantial than “small teams good, big teams bad.” He is describing an organizational challenge. A team needs enough people to fulfill its ambitions, but it also needs a structure that makes choices, preserves context and limits the amount of work that must be redone.

What this means for Valve and players

For people asking Valve to staff up, Faliszek’s answer is effectively that hiring cannot be judged as an automatic cure for a lack of releases or updates. A bigger payroll does not guarantee a faster game, a better game, or a more decisive organization. It may even create the management burden that slows work down.

That perspective is especially notable coming from someone associated with a studio often discussed in terms of its comparatively small employee base and its major games. The example of Left 4 Dead 2 gives the argument a concrete scale: 45 people, Faliszek said, were enough to build the game, and multiplying that group by ten would not have made the outcome inherently stronger.

It also offers a useful lens for following current PC development. Projects can be ambitious without using mega-studio staffing, as the broader PC release conversation around Dear Passengers reaching Steam’s No. 3 wishlist spot illustrates. Wishlist attention, like team size, is only one visible signal; the important work remains translating an idea into a finished game with a clear direction.

Faliszek’s argument leaves room for the genuine exceptions. A production on the scale of Grand Theft Auto VI may require an immense workforce. But the exception reinforces rather than erases the question: what does a given game truly need? For many projects, the better answer may be fewer layers, clearer decisions and a team that can hear one another before a change becomes months of rework.