A former Capcom employee has offered an unusually specific diagnosis of what separates Japanese and Western game production, and it comes down to what a studio’s process is actually built around: creative direction, or a ticket queue.
Speaking anonymously to journalist Lewis Gordon for a piece published at The Ringer, the US-based former employee described “an overemphasis on project management in the West [in terms of Jira], task management that doesn’t necessarily turn into a game,” in remarks picked up by Kotaku.
The distinction being drawn
The comparison is not that Japanese studios lack process. It is where the process originates. As the former employee put it: “Obviously, the director has the final call, but you’re working with them to say, ‘This isn’t going to resonate with players,’ or ‘That’s going to take too long,’ or ‘We don’t have the timeline or budget to do that.’ Whereas in the West, production was more born from project management and Microsoft software development.”
That last clause identifies the lineage precisely. Western game production inherited its methods from enterprise software – sprints, backlogs, burndown charts, ticket hygiene – a toolkit designed for building software whose requirements can be specified in advance and validated against a specification.
Games do not work that way. Nobody can specify in advance whether a jump feels good, whether a boss fight is satisfying, or whether a mechanic that reads well on paper is tedious in the twentieth hour. Those questions are answered by building the thing and playing it, repeatedly, and by someone with authority deciding it is not there yet.
Why the tool becomes the target
Jira attracts this criticism because it makes work legible to people who are not doing it. A well-maintained board tells a producer what is in flight, what is blocked and what shipped. That is genuinely valuable on a project with hundreds of contributors and a hard release date.
The failure mode is that legibility becomes the objective. Work that decomposes cleanly into tickets gets prioritized over work that does not, and the work that does not decompose cleanly is often the work that determines whether a game is any good: iterating on feel, throwing out a system that tested badly, spending three weeks on something that produces no closed tickets and a better result.
A studio measuring throughput will reliably produce throughput. Whether it produces a game people want to play is a different measurement, and it does not appear on the board.
The counterargument
The director-led model has well-documented costs of its own, and it would be a mistake to read this as a straightforward endorsement. Japanese studios have historically shipped projects through schedules that depended on sustained overtime, and creative authority concentrated in one person produces both singular games and unmanageable ones. Western production discipline emerged partly as a response to budget overruns and crunch that project management was meant to prevent.
The record does not support a simple ranking. Western studios have shipped enormous, technically ambitious games on schedule using exactly these methods, and Japanese studios have shipped their share of delayed and troubled projects. What the former employee describes is a tendency, not a law.
Why the complaint keeps recurring
Versions of this argument surface every few years, usually from developers rather than management, and usually in the aftermath of a period of layoffs and cancelled projects. That timing is not incidental. When budgets tighten, process typically tightens with them – more reporting, more granular tracking, more oversight – which is precisely when the gap between tracked work and good work becomes most visible to the people doing it.
The observation that survives the debate is narrower and harder to dismiss than the headline: a task management system records decisions but does not make them. A studio that has substituted the record for the decision has a very organised backlog and no one saying this isn’t going to resonate with players.
That, in the end, is what the former employee was describing – not a complaint about software, but about who in the building is empowered to say a thing is not working, and whether anyone is listening when they do. The tooling is downstream of that question. A studio with the answer settled can run Jira without harm; a studio without it will not be rescued by any board, however well maintained.
