Game Dev Project Management Theorycrafting: Ownership Threads

There are two dimensions to feature ownership in game development: how strongly are features owned by an individual member of each discipline, and how tight is the collaborative connection between those owners in different disciplines.

It is common to sort teams into pools of talent based on their discipline. This makes sense: two artists are much more likely to be able to share work than an artist and an engineer. From a project management perspective, knowing roughly how much “engineering” work and “art” work there is, measured against the number of “engineers” and “artists”, gives a good first approximation of how much time it will take to finish all the work for the game.

However, to a second approximation, interchanging tasks between members of a discipline carries a penalty, either in time or quality or both. One engineer may be more familiar with the game’s animation systems, while another is more familiar with the physics system. One artist may be faster at environmental modeling, while another is faster at prop modeling. This can be captured as “Ownership Strength”, the first dimension of feature ownership.

In a project with strong ownership, it is highly advantageous to silo your developers; that is, the engineer who works with the animation systems gets assigned all the animation-related tasks, and none of the physics-related tasks. In a project with weak ownership, each developer is able to take on any task within their discipline. Typically, strong ownership carries an efficiency bonus (devs get really good at working within their silo) at the risk of introducing bottlenecks (the game requires much more animation-related work than physics-related work, causing an uneven work distribution).

Each feature in a game requires some amount of work from each discipline. Artists, designers, sound designers, animators, and engineers all must collaborate to get a given part of the game to a shippable state. There are two broad strategies to managing this collaborative aspect. The first, as previously mentioned, is to sort devs into discipline-based pools, or “teams”. The second is to sort devs into feature-related “pods”, in which developers of all disciplines who work on a particular feature are treated as an organizational unit. This strategic spectrum can be described by the second dimension of feature ownership, “Collaborative Tightness”.

In a project with loose collaboration, an artist that asks for engineering support will create a ticket that is passed to the engineering team, which is subsequently assigned to an engineer, who will perform the indicated work and then send that ticket back to the art team. In a project with strong collaboration, an artist will work closely with an engineer, rapidly iterating and trading ideas, asking directly for support until the feature reaches the desired quality threshold.

Strong collaboration not only leads to higher quality features, but also stronger team morale due to a higher sense of teamwork and feature ownership. However, it comes at the cost of degrading the benefits of sorting developers into discipline-based teams. When small, agile, cross-discipline teams work iteratively and collaborate closely, it can be difficult to capture the work involved and effectively create a projection of how long it will take to finish all the work for the game.

That is, as long as we are using standard project management paradigms.

It is clear (to me, at least), that tending towards both Strong Ownership and Tight Collaboration is a recipe for a high-quality game. The only downsides are the risk of bottlenecking and the difficulty of predicting work schedules. These downsides are simply failures of the traditional game dev project management framework.

Starting with the first principles of supporting a Strong Ownership / Tight Collaboration development environment, let’s craft the ideal project management framework. This framework should ensure that the project meets internal and external milestones, is predictable in development time and cost, and meets the desired quality bar across all aspects of the game.

Strong Ownership is most effective when it grows naturally within a discipline. This accounts for natural collaboration between a group of artists, a group of engineers, etc. that leads to better problem solving and technical skill growth. Top-down assignment of feature ownership is a recipe for disaster. At the start of development, the Lead of each discipline should be considered the owner of all game aspects. As needed, the Lead can assign out ownership to specific team members, and similarly ownership can be passed between team members as needed.

As distinct aspects of the game become obvious and individuals begin gaining ownership over them, Tight Collaboration can be encouraged. In cases where it makes sense, an individual from each discipline can become the owner/liaison for that feature. For example, an artist has a single engineer, a single animator, and a single sound designer to talk to regarding a particular feature in the game. This group of inter-discipline collaborators can be called a “Thread”. Each person in the thread is responsible for getting the feature to the desired quality bar and estimating the required time to do so.

As development continues, more and more Threads will form, until there are very few aspects of the game that aren’t Strongly Owned by individuals. 

In many cases, there will be more work to do on a feature than can be done by a single person. Multiple members of a discipline can support the same Thread, either as primary owners or “secondaries” (in fact, having a secondary for each Thread would help reduce the “bus factor”). Tasks should be more-or-less assignable to any primary or secondary in a Thread; e.g., any art-related task can be assigned to any artist associated with the Thread. If too much specialization occurs within a Thread, it is time to split the Thread to form 2 or more new Threads. 

By polling each Thread, a project manager can quickly gain an understanding of how much work is required to bring each aspect of the game up to a given quality bar. For each person, the work from all of their Threads can be summed up and compared to find team members who are bottlenecks. The Lead of a discipline may re-assign ownership of Threads as needed in order to reduce bottlenecking to a minimum. High-level feature prioritization converts into Thread prioritization, which easily converts into task prioritization in whatever project management software is being used.

Within this framework, achieving a first approximation of the amount of “art” or “engineering” work is still completely possible. But a second approximation is much easier to get and much closer to the reality of feature development. We have unified team member management, schedule management, and feature quality management into a single theoretical framework.

Allowing feature designations to naturally precipitate out as Threads, rather than attempting to impose them top-down, also helps ensure the game reaches a quality bar across all features. For example, in a game where the player performs ranged and melee attacks on enemies, a project manager might think that “melee combat” and “ranged combat” are a good way to separate the different types of work. However, by allowing designations to precipitate naturally, the manager might discover the team finds it more useful to categorize work into “damage and dismemberment” and “weapon handling”. This sort of thing cannot be determined a priori, so allowing these feature designations to develop naturally via a formalized Thread framework is highly superior to imposing them top-down.

Overall, this sort of framework seems like a good compromise between a strict discipline-based team approach and a strict “feature cabal” approach, while maintaining more flexibility and accountability than either, and also boosting game quality and team morale.