Magic: The Gathering Drive to Work Podcast - Drive to Work #315 - Collaboration

Episode Date: March 18, 2016

Mark talks about team dynamics and how to teams work together.

I'm pulling my driveway. We all know what that means. It's time for another drive to work. Okay, today I'm going to talk about something very important to the making of magic. Collaboration. So, one of the things that I talk about, but I don't know, I talk about enough maybe, is that making magic is a collaborative effort. That is not one person that makes a set. It is many, many, many people that make it. In fact, it's not even one team.

There's many teams. And I spent a lot of different podcasts talking about just other teams, about the development team or the creative team. I haven't talked about the editing team or the caps team or logistics or marketing or, you know, the brand team, the legal team. You know, there's just so many different people that go in to making magic. So one of the things I want to talk about a little bit is the act of collaboration. Because I talk a lot, I focus a lot on design, on like the crunchy bits

of actually designing stuff. But I think I sometimes don't spend as much energy on what it takes to be a good collaborator. And so the point of today's podcast is to talk about the collaborative process.

How does one be a good collaborator? So there are a couple things. So first thing to understand is in a collaborative effort, you need to realize it's a collaborative effort. One of the biggest mistakes I've seen sometimes with early

designers is that they don't, they carry too much of the burden on themselves, both within their design team and as a larger whole. That they're just trying to get everything done themselves because they're trying to make sure that everything gets done. And that a big part of the collaborative process

is having enough respect for the other parts of the process to know they'll do what they need to do. Meaning a big part of collaboration is trust. You need to trust that the other people are good at their job and know what to do and are doing their job. And that I think one of the things that happens sometimes when you're not used to collaboration is you sort of double check on everybody. You sort of make sure things get done. And, well, it's fine to be thorough. Nothing against being thorough.

A good collaboration is not you doing everybody else's job. A good collaboration is understanding what jobs are being done by everybody and allowing them to do those jobs and give them all the tools they need to do it. I think a big part, one of the big things that's important to me, I know that when we work in design, is there's other teams that have to be happy with what we make. There's other teams that are going to need to

be involved. And if we have decisions, I want to make sure they're involved in the decisions, because what you don't want in a collaborative process is to have somebody who's responsible, but who didn't have a say in helping figure out, you know, for example, design makes something and doesn't at all check with development and then gets to development, well, development has less incentive. You know, you want development involved early for a whole bunch of reasons. First and foremost, you want them involved early because it'll reach better decisions. Like one of the things about, when I talk about the makeup of the team, you know, we always have a developer in every design team. And one of the reasons that person's there is they're just different. Different groups have different cares.

A design team also has a creative team member. So there are representatives of other teams on a design team on purpose because there are certain vantage points that not everybody's going to think about. For example, when I'm designing something, my priority is to make a good design. I want something to be well-des design. I want something to be well designed. I want something to be fun. I want something the audience will enjoy. And I'm trying to make a set that I think will be fun to play. But there are developmental concerns that maybe I, I'm not a developer. I don't have those skills, you know. I'm not as fine-tuned. Because maybe

we make a choice in making the mechanic that makes it hard to make you know hard to push for constructed you know i can make a mechanic that okay it's a neat fun mechanic and then development can come back to me and say okay it's it's great i'm glad you made this fun mechanic but because of reason a b and c we can't push that so no one's going to play in constructed and if none of the cards are sort of pushed, that means that, look, just less people are going to play the mechanic because people will play the better cards. And the better cards aren't the mechanic, then they might not play the mechanic. And so one of the things, you know, that's important to understand is if you talk early on, like one of the big things about design is the earlier we understand something, the earlier we can adjust. The way I always explain it is, imagine you are building a house.

If somebody says, hey, hey, hey, at the blueprint stage, well, you have a lot of time to react. You know, okay, you need to shift this wall over there. Okay, let me figure out how to do that. If the house is already built and someone starts saying, hey, we need to move this wall, you're like, whoa, whoa, whoa, we built the wall. That's not an easy task to move the wall. And that doesn't mean the wall can't be moved.

You can knock it down. I mean, it's possible, but it's a lot harder. And in general, in design, the earlier you understand things, the earlier you can react to them. And that one of the reasons that the collaborative process is important and you want to involve people early is, the earlier you involve somebody, the earlier you can actually make sure that their voice is heard and that what they are saying can be taken into the design. I mean, once again, I'm talking from the vantage point of designing a set.

A lot of what I'm talking about today applies to any collaboration and it applies to any part of the process. My vantage point is design. This podcast is about design. So I'm giving my examples in kind of, from my viewpoint. But be aware, a lot of stuff that I'm saying

applies to everybody. I mean, if you are not earliest in the process, part of the collaborative is getting involved early in the process because whoever's doing

the early work is in the same boat the design is in. Like if you're building a house, you want to check in with the architect and make sure that you're happy with what the architect is doing. Because the architect, before anyone's done anything, has lots of latitude to try to make changes. But once you start building the building, once you start making the house, it's harder. And that's true of anything, that if you want to be involved, make sure that you understand the early things so that you don't want to change things later in the process when it's harder to change things. And so one of the things that I think really helps the collaborative process is lots of communication.

Communication is key. You want to understand not only what is being done, but also why things are being done. It's not just a matter of understanding the what, but the why is super important. Because sometimes the what might be correct, but the why might be wrong. And if the why is wrong, even if the current decision happens to be correct, it'll lead to further decisions that aren't correct. Like one of the things that's very important, that when design does a handoff to development, probably the most important thing

is trying to get the essence of the design, the vision of the design. What are we trying to do? Because individual decisions might be incorrect. And development a lot of times will go, oh, you want such and such to be such and such? Oh, well the way you did it won't maximize that.

We can fix that. The classic example I give is in Innistrad, I made vampires black and red, and I wanted them to be the aggressive tribe just based on how other tribes were working. And it turns out what I handed off was not the way to make them the most aggressive tribe. But I communicated to Eric Lauer,

who was the lead developer, my intention, and so he was able to change it so the design or the set matched the intention of the design. In the end, when Innistrad came out, the vampires were aggressive, but that's because he made some changes to make sure that they were aggressive.

The way I designed them, they weren't as aggressive as they could be. And that one of the things that's super important to understand is, in any collaborative process, is you have other people who have strong skills and you want to make sure that you are maximizing their skills at every step along the way. For example, if you go back in time, one of the things about the change in the design process over the time I've been at Wizards, you know, 20 years, is early on, design kind of went off and hid in a hole.

And then at some point they popped up and go, here, development, here you go. We've made a set for you. What we've learned is you just make more work for development if development isn't involved early. You make more work for creative if creative isn't involved early. In fact, that's another big change is there's a period of time where we would make a set and then once we were done with the design, maybe not the development, we say to the creative team, okay, well, what's going on?

And now we've evolved them way, way earlier. There's a lot more that goes on and a lot of decisions are creatives weighing in before design even starts so we understand the world correctly and we're building things properly so that we are telling the story we are trying to tell. And like I said, one of the things about something as complex as magic

is there are a lot of moving pieces. I always talk about how it's different games for different people. But what that means is I'm trying to make sure that every aspect of the product is the best it can be for the player who appreciates that aspect. So, for example, there are people who appreciate the story very much. It's a major factor of what makes them play and enjoy the game. There are other people that could care less about the story. Unless it gets in the way of them understanding the cards, it's just not something they interact with.

And the point is, you need to have the story matter enough that the people who care about it are happy, and that it doesn't get in the way of the people who don't care about it, but make sure it's not interfering with other things. And that requires a lot of collaboration on our part, because the goal is, we want the creative team to make the best set creatively they can. We want the development team to make the best set developmentally they can. Everybody wants us to make the best set creatively they can. We want the development team to make the best set developmentally they can. Everybody wants us to make the best set design-wise we can. You know, all the different teams, or even like I said, you start getting to editing, or caps is a good example. So caps are the people that actually produce the cards. So if we're going to make cards, we can come up with ideas. So here's

a good example was during Innistrad, I'll use Innistrad again, I figured out, I don't know, but halfway through design that the double-faced cards were something we wanted to do. We were trying to figure out how to do werewolves

and it was the cleanest answer. Okay. Now, just because I want to make double-faced cards doesn't necessarily mean we can make them. You know,

this was an example where I had to go to the people that made the cards and said to them, okay, technical people, can we do it? Is this something we're capable of doing it? I knew that Duel Masters, which was another game

we make, had done double-faced cards. And so I'm like, okay, well I know we've printed double-faced cards before so that made me believe that there was some chance we could do it. But magic has different specs and different criteria and one of the things that you realize and the reason you talk to other teams is

they have concerns that you might not have. They know things you may not know and part of what's important is when you're trying to understand if you can do something is you have to go to the experts and say, okay, I want to do something, but I have no idea. We've never done this before. Well, let me go ask the experts in this area.

Can we do this? And it's a good thing. I went as early as I did. I went in. Design normally is 12 months long. I went at a six month point. So halfway in. So like design show had six months to go.

And I'm like, OK, guys, I want to do this. Can we? Um, and it took, um, like we managed to finish about just in time, meaning had I not gone as early as I did, we might not have had double-faced cars. Cause it might've been, oh, that would have been a neat idea, but yeah, we didn't have time to execute on that. Um, and that's another big thing about collaboration is that you need to make sure that you need to respect every part of the process and that you can't be careful of ever saying, oh,

yeah, yeah, they can do it. You don't know that in other, you know, always ask the other section if they're capable of something. Because things that might seem easy and obvious to you, like here's another good example is, one of the things that we need to do early in design, or not early in design, during design,

is we need to talk to the editor of the set. The editor is picked very early. And the reason is, for example, there are things, there are editing problems that we don't see, we don't edit all the time that they'll be very aware of. For example, we can make cards that just don't fit. Or we can make cards that are untemplatable. Or we can make cards that don't work in the rules. And the editor is the person who will start to catch some of that.

I mean, obviously, we're the rules manager on the rules. But, you know, you want to involve the editor early so that if there's trouble, you might not even realize there's trouble because you don't realize what the trouble will be. But you bring somebody like an editor in who's technical, who has a very specific job, and they're going to point out things you might not be aware of and say, oh. And another very common thing is sometimes it's not that there's not a solution to your problem, but A, you didn't realize you had a problem and B, you couldn't have

solved the problem but they have a solution for you that you might not have thought of. And like I said, it is very, one of the things

that's very eye-opening to working in a collaborative thing like magic is there is so many different facets to the making of the game and to the structure of the game. And that, you know, it is very easy when you focus on your area of expertise to get really caught up on that expertise. In some level, it's like whatever it is you do,

that is the most important thing. And it is to you. It's the thing you, you know, like I spend a lot of time and energy really dwelling on design, really dwelling on what's making a particular thing tick or work. And that the, I'm not concerned myself with other factors.

I mean, sometimes I will realize I need to, but that's why we have a lot of check-ins. The reason we check in with development or creative or editing early on is to say, hey, okay, am I doing something that's going to cause one of you problems? Am I ignorant of something that, like, is going to come to be problematic later down the road? So another good case is with digital, that most of our games get converted over to digital. And so, hey, we have to check in. Sometimes something that we're doing, if we made a small change for us, could be a giant change for them. A good example might be, we want to make a card, and we go talk to people who are going to program the card.

And they can say to us, oh, you know, this one factor is going to be really problematic for us. Are you able to change something about it and make suggestions to us? And we might go, oh, yeah, yeah. The difference between the version we had and the version you're suggesting doesn't matter at all to us. You know, we just care about thing A and B, and you're talking about C. Oh, yeah, we could change that, you know. and we will make changes that have minimal impact on us and have huge impact on somebody else. And I think that is, it is very important to understand, and it's very easy to trap to fall into.

It's very easy to just go, oh yeah, yeah, whatever, they can do it. And not involve them. Oh yeah, yeah, they can do it, and never ask. and not involve them. Oh, yeah, yeah, they can do it and never ask. And the reason is, if you ask them, sometimes, like, one of the things that's very interesting to me is, now, sometimes you ask and there's major changes required,

and that's a lot of work on your part. But it's funny how often in time they want to do something, and it's a trifle to you. It's insignificant to you. It's not, I mean, it's something that has an impact, but a small impact. And it's like, oh, you know, can you make this change that will save us hours and hours of work or maybe allow us to do something? And the answer is, oh, yeah, yeah, yeah. Oh, and the other thing that's very important, as I brought up earlier, is there are things that are very easy to do early on that become harder and harder to do

um one of the problems we used to have back in the day was we'd make a design and we would involve some component and then late in the process they're like oh can we just take out this component and i was like oh well we designed around it like it's really integral to what's going on you know it's a bearing wall to use my. You kind of can't take the wall out. Like, the house is kind of leaning on that wall. And it's like, had someone come earlier, it's like, well, maybe I could have changed where the wall was, you know. Maybe, not always, but maybe I could have. Okay, so the other big thing about collaboration, communication is important, respect is important.

Yeah, and then let me get on the respect thing a little bit because this is pretty key, is if you don't have faith in your fellow team members, a couple things will happen. One is you'll stop talking with them because you won't believe that what they have is of value to you. Second is you'll start sort of doing work for them without consulting them because you're like, well, because I don't trust them, I better do some of the work that they're supposed to do.

And what ends up happening is you undermine that team's ability to do the work and you also sort of set yourself up for additional problems. You know, because a collaborative process can't function if all the pieces don't work. If something is flawed, it's going to cause problems, and you need to draw attention. Like, let's say there's part of the collaborative process that isn't working. you need to draw attention. Let's say there's part of the collaborative process that isn't working. You doing extra work so it's never seen by other people does not help the system.

You need to trust the people, and if there's something that isn't working, let that come out and let the process understand that something's not working. That is how you fix it long term. Hiding it does nothing but just make it happen again. Like, once again, the teams at Wizards are awesome. So this is more an example of,

I guess I go back into Wizards Pass or some of this I could relate to, but where some section would have problems and not deliver, and then you're like, well, let's just not involve that section. But the problem is, and it never changes, then that section's always, you're not getting what, assume that every section is doing something important. And so when you just ignore some section, whatever work they're supposed to do doesn't

get done. And no matter how well you try to sort of make up for it, look, that's not your area of expertise. The whole idea of collaboration is you have a process that's complex enough that no one can do it all. You know, like if you said to me, okay, you have all the time in the world.

Time's not the issue. Could you, by yourself, from beginning to end, make a magic set? And the answer is, I could do parts of it really well i would design it well um parts of it i would do okay you know i've been a developer i could do some development it wouldn't be great development uh it would probably break in the in the higher you know like i don't have the skills to make a balanced standard environment so it's's definitely going to break there. Probably would, I mean, it developmentally would break in some spots.

Editing-wise, I'm not a good templater. I'm not, you know, I have some knowledge of the rules. I don't have perfect knowledge of the rules. I think they would run some areas there. Creative, I mean, there's a lot of things that I don't know about all the intricacies of the story. I'm not working on it day to day. You know, there would be areas in the creative that would just be, wait a minute, two years ago we said this, and now you're completely contradicting it. Or maybe there's a character that I don't quite understand the nuance of something with the character,

or their background or something, and like, my general knowledge of the character, I miss something. And to the people that care, you know, it falls flat. The idea is if you don't allow each part to do its thing, it can't shine. And so you do have to trust and respect the people that are doing each section. And one of the things that's important also is, especially if you're early in the process, like design, you have to take the feedback. That doesn't mean you can't talk about it. It doesn't mean someone says something and you're like, oh, well, absolutely.

It might be, oh, well, here's some issues, how that affects what I'm doing and walk through. is a good sort of lesson is people will often, I talk about this a lot, is that people will recognize problems very well. People are, people, humans are very good at recognizing problems. What they're always not as good at

is solving the problems. And usually the reason is the person who recognizes a problem can recognize the problem exists. But that doesn't mean they understand the reason is the person who recognizes a problem can recognize the problem exists but that doesn't mean they understand the nuance of the system necessary to always fix it. Now sometimes they do

but a lot of times in design if development or creative or somebody has an issue I might say okay let me understand your issue and let me see if I can fix the problem. So that's another big thing about collaboration is

problem solving is multi-step. Magic is interesting in that we definitely have areas where, like, design is in charge of the process for some amount of time and then it passes over to development for some part of the time. So there's definitely a handoff. Not all collaborative processes have a handoff. A lot do. But one of the things that's important is troubleshooting.

So what I find is, what I want is, I want to understand from other teams what problems are being caused. I want some sort of talk of them of, well, usually what I want is I want them to tell me what the problems are. I then want to come back and ask questions. I want to make sure I understand the problem from the vantage point of what I'm doing, which obviously is design. If something is a developmental issue, then I want to come back and say, okay, let me understand which components of it. And that's another big thing to understand is,

let's say you're working on thing A and thing A is a problem. It's not necessarily that every aspect of thing A is a problem. Thing A in the whole is a problem. So what you need to do is walk through exactly why someone has a problem. Good collaboration is not, I have a problem with this. Good collaboration is, here is why I have a problem with this. Good collaboration is, here is why I have a problem with it. Here is the issue at hand. Because a lot of times, solving problems as a team is figuring out what different people care about and finding a solution that addresses all the individual concerns, you know, but is still doing the thing that needs to

be done. So like a development comes to me and says, okay, you have mechanic X. Mechanic X won't work for problem Y or Z. The correct answer is not always kill mechanic X. It might be, okay, can we change mechanic X in a way that it addresses the concern that has been brought to us? Now, sometimes we can't, and sometimes,

you know, sometimes criticism might remove a component, but other times, like, a lot of times what happens is some of the best design is somebody tells me there's a problem, I understand the problem, and then I look to find a different solution. So my best example of this actually is not from,

it's a writing example, but it's a good example of, is, so, it's a writing example, but it's a good example of, um, is, so, well, may I give you a magic example? Um, okay. So one of the things that will happen, let me see if I give a good example here is, so when I was working on... Oh, here's a good example. When I was working on Theros, Theros, the idea we wanted is we wanted to make a set

that had an 11... I mean, it was a Greek... It was a top-down Greek set. But I wanted enchantments to play a big role. I wanted enchantments to be a big part of the set. And originally,

there were no enchantment creatures. That all the enchantments existed outside of creatures. Now, I was able to take some instants and turn them into enchantments, and some sorceries and turn them into enchantments, and even some artifacts and turn them into enchantments. I could take a lot of non-creature cards and make them into enchantments, and even some artifacts can turn them into enchantments. I can take a lot of non-creature cards and make

them into enchantments. But what happened was development came to me and said, okay, your numbers don't work. In order to make this matter, in order to have enough cards that are enchantments, if only the non-creature portion,

even if every single card's enchantment, even if limited, they're playing 16 creatures and 7 non-creature portion, even if every single card's enchantment, even if limited, they're playing 16 creatures and 7 non-creatures and every single non-creature's enchantment, you still don't have enough enchantments. You know, you're still going to run into trouble. And he said, like, they're just going to play some stuff

that aren't enchantments. That's the nature of the system. And so Eric said, you have an As-Fam problem. You don't have enough enchantments. Now, Eric had made some other suggestions. I don't even know what the suggestions Eric made, but really what he was saying was the numbers don't work.

Meanwhile, in an exploratory design for Born of the Gods, Billy Moreno had made the bestow mechanic. And I thought it was a really cool mechanic, and we were sort of saving it for Born of the Gods. But once I heard, our Aspen isn't working, it's like, oh. In order to fix that, the only way to fix it was to have some creatures that were also

enchantments. And Bestow allowed us to make things that were enchantments and function like enchantments and did a lot of enchantment like qualities but also be creatures and so um that allowed us to um fix the problem and once again you know bestow wasn't something eric didn't come to say put bestow in eric came and say here's your problem your Eric didn't come to us and say, put Bestow in. Eric came and said, here's your problem. Your numbers don't work out.

And then we were able to say, okay, let's take Bestow and put Bestow in the set. And like I said, I think that the most interesting thing in general when I think about sort of collaborative problem solving is... I like that each person does a good job of explaining to, like, if you're going to be collaborative and do a good job, it's important that everybody understands the issues at hand. It's not like Eric came to me and said it won't work.

For example, one of the stories from my runner days. So my very first job ever, this is the job I got because I snuck on a lot and took an interview that wasn't my interview, for those that ever heard that story. I ended up working on It's Gary Shandling Show, which long ago, it was a show starring Gary Shandling, if you can't figure that story. I ended up working on It's Gary Shandling Show, which long ago was a show starring Gary Shandling, if you can't figure that out. But anyway, the first day we were in the office, we were there before the cast

was back. The crew shows up before the cast is back. In fact, not even all the crew were there yet. They wanted to decorate the office. So they asked us, you know, the runners and stuff, say, okay, we decorate the office. So they asked us, you know, the runners and stuff, say, okay, we want the office decorated. We want a sports theme.

Okay, so we go out, we get sports things and sports memorabilia and sports posters and different things and we decorate the office. And then the guy who gave us the task came back, looked at it,

and said, not that. And that was insanely hard because he wasn't giving us any guidance. He wasn't saying why something didn't work. So why would the second, so we had to redo it again. Well, why is our second chance going to be even better than our first? We learned one vantage point. Our first attempt didn't work.

What are we to know from that? Were we to not repeat anything and just completely do all new different things? Because we didn't want to repeat the mistake we made and to repeat anything would be to repeat the mistake? Like, for example, what if he hated the posters but he loved the memorabilia? If he doesn't tell us that, how do we know?

And that I think a lot of times in the collaborative process, people do that. Like, it's my job to sort of say whether it's okay or not. So I say it's not okay. Well, are you helping? You know, part of being collaborative is not just making sure that you shine in the area that's your area, is not just making sure that you shine in the area that's your area, but making sure that other people, like giving other people the information so they can shine in their area.

Like being collaborative is not like, here's what I like to think about. My job is not just to make the best design possible. My job is to make the best design possible, enable the best development possible, enable the best creative possible, enable the best editing possible, enable the best creative possible, enable the best editing possible, enable the best printing possible, enable the best digital interpretation possible. You know, I'm supposed to, on every facet of the product, make sure that I'm enabling

other teams as much as I can. Now, obviously, I'm not going to know everything. You know, there are things that other teams are not going to figure out until they have to do something. Like development might say, fine, fine, fine. But when they finally put all the pieces together, they learn something they didn't realize until they had done that. And so that means another part of the collaborative process is being around even when it's past your part. So, for example, I come first in design. I design something. Now I could pat my hands, walk away, go, okay, I'm done. Never see that again.

But I check in. I go, hey, you know, and I want to make sure that people are aware that I'm there. You know, one of the things that's really important is not only do I want to check in with development and creative and editing and stuff early, I want them to check in with me later. You know, if they're going to make a change, I want them to come to me and say, hey, we're doing something. Is that going to cause a problem? And once again, I don't just say yes or no.

I say, here is the potential problem it could cause. My job is not to... The same thing that I get from them I should get back is, what I want from them is, don't tell me how to fix the problem, tell me what the problem is so I can fix it. And so on the reverse end, if they're like, can we make this change? I say, here is the problems that would cause. You know, here is what that does that might unbalance things or have vision issues or whatever.

Not that you can't do it, Here's just the problems it causes. So they might go, oh, maybe if we tweak it a little bit, we can get the things we need, but without causing the problems you think would be problems. And a good way to think of collaboration in general is you want to be, treat the collaborator the way you want them to treat you. The golden rule applies here just fine,

which is what development wants when they come in design is they want to be listened to, and they want to make sure that what they're saying is taken into account and used. And the same thing I want in design when development comes to me is I want them to listen to what I have to say and make use of it. I respect and trust that they're going to make the best development they can.

They respect and trust I'm going to make the best design they can. When they come to me and it's my time to do my thing, they're not trying to tell me how to do my job, but they're trying to give me information so I can do the best I can. And when I come to them, I'm not trying to tell them how to do their job, but I'm trying to give them the information they need to do the best they can do. And one of the cool things about collaborative, like, I've done a lot of solo efforts. You know, I used to be a writer.

A lot of writing is very solo. You sit in a room and you make things. Now, to be fair, the Hollywood process is pretty collaborative. I'm going to write something, and I, the writer, I'm not the end of the process. and I the writer, I'm not the end of the process. But the more interconnectivity you have, the more, like, the fun thing of a collaborative process is you can make something far bigger, far grander than you can by yourself. You know, I've done projects of my own and I've done things I've been very proud of, You know, I've done projects of my own, and I've done things I've been very proud of,

but nothing on the scale of magic, nothing on the, you know, I couldn't ever by myself hope to make something as grandiose as magic, because I just don't, the amount of moving parts to make it happen is a lot. But like I said, part of what I'm hoping to do today, today's podcast is explain that, um, I think a lot of the reasons for magic success is that we have so many different teams and that we all work together very well. You know, um, and like I said,

I think when I look at the advancement of, of the last, um, 20 years is we have gone from a system which used to be very conveyor belt. I'm going to do my section of the process. Okay, let's throw it on the belt and let it go down to the next people and they'll work on it. And it really was kind of like I've done my job on my part. Okay, bye-bye.

And that I didn't consult with them when I was doing my part, and I didn't consult them when they were doing their part. And each group really functioned in a vacuum. And the problem with that is, remember that a creative process is an iterative process. It's true in design. It's true in development. That what you're trying to do is say,

we want to make the best version we can. We make it, we test it, and then we figure out whether things are working or not. We try to fix the things we think are working, and then we test it again. The less cooperation you have,

the longer it takes to figure things out. And the reason is, like let's say, for example, that development makes us aware of something early on and design addresses it. Well, when it gets to development, that doesn't have to be iterated out. It's already been worked into the system. You know, one of the big differences, for example,

is the quality of the design handed off to development, you know, is higher than it was back in the day. The quality of development handed off to editing is higher than it was back in the day. The quality of development handed off to editing is higher than it was back in the day. I'm sure the quality of editing that's handed off to caps is higher than it was back in the day. Because, you know, one of the big things about doing the same thing for a long period of time is you improve. You know, how do you get good at doing something? You do it a lot.

is you improve. You know, how do you get good at doing something? You do it a lot. And Magic, you know, one of the interesting things about it, being a game that's over 20 years old, is we have a lot of systems in place that we understand. Now, we're constantly improving the systems. You know, I do not make Magic the way I made it 20 years ago,

not even close. A, it's a lot more collaborative for starters, and B, just the tools we use, because we've done stuff, we've iterated the process as a whole, we've figured out how to improve upon it and we've improved. And like I said, one of the biggest changes is the level of collaboration. There really was a point in time where different sections didn't have nearly as much communication with one another and did a lot more problem solving on their own. And the problem you ended up with when that happened was that it just slowed down the process of finding the best answer possible.

In some way, the way I like to think about it is, for magic, is we're on a deadline. We've got to produce a magic set. We're not going to not produce a Magic set. So if design ends and I've not done everything I can do, well, it's going to get handed off. If development ends and they haven't done everything they can do, it still gets handed off. The goal is you want to do the best work you can in the time allotted. And the thing to remember, by the way, is if there was no deadline,

you could fiddle forever. in the time allotted. And the thing to remember, by the way, is if there was no deadline, you know, you could fiddle forever. That's another... One of the sort of benefits of having a deadline is that it forces you to pass things on, that you can always iterate and try to make things a little bit better. And part of not having that option is, you know, we want to improve things, but we have a timeline to improve them, and the reason why collaboration is so important there is that every time we get to make a change faster,

every time we can iterate one less time to figure out key things, that just means more of the time we're working with the thing that's the final thing, and just the more of the time we're working with the thing that's the final thing. And this is the more polish we get. Meaning if design makes a set and makes a whole bunch of mechanics and all of them need to be changed in development, that's just not going to be as good a set as a set that had design, the kinks got worked on in design, and development likes the mechanics, and then they're working with them.

I think that one of the things to understand about the collaborative process is it does make for better product because it just speeds up the iteration and allows you to get farther faster. So what are the big problems with collaboration? Where does collaboration have issues? Well, number one is different people can have different ideas of what they want.

And that you're, I mean, this is why the vision is so important, is if one person thinks they're trying to make thing A, and somebody else thinks they're trying to make thing A prime, and those things aren't quite the same, there's going to be some tension in the system. And one thing about collaboration, like when you're a solo artist, you have a vision

and no one else is going to sway you. That is your vision. You know what it is. In a collaborative process, you have to create a vision, share a vision, and then get people on board on the vision. That's a big part of my job is getting people to say, okay, hey, we're doing a block kind of thing. Hey, everybody, let's get on board. Let's do this.

And a lot of my job is selling my ideas, pitching my ideas to the rest of R&D and the rest of the company, really, and getting people on board saying, okay, this is what we're doing. So I think where collaboration shines is where everybody's on the same page, going in the same direction. So the big problem with collaboration can be if you and other people aren't making the same product, or in your mind, you know,

if you talk to somebody else and what they think you're making, what you're making aren't the same, and you don't get on the same page, that causes a big problem. That, you know, a difference of opinion of what you're doing can cause a problem. Another big thing that can cause a problem is lack of communication, where people have issues, but they don't speak up about the issues.

That's horribly destructive for the collaborative process. And you need both respect and communication and trust because if people don't think that talking to you will improve the system, then they will stop talking with you. And then a lot of the most dangerous things that happen, I think, in companies is when an unhealthy system happens where the people don't trust or respect each other and they work around each other. Instead of working together to collaborate, they are, it's the opposite of collaborating, they're not collaborating. That they are, you know,

they're not allowing people to do their part. And I think the thing that I've become, I've realized is that you can't do your best work if you are not open and trusting and sharing with your collaborators. And so that's another big problem is a lack of trust or a lack of belief in one another. Because in a collaborative process, if you're doing somebody else's work that's supposed to be somebody else's team, especially without them being involved in it, you're just undercutting the process. it, you're just undercutting the process. And that I think a big part of being collaborative is helping everybody else in the collaboration do a better job. I think that where collaboration shines is every person was able to do a better job than they could do by themselves. So for example, you've heard the expression, the sum is greater than the parts. And I think collaboration is exactly where that's true. And the idea is, if you are truly

collaborating, you are improving each other's game, if you will. Like one of the things, I use a different analogy, if you want to get better at a sport, especially a sport in which, an individual sport especially, what they say is, you want to become a good tennis player? Play against tennis players that are better than you. You want to be, you want to play with people that are going to push you.

Because if you want to learn, you want to play with people who are going to really bring out your best game. And collaboration is the same way. I'm not interested in designing where the developers aren't the best developers or the creative team isn't the best creative team. I want to work with the best.

I want to work with the absolute best. And luckily, we have the best. But there's something really thrilling about trying something and having other voices and other people and other cares who know what they're doing and are really good at what they're doing, and they're going to push you to be your best because they're going to want the best for their part of the process.

And since you're trying to enable everybody else to make sure that they're doing their best work, it pushes you. And one of the things I enjoy, like I said, I've been doing this a long time, is I feel like I still am able to do really strong work because of the collaborative process, because I have so many different people. Like one of the things that's absolutely a blast to me is I love seeing finished sets. I love, you know, getting the booster packs in and ripping them open and just seeing the finished product. Because I know there's so much that went into that and watching all the different things and then seeing where we ended up

is really cool. It's a lot of fun playing with a set, you know, and knowing all the things that went into making the set. That there's a satisfaction you know, I think there's a saying that like, nobody enjoys a chair like the craftsman that built it.

There's something really cool about sort of working on together, working with a team on something, and then watching the net results of what you've made, the end results of what you've made. And that is really cool because, like the other neat thing for me also, remember, is I'm the beginning of the process so a lot changes like one of the neat things is

it is fun to work on things and get input and make changes it's also fun to watch other people take what you've done and do cool things with it like I remember like Ravnica is a good example where we collaborated with the creative team. We came up with the idea of the guilds and then, you know, design ran with the guilds and creative ran with the guilds and then development ran with the guilds.

And, you know, everybody sort of got on board on this vision and all really sort of followed along with it. And we ended up with something really cool that the audience really connected to. And I think that came to that all of us together you know we we came together and like you know the gills are a perfect example that it wasn't a design creation it wasn't a creative creation it was a combined effort for example that design wanted something and design went to creative and said how can we make this happen and design said okay here's a creative wrapping wrapping. And we went back and forth. And then once we discovered that we had that,

then I went back and forth with development saying, okay, how do I make a set? I want to make a set in which there are 10 color pairs and I divide them 4, 3, 3 among 3 sets in a block. Can you draft that? How does that work? And development at first was very skeptical because like, I don't know, can that work?

We've never done that. But they embraced it and they figured it out. And then Ravnica went on to be one of the top drafting environments. People really liked Ravnica. It was really different and interesting. And that is the thrill of collaboration is when you come together that you get to see in some ways, you know, I talk a lot about how, you know, your creative thing is your child. You have a lot of personal emotional attachment.

But it's not, in some ways, you know, I'll use my own children as an example, is there's things my kid do that I didn't teach them, somebody else taught them. You know, maybe my wife taught them, maybe their teacher taught them, maybe a friend, you know, that their skills they picked up, they weren't skills I gave them,

but as somebody who's looking at this going, oh, I'm so excited that other people improved, you know, helped my child be the best they can be. And then it doesn't matter that I would, you know,

it's not like I see some improvement in my child and go, wait a minute, who taught you that? No, I'm glad. I'm glad that there's a collaborative process in raising a child. I mean, obviously, my wife and I spend a lot of time working together.

And we work with teachers. And we work with all the different people that interact with our child to help them raise them. And I think the collaborative process of making magic is very similar, which is there's areas I shine. the collaborative process of making magic is very similar which is

there's areas I shine I want the game to have some semblance of elements I added to it I want to make sure that I improved it but there's other people

that do other awesome work that are going to make it even better than what I did and that is a cool part of seeing the finished product and saying oh oh this is awesome

that's awesome and you also can appreciate some stuff sometimes you know it's hard for me to be the consumer on the design end because I'm in the nitty gritty oh, this is awesome, that's awesome. And you also can appreciate some stuff. Sometimes, you know, it's hard for me to be the consumer on the design end because I'm in the nitty gritty and I can see behind the scenes. But sometimes the stuff that other teams do

that I get to kind of sit back sometimes as a consumer and go, ooh, that's cool. That is cool. That's not something I baked into it, but you added on something and that is really neat. So anyway, I'm almost to work. I think actually today was a slightly longer week. We had some rain today, so more traffic. In fact, I have a meeting in four minutes, but I'm in or two more. So I'm going to end with you and then rush off.

But I just want to wrap up by saying today that collaboration is one of those things that when done correctly is an awesome thing. It's a beautiful thing. You walk away from the process happier, that you get to do better work than you can do by yourself, that you create something that you could not have created by yourself, and that you get to be part of a larger thing. But on the flip side, if done poorly, collaboration can be very frustrating. That part of trying to be a good collaborator is, I'm hoping today is understanding the value of why you want to collaborate, how you can be a good collaborator,

you know, and how, how when everybody is shining and doing their best and working toward a shared goal, you can make awesome, awesome things. And magic to me is an awesome, awesome thing. But that if you don't, if you aren't trusting and aren't respectful and aren't communicating, it can cause a lot of problems and be very frustrating. And so I'm hoping today,

a little peek into this to give you some ideas of maybe how you could apply and help be an even better collaborator doing whatever you collaborate on. So, but anyway, I hope you guys enjoyed my collaboration talk. It is a big part of what I do. And one of the things I find fun in this podcast is just finding a way to talk about other aspects

that are really important that I haven't talked about before. So I hope you guys enjoyed hearing about collaboration. But I parked my parking space and I'm late to a meeting. I'm not late, but I have my first meeting. So anyway, we know what that means. It means it's the end of my drive to work. So instead of talking magic, it's time for me to be making magic. I'll see you guys next time.