Team Player

Posted in Making Magic on November 30, 2015

By Mark Rosewater

Working in R&D since '95, Mark became Magic head designer in '03. His hobbies: spending time with family, writing about Magic in all mediums, and creating short bios.

Welcome to Teams Week. It's time for the World Magic Cup, where teams from countries around the world come together to compete at the highest level of Magic team competition to see which country will become the reigning world champion. While most everyone else is going to be talking about that, I've decided to take this theme in a slightly different direction and talk about what teams have to do with the making of Magic.

Win One for the Team

Let's begin by talking about a very important aspect of how Magic is designed (and developed and well, pretty much how almost every aspect is done). Magic is a collaborative effort. No one individual makes the game, but rather groups of people make the game. Every time I start previews, I begin by introducing you to the design team. That group of people worked together for a year for large sets and at least four months for small sets to create the initial design. Then a completely different team developed the set, acting as a second set of eyes to continue advancing the design. Meanwhile, a team of story people have worked very hard to make sure that set has a story that is conveyed not just through the set but through as many mediums as possible. And a different team is overseeing the art to make sure that the world has a cohesive look. Then there's an editing team, a production team, a logistics team, a sales team, multiple digital teams, an organized play team, and many other teams I'm forgetting as I write this sentence. The point is that in order for Magic to go from a blank piece of paper to printed cards, numerous groups of people have to gather together and work cooperatively to get the job done.

Today's article is going to be about just one of those teams—the design team, because that's the part of the process I write about. But please keep in mind that what I am going to describe today is just one piece in the much larger puzzle of how Magic gets made.

Team Building

The whole process starts before there even is a design team. In fact, there's a team or two that comes first. When we first come up with the idea of what worlds we want to visit in the future, the upper management of Magic R&D gets together to walk through a proposal, usually put together by the art and story teams, outlining a rough idea of where they think the story is going. As a group, we then examine many potential worlds to get a sense of what place would both reinforce the story we're telling and also, in a vacuum, be a compelling world for Magic to visit. Sometimes that's a return to a known world that we've visited before, and sometimes that will be a brand new world that has some hook we like.

Those ideas get bandied about so that we can start getting a sense of what individual settings make sense. Sometimes this results in us making mini-teams where we explore the different worlds to make sure that each one has design, story, and art potential. Eventually, the larger R&D group comes to a consensus on which worlds make the most sense, and we commit to a basic framework. When I talk about the "seven year plan," this is what I'm talking about. We tend to always try to have a rough idea of what the next seven or so years hold so that we can properly adjust our lineup to maximize its potential. We don't plan seven years at once, but rather plan a bunch of years that go onto the end of what we already have planned.

Once we have a rough sense of the upcoming worlds, the design, story, and art teams each give an educated guess of what we anticipate that world being about so that upper management can get a sense of where we plan to go. This future plan is not written in stone. Things can happen that make us realize we have to adapt, and the future is always able to be shuffled if things don't quite work out like we planned.

Scapeshift | Art by Fred Fields

At a certain point, though, worlds are basically locked down. The first work done on a set, behind the prep work required to get it approved in the first place, is done by what we call the exploratory worldbuilding team. That happens prior to exploratory design because we've realized that design can do better work if the world and story have been somewhat locked down. The exploratory worldbuilding team always includes at least one designer, so that design ramifications can be considered as the world is starting to be formed.

After the exploratory worldbuilding team is done, the work is passed to the exploratory design team. Just as a designer is always on the exploratory worldbuilding team, a member of the creative team (most often a member of the story team) is on the exploratory design team. As I've talked about before, the exploratory design team is made up of a group of people who rotate through months of exploratory design, allowing us to get a lot of fresh eyes on the upcoming set. Exploratory design's main purpose is to help design start to understand the scope of the problems needing to be solved. The team also creates a lot of mechanics to provide the design team with some material to consider as they work.

Finally, it's time to make the design team. Design teams are chosen by Mark Gottlieb (the design team manager) and myself. Each design team for Standard-legal expansion sets has to have several components:

A lead designer—We always start by deciding who the lead designer is going to be. This person is picked first, because we both like to have them involved in the exploratory design and want to ask their opinion about team members they are interested in having on their team.

A "strong second"—People get sick and go on vacation and occasionally get pulled into emergencies. As such, we like to make sure every team has a designer capable of leading the team if the lead designer is out.

A development representative—Every design team needs a developer, who has two main functions. One, they are responsible for keeping a sanity check on the set to make sure we are making things that can be developed (and they will often check in with both head developer Erik Lauer and the lead developer of that set). Two, they are responsible for doing all the costing on the cards.

A creative representative—Every design team needs a member of the creative team, who also has two main functions. One, they act as a liaison between the creative teams (story and art) to both communicate what the story and art teams have done and let those teams know what the design team is up to. Two, the creative representative is responsible for maintaining the card names in the design file to make sure they adequately reflect the flavor of the set.

Fresh blood—Another important aspect for design teams is to bring someone onto the team who doesn't normally serve on design teams. It's very easy for the designers to get into groupthink, and having someone coming from a different vantage point can help spur new ways of thinking about problems.

A filekeeper—This role started because I was so busy that I was trying to find a way to cut down some of my extra work, and monitoring a card file (including inputting all the cards as well as constantly updating the changes) chews up a lot of time. I discovered that this role had a second beneficial effect: it proved to be a great teaching tool. There was no better way to learn about how a set gets designed than having to be responsible for monitoring every change. This role is usually just for design teams I lead. In sets where I am co-leading the design, my co-lead fills the roles of both "strong second" and filekeeper.

Me—As head designer, one of my jobs is to keep tabs on every design team. Trial and error has shown that the easiest way to do this is to actually be on all the design teams. Interestingly, keeping up on files is more time-consuming than just coming to meetings. For time purposes, I only show up to half of the meetings for small sets.

If you count all the slots up, you end up with six. (The filekeeper job only exists when I'm the lead designer.) That means every design time has a minimum of six people, with the maximum being seven (and only a couple of design teams have had seven).

Assemble the Legion | Art by Eric Deschamps

Team Dynamics

So what exactly does having a team do for design? Why wouldn't one dedicated person be more effective? I can answer this from a perspective that almost no one else can, because I actually once designed an expansion all by myself. Way back in the day, I was assigned the design for Urza's Destiny—and because we were very short-handed at the time, I asked if I could do the design by myself. I was given permission and executed the only one-person "design team" for any Standard-legal expansion in the history of the game. It gave me an interesting insight into the value of having a design team.

1) You Come Up with More Ideas

Six or seven people can simply do more work than one. The volume of material produced is higher in quantity and quality.

2) You Come Up with Different Ideas

A single person is going to attack all problems similarly. They think in a certain way, and that is going to influence the kinds of ideas they have. A team has distinct individuals, each with their own vantage point—meaning that when given a problem to solve, they are far more likely to try to solve it in a variety of ways.

3) You Can Inspire One Another

The best ideas don't tend to be formed of whole cloth. Rather, they start as an idea that inspires a second idea, which inspires a third idea, and so on. The best designs are the result of a lot of fine-tuning that comes from taking ideas and constantly improving upon them. Having more voices and more vantage points just means there are more possibilities for combinations to occur. A single person can advance an idea, but it tends to happen a lot more slowly than in a group.

4) You Have the Advantage of Expertise

You'll notice that when I listed the design team slots, a number of them are about making sure the design team is connected to other teams. These pockets of expertise have proven invaluable to the design process, because in the moment of forming an idea you get instantaneous feedback about developmental or creative concerns. There are always design team members who are working on other design teams, so you also get input about what is happening right before or after this set. You can also get feedback about other things going on in R&D that might have implications for the design. And all of this is happening as you make the design, allowing you to adapt, on the spot, to the new information.

5) You Have the Advantage of Different Designers' Strengths

This reason is an offshoot of the last one. Just as different members of the design team have various pools of knowledge, so too do they have different areas of strength in design. With a design team, you have the ability to assign tasks to the design team member best suited to that task.

6) It Changes the Dynamic

When I think back to designing Urza's Destiny, my memory is always me versus the computer screen or the pad of paper. There was a design to be done, and my focus was always on solving the next problem. The design team meetings have a different sensibility. Yes, we're there to design a set, but there is a playfulness that I never got while designing solo. We joke, we tease, we make each other laugh. There is a levity to the meetings that can only come from a group of like-minded people hanging out together. And it has a profound impact on the work the team can do, because it makes the overall experience more fun. Design is a mental task, and as such, the mental state of the participants has a big influence over the quality of the work produced.

Gather the Pack | Art by Igor Kieryluk

7) Work Progresses Even When One Person Is Absent

There were times during Urza's Destiny design that something came up that took my attention. When that happened, design work on the set stopped because the entire "design team" was occupied. But with a design team, the team can do work even when one or more members are missing. In fact, even when the lead designer is absent, they can leave instructions for what the team can do in their absence. (And remember we have the "strong second" chosen to run things when this happens.)

8) You Have More Eyes to Catch Mistakes

One of the hardest things about working by yourself is that you know what you mean even if that's not what you actually put in the file. It's very easy as an individual to make mistakes that you fail to notice because you are too close to the decision being made. Having a larger team means having numerous eyes, most of which don't presume to know what you mean and actually have to read things at face value.

Overall, teams are advantageous, but there are a few issues that teams can create:

1) Team Members Can Fight

I can't recall any fights during Urza's Destiny's design. That can't be said of any other design team I've ever been on. Having more than one person means that occasionally there will be differences of opinion. And at times, that will lead to a confrontation between one or more team members. In moderation, this is actually a plus in my mind, because often those disagreements can lead to new discoveries. But I've witnessed (and participated in) enough fights to recognize that a team can get off track in ways an individual never can.

2) A Team Dynamic Sometimes Leads to Unhappy Compromises

Part of working on a team is finding a way to make everyone on the team happy with the design, and if you are not careful, things can sometimes drift to a place where no one is unhappy but also no one is really happy. Compromises can often lead to healthy, valuable discoveries, but other times can force decisions that no individual would ever have made.

3) It's Easier to Waste Time

The same environment that can lead to fun fraternizing can also, at times, cause a group to spend a lot of time without doing anything productive. An individual knows that the task is on their shoulders, while it's easier for a group to push off responsibility.

Team Performance

Now that I've talked about the pros and cons of having a design team, I want to talk a bit about the dynamics of how exactly a design team functions. To do this, I am going to walk through various types of design meetings and explain what happens in them.

The Brainstorming Meeting

This type of meeting happens in the early part of design. The key to this meeting is that the lead designer brings a focal point to discuss and then has all the team members contribute ideas within the area of the brainstorm. I'll give an example from past designs. The very first Innistrad meeting had us brainstorm about all the horror tropes that we wanted to consider for the design. We filled an entire whiteboard with everything from the different types of monsters we expected to see to the types of locations that made sense and the objects we assumed would exist. Once we had our list, we then brainstormed on what kind of card each different trope might make sense on.

Rite of the Raging Storm | Art by Svetlin Velinov

The Theorycrafting Meeting

The design meetings are often very practical, but sometimes we'll have a meeting where we take one or more ideas and talk about them. This type of meeting will often come when we first get an idea but we haven't quite figured out the best thing to do with it.

The Card Design Meeting

Some meetings are all about picking an area that we want to have cards for and then designing them in the meeting. This could be focused around a mechanic, a certain series of holes in the file, a needed cycle, a top-down design, et cetera. In-meeting designs are valuable for several reasons. One, they allow the team to work together and come up with some very cool cards. For instance, both Chained to the Rocks and Rescue from the Underworld from Theros, two of the most flavorfully mythological cards in the whole set, were the result of design meetings. Two, these meetings allow the lead designer to pick off specific cards that need to get made and make sure they get them into the file. Design meetings will often happen right before playtest meetings to help fill in holes.

The Playtest Meeting

I often talk about how Magic design is an iterative process. A key part of this process is playing with the cards and getting feedback, so we can understand what we've designed that works and doesn't work. Playtesting goes throughout design but gets more and more frequent as you get closer to handoff; the iterations get shorter and shorter. Playtest meetings are the meetings you are most likely to invite outside guests to, because getting fresh impressions of the set is very valuable.

Playtest meetings fall into two camps: Limited and Constructed. Limited playtests start out as Sealed Deck in early playtests and end up as Draft in later playtests. We start with Sealed because in the early playtests, the archetypes haven't been figured out yet—so drafting would prove too frustrating. Once we get the set in a place where we can draft, we move to drafting because most of the Limited play with the set will be through drafts.

For Constructed playtests, each design team member is given a deck to build, mostly from cards in the set (or block if it's a small set) along with a handful of generic cards we use for playtesting. The design team members then play one another with their decks. Constructed playtests are important because they help us understand if we have all the pieces in place for players to build decks out of the set's themes.

The File Review Meetings

These are the meetings where the lead designer brings all or portions of the design file and then has the team walk through the set card-by-card. File review meetings tend to be very tactical, as the lead designer is trying to address certain issues. These meetings are often about specific subsets that need attention. File review meetings are often held after playtests.

The Analyzing Meeting

This is kind of like the file review meeting, except there is no file to review. These meetings are where the design team sits around and talks about some aspect of the set that they want to evaluate. A very common type of analyzing meeting might come after a playtest, and we'll go person-by-person and talk about our feedback from the playtest.

The "Breaking Bones" Meeting

This is a design meeting where we realize something isn't working and we set out to correct the problem. We refer to it as a "breaking bones" meeting because sometimes before you can fix something, you must first break it and then rebuild it.

Bonesplitter | Art by Darrell Riche

The Presentation Meeting

This is a meeting where the lead designer has someone (often from outside the team, but not always) give a presentation to the team on some topic relevant to the design. A good example of this might be to have the person in charge of the story for the set come in and walk through exactly what happens and who all the relevant players are. After a concept push, it's common to have a meeting at the art wall where Jeremy Jarvis (Magic's head art director) will walk the team through how the world is going to look. This meeting is valuable because it often inspires design to make elements to reflect cool world aspects that don't yet exist in the cards.

The Homework Meeting

Some designs are done within meetings, but the majority are down outside of meetings, usually as homework. Normally when that happens, each team member prints up their designs and makes enough copies for everyone on the team. The meeting starts with everyone handing out their homework, and then the team goes through it all. Most often, if the assignment was specific, we'll go through each hole one by one and look at what each designer did. One of three things will then happen. Either one card will be chosen for the file, multiple cards will be combined to make a card for the file, or no card will be accepted and the task will be included in a future homework.

The Research Meeting

Sometimes the lead designer feels the team could get more firsthand information about some aspect of the set they are working on. The most common example of this would be playing with an old set that the new set is returning to. For example, early in Battle for Zendikar, we played with both Zendikar and Worldwake, and then later played with Rise of the Eldrazi.

Let me end by noting that many of our meetings are not one single example but rather a hybrid of two or more. We could start by theorycrafting and end with designing cards. We could start with a presentation, then brainstorm, and end by analyzing our brainstorm ideas.

No "I" in Team

I hope today's column has given you a better idea of both why we have teams to design Magic and how we go about it. As always, I am eager to hear your feedback. You can write me an email or contact me through any of my social media accounts (Twitter, Tumblr, Google+, and Instagram).

Join me next week when it's time for another Topical Blend.

Until then, may you have a chance to be on a team of your own.

"Drive to Work #282—Most Asked Questions"

As part of my job, I get interviewed a lot. This podcast is me talking about the questions I get asked the most and the answers I do and do not give.

"Drive to Work #283—20 Years Later"

On October 30, I celebrated my 20th anniversary working at Wizards of the Coast. This podcast talks about the differences in both Magic and Wizards between when I started working and today, 20 years later.

Latest Making Magic Articles


October 18, 2021

Mechanical Color Pie 2021 by, Mark Rosewater

In 2017, I wrote an article called Mechanical Color Pie 2017 where I listed in detail what effects were in each color. I promised that from time to time I would update this article. Today...

Learn More


October 18, 2021

Mechanical Color Pie 2021 Changes by, Mark Rosewater

*/ Below is a detailed list of every change I made between my Mechanical Color Pie 2017 article and today's 2021 version. After each change, I will explain what changed and why in a blue...

Learn More



Making Magic Archive

Consult the archives for more articles!

See All