What is a remote game development operating model?

A remote game development operating model is the set of principles, decision rights, handoff protocols, and trust structures that determine how work moves across a distributed team. It is distinct from remote work policy, which governs where people work. Studios that treat remote work as a location policy without redesigning how decisions, documentation, and handoffs function will encounter the same bottlenecks as an office team, compounded by time zone gaps. An effective remote operating model treats geographic distribution as a production input to design around, not a constraint to manage.

How do you use time zones as a production asset in game development?

Time zones become a production asset when the team is structured so work can advance across regions without a coordinator. This requires four things: QA coverage designed so verification can happen in a later time zone rather than waiting overnight, decision framing clear enough that someone in a different region can move a question forward, sequential regional coverage that reduces calendar latency, and stakeholder coverage that treats platform holders and partners in other time zones as addressable during their business hours. Super Evil Megacorp applied this model across 15 countries and 11 time zones while shipping TMNT: Splintered Fate across 15+ SKUs.

Why do studios fail at remote work even with good tools and processes?

Studios fail at remote work when the operating model is still designed for an office. The habits that make office studios function -- ambient awareness, hallway escalations, decisions that move because the right people are in the same building -- become bottlenecks when the team is distributed. A Slack message nobody sees for six hours replaces a two-minute hallway conversation. Process improvements like better handoff notes and async norms create the conditions for distributed work to function, but they cannot substitute for a culture where people trust that their judgment is sanctioned to act without a coordinator present.

What does six years of running a fully distributed game studio teach you about remote operations?

Six years of running a fully distributed studio across 15 countries taught that the operational problems attributed to remote work are almost always operating model problems. The studios that struggle with distributed teams typically have not redesigned how decisions move, how ownership transfers across time zones, or how trust gets built in the absence of physical presence. The teams that work well at a distance are not better at remote work -- they have built operating models that treat their geographic shape as a production asset rather than a constraint, and they have invested in cultural infrastructure that lets work move without anyone pushing it.

How did Super Evil Megacorp manage distributed QA across time zones for TMNT: Splintered Fate?

Super Evil Megacorp structured its QA team across North America, South America, and the UK so that verification work could continue after the North American team's end of day. When a release-blocking bug fix landed too late for North American verification, the UK-based QA Lead ran a preliminary check during his normal morning hours. By the time the Canada-based QA Analyst opened Slack the next morning, the question was not whether the fix worked but whether to submit that day. This outcome was not coordinated in the moment -- it resulted from explicit operating principles taught directly to the team through one-on-ones and team meetings.

The Hidden Work of Remote Game Development

Q: How do you build trust in a distributed game development team?

Building trust in a distributed team requires making ownership explicit before it becomes necessary. Team members need to know that acting on their judgment across time zones is part of the job, not an exception to it. This means naming the expectation directly in one-on-ones and team meetings, framing timezone coverage as a capability to develop, and creating conditions where people in handoff positions feel sanctioned to advance work rather than waiting for the primary owner to wake up. The receiver's trust -- confidence that their judgment is actually authorized -- is harder to build than the handoff process itself.

The Hidden Work of Remote Game Development

by Craig Wells, Vice President of Operations, Super Evil Megacorp

On a Wednesday in late July, a blocking bug surfaced in TMNT: Splintered Fate. Players who tried to change the game’s language couldn’t dismiss the menu afterward. If they tried to select a second language to get out of it, the game crashed. The Canada-based QA Analyst flagged it as a release blocker. The Director of Production agreed it had to be fixed before the patch could move. A Brazil-based Senior Engineer committed a fix at 3:23pm PT, too late to kick off a new build and verify it was working for the North American team.

In a studio where everyone is in the same office, that’s a full day lost. Verification doesn’t start until the next morning. Results come back in the afternoon. Standard submission best practices mean you don’t push a patch on unverified results, so the release slips by a day. Instead, the UK-based QA Lead came online, ran a preliminary check across his available platforms, and confirmed the fix was working. By the time the Canada-based QA Analyst opened Slack on Thursday morning, the question wasn’t “is this fixed?” It was “do we submit today or hold?”

Nobody coordinated this in the moment. The team was built to work this way.

Distance Isn't the Problem

Remote work doesn’t fail because people are remote. It fails when the operating model is still built for an office.

Office-based studios run on a set of habits so embedded they’re nearly invisible: ambient awareness of what’s happening across the room, hallway escalations that resolve in two minutes, decisions that move because the right people happen to be in the same building at the same time. Those habits aren’t bad. They’re just local. Distribute a team across time zones without redesigning how work actually moves, and those same habits become bottlenecks. The right person isn’t in the building. They’re asleep. The hallway escalation becomes a Slack message nobody sees for six hours. The decision waits.

It’s easy to mistake that friction for a remote work problem. In most cases, it’s an operating model problem.

Time Zones as a Production Asset

A distributed team doesn’t have to compress all the day’s work into one region’s working hours. The point is not that anyone works longer. It is that the work can keep moving across regions when the operating principles are built around the full shape of the team: where people are, when they’re online, and what they are trusted to advance.

The coordination problems that come with distributed work aren’t unique to remote teams. Unclear ownership, unclear priority, not knowing who to hand something off to: these exist in every studio. In an office, they resolve quickly because everyone is in the same place. Distributed across time zones, the same problems can cost hours or days. A well-designed distributed operating model addresses each of them directly.

In our experience, at least four coordination problems have clear solutions when the team is built to use time zones as an asset rather than work around them. There are likely others.

QA coverage. A fix that lands in the late afternoon in the Pacific time zone doesn’t have to wait until the next morning to be verified, provided the QA team coming online next has enough context, access, and confidence to run the check without waiting for someone to sanction it.
Decision turnaround. Questions that go unresolved at end of day in one region don’t have to sit overnight if they’re framed clearly enough for someone in a different region to move them forward. The team can wake up to a decision made, not a decision pending.
Deadline compression. Sequential coverage across regions reduces calendar latency without stretching any individual. The same amount of work gets done; it just doesn’t stack up behind a single region’s working hours.
Stakeholder coverage. Platform holders, licensors, and publishing partners in other time zones stop being a scheduling headache when regional coverage is designed into the operating model rather than treated as a lucky coincidence.

None of these are automatic. Each one requires that the people in the handoff position have what they need to actually move the work, not just access to it.

Process Builds the Relay. Trust Makes It Run.

Here is where a lot of remote-work thinking stops short. It treats the problem as purely a process one: better handoff notes, more disciplined JIRA hygiene, clearer async norms. These tools are important and necessary because they create the conditions for distributed work to function. However, process alone isn’t enough to make it work without a coordinator.

Trust is what allows that process to work without someone directing it, and it has to run in both directions. The person handing off has to trust that someone else will pick it up. The person receiving it has to trust that their judgment is actually sanctioned, that they are not merely watching the work until the “real” owner wakes up. That second kind of trust is harder to build and more important. Many leaders say they trust their teams, but their operating model still teaches people to wait.

Building that trust is a cultural problem, not a process one. The leader’s job is to make distributed ownership feel normal before it becomes necessary: to name the principle explicitly, repeat it in the right rooms, and make sure the team understands that acting on their own judgment across time zones is part of the job, not an exception to it. In practice, that means talking about it directly in 1:1s and team meetings, framing timezone coverage as a capability to develop and actively encouraging the team to find opportunities to use it. This is how we made the expectation explicit within the QA team.

That is why the language bug worked itself out: the expectation had been set long before anyone had to act on it. Before the July incident, the QA group had transitioned to new management. The operating principles didn’t transition with a handoff document or a checklist. They transferred because they had been taught directly, repeatedly, and in enough conversations that they had become part of how the team understood its own job. When the UK-based QA Lead ran that preliminary check on Thursday morning, he wasn’t following a procedure. He was doing what the team had been built to do.

Studios that treat distributed time zones as a scheduling liability will always be managing around their own structure. The teams that design for it, building the trust that lets work move without a coordinator, create real production leverage without asking anyone to work longer days. That is the hidden work of remote game development: not the tools, not the meetings, and not the handoff template, but the operating culture that keeps work moving when no one is there to push it.

Craig Wells is Vice President of Operations at Super Evil Megacorp.