Class Prompt: Prioritization


In spring 2020 I taught a Technical Game Design class in Champlain College’s game design program. As part of my work I wrote discussion prompts. I’m expanding some of those prompts into blog posts, like the one below. The full set can be found here. Because they were meant as prompts for students to discuss, they do not necessarily provide strong conclusions or answer the questions that they pose.

This week let’s talk about an important skill: Prioritization.

In a large studio environment, the ability to prioritize – triage – every task or problem that comes your way is crucial, especially if you’re in a role where you may be randomized or need to react to sudden pivots, changes, or requests.

Let’s do some quick vocabulary. These are all terms that we use at Bungie. I can’t promise that they use these same definitions everywhere, but they’ll help us talk about these concepts:

  • Triage: Triage is the act of reactively evaluating bugs or problems as they arise, and assigning them a priority, either with a priority rating or by stack-ranking them in a list.
    • It can also be the name of a meeting where triage occurs, IE “we’ve got Triage tomorrow morning”.
  • Prioritization: Synonymous with “triage”, except more general: it can be proactive or reactive.
    • A common example: A product owner in an agile team is responsible for prioritizing the stories in their team’s backlog.
  • Dependency: A dependency is a task or deliverable you need from another team in order to finish your own work.

This all sounds like producer stuff, right? But it is super relevant to day-to-day design work. You constantly need to think about what order to do things, and this comes in all shapes and sizes.


  • You need to decide whether to implement the AI markup or the combatant squads first when setting up an encounter.
  • You have two tasks: one will help you hit your milestone, the other will unblock another team so that they can hit their milestone. Which do you do first?
  • You’ve been asked to help the tools team understand the biggest pain points in a new tool.
  • You’re closing the project, and you may not be able to fix all the remaining bugs. Which bugs must be fixed to ship? Which ones could you get away with not fixing?
  • Should you spend your time on:
    • A: Writing documentation that will help many people a little bit, many times a year, for years.
    • B: Polish the hell out of the new feature you’re working on to help ensure that it’s a success and your studio will survive to work on another project at all.

This is important for basically any industry, and certainly for any game development work. I bring it up here because tech designers are expected to have a high proficiency with this skill. You will be more likely to have multiple stakeholders that need work from you, people asking for help, people asking for feedback, and people asking for your time spent documenting. You will be relied upon to foresee technical dependencies and workflow problems.

Studios may not put this front-and-center in most job descriptions, but it is a key skill. Demonstrating it in your body of work, resume, and in interviews will be a tremendous help in getting you hired, and honing this skill in your day-to-day work will help you go far.