Jan 19, 2019
I recently had the opportunity to interview veteran game producer Bernard Yee, currently Executive Producer at Oculus and author of one of my favorite GDC talks: “My To-Do List: Organizing a Producer’s work”.
He shared some of his personal experience in the industry and his take on risk management and planning.
On joining the industry and becoming a producer
Leonard: When I checked your LinkedIn profile, it showed that not only did you study law, but you also studied political science. I guess the question is: why did you move to video games, and why game production? What attracted you to the industry and the role?
Bernard: Well, actually, I was a game developer. I taught myself programming and wrote games as just a hobby when I was pretty young. I was probably a game developer before I was a lawyer. I’ve always loved games, and I think I didn’t quite realize that I could make a career out of making games when I was younger. Law school seemed like a more obvious fit for some of my interests. I actually find politics and policy and rule systems really interesting, and the law school side of my brain is sort of the same side that really enjoyed programming. You are rewarded for logical thinking. You’re rewarded for innovative ways to use rules. It’s very rigorous. It’s very demanding. I still think public policy is a really interesting area that if, in a second life, I would still go do.
Bernard: But I got into games, I think, when I was laid off and during a recession from my law job. I was thinking, “Do I want to be a lawyer more, or do I want to continue to write about games?” Which I was doing as a hobby. I decided I’d rather just write about games, honestly. I kind of pursued a career in journalism, games journalism for a while. That got me in contact with a lot of game developers. I learned about the process and how they made their games.
Bernard: Game production, I think it almost became a right place, right time. Game production is about process and understanding the subject matter, and figuring out logical ways to solve a problem. Also, obviously having a strong sensibility of what the reality of shipping the games are from a business standpoint. The law background helped that a ton. Then game production, it seemed like an easy thing to … I wouldn’t say easy, but the obvious thing to slot into, because I wasn’t a programmer. I wasn’t an artist. I wasn’t a game designer, but I kind of understood how the whole system worked. That was useful.
Bernard: Another thing I think is interesting back when I entered games, which was ’96, I think that there was a desire to have more experienced professionals in the business when still back then a lot of the business was small teams, 5, 10 people, 15 people. Maybe they worked out of college. They’ve never really been in a business environment where things were formal and things were serious. I think that that helped, my background then helped at that time too.
Bernard: That’s not the case anymore, but back in the mid ’90s, game development was still very … It almost feels like what indies are today. But back then, games were still making lots of money. It was still big business. I think that having … I don’t want to diminish my contribution, but in some ways, I was a little bit of the adult in the room. Like, okay, we work on Wall Street. Big law firms. You take your job very seriously. It’s a profession. Having that sort of discipline and structure made it easier for me to break into the industry at the time, because I think that was more the exception rather than the rule now.
On the need for production in modern games and crunch
Bernard: …I can guarantee you if you’re running a 700-person project that Bungie is or 1,000-person project that Ubisoft is for Assassin’s Creed or Far Cry, you’re not having a bunch of college graduates run that project. It’s way too complex. It’s way too many moving pieces. It’s a ton of management, and it’s a ton of dependencies. Honestly, I’m not sure I would want to do that. But you couldn’t have a bunch of college kids doing that now, right? You could, for triple-A games in the ’90s, you could have 20 or 30 people working on it and winging it.
Bernard: Some of my best friends in the game industry came from this small studio called Looking Glass. They were a bunch of college grads with a couple of adults who kind of started the company, but it was a bunch of MIT grads. They’re like, “Okay, I guess this is how we’re going to build the game.” They just sort of plowed through it by sheer force of will. In retrospect, they probably could have used much more structure to focus their work. You would not have a triple-A game run that way anymore.
Leonard: Do you think that’s partly the reason why the industry is known for crunch?
Bernard: I can give you an anecdotal story about before I was there. Halo 2, I don’t know if people remember, but Halo 2’s ending was basically cut. The game ended on a cliffhanger because they ran out of time to finish the game. One of the reasons that Bungie introduced a production process after Halo 2 was they crunched for more than a year to try to get that game done, at the expense of personal relationships and mental health and physical wellbeing. They realized they couldn’t build Halo 2 and Halo 3 the way they built Halo 1. The stakes got higher. The teams got bigger. The pressure got more tense for ship dates. They just couldn’t work harder. They had to work better. I think that that’s certainly a studio that introduced production after they got started.
Bernard: I think very few studios, hopefully, start today without production. There’s still game studios that don’t use production, like Naughty Dog and Valve are two obvious ones to my mind, but to me, that means Naughty Dog’s also known for crunching. They’re also known for shipping amazing games. If no one is doing the job of producer that means someone’s doing the job or multiple people are doing that job. There’s still that production work being done. It’s just not obvious to me who’s necessarily doing it.
On different aspects of production and what he enjoys the most
Bernard: That’s a good question. The part of production I enjoy the most is when interesting, non-obvious problems come up and we have to solve them. I think if you were to lay out a game on a table, the different interactions between the systems and the work, some of it is obvious, but when you actually do the work, interesting problems come up. I like hearing and trying to solve those problems that are new and interesting, because I think that’s where often the best parts of games come from, these random ideas that get, when enough systems are thrown together, start to form either a hard problem to solve or a new opportunity. I think that’s really interesting.
Bernard: I think kicking off a project is really interesting, getting together and watching the team work and explore different ideas. That’s not a lot of production involved early on, but I think it gives you a good sense of where the team trajectory is going to be, because in early exploration phases, I think the best you could do is give them a time box with goals and let them try to solve them.
Bernard: The thing I think is least interesting to me personally that I would delegate is a lot of the day-to-day. Right now, I’m actually sitting down and trying to clean up a bunch of documents and extract a back log. I have a little back log, and put it into some sort of tool system that allows us to see the data and validate the data that we have enough time to do the work we want. It’s pretty tedious, and I’ve done it before, and I’m doing it again. It has to be done, but I’d rather not do it, because it’s really a thing that I could teach almost anybody to do. It’s also important. While at the same time I’d rather not do it, when you go over the information, you’re also exposing yourself to the guts of a project and you understand the project better.
Bernard: It’s not a waste of my time. It’s something that I would rather not do, given the opportunity, but I also don’t want to get too far from it either, because if you get far from this level of production, then I think you lose track of what’s going on in the project.
On the responsibilities of producers through all levels of seniority
Bernard: This is how it’s always been explained to me is that an associate producer spends their time on the mechanics of production, is do standups and notes and making sure all the information is in whatever tool you’re using to track the system, making sure the data in the system is up to date, knowing what to measure and what not to measure, or making sure that the team is working on the things that are high priority based on standup. Lots of day-to-day work, and that’s actually fairly … There’s a lot of work there. I think a producer generally keeps the project running from sprint to sprint. We have a plan. You can leave on vacation and know that the producer will keep the ship running.
Bernard: A senior producer or senior producer, executive producer, their job is to deal with all the unforeseen problems, all the things that come up that you didn’t plan for, because when you really build a game, you have a ton of things that you could never have thought of. Those unknowns are the things that a senior producer and executive producer provides. That executive producer, I think, at a very high level is kind of solely responsible for the product. Who takes the blame when the product fails? When the product succeeds, the team takes the credit. Who takes the blame or who bears the brunt of the problem if a project runs into problems? It’s the executive producer. Then they have to accept a project responsibility. That’s how I think of the difference.
Leonard: Is it true that the associates also have to bring coffee and donuts?
Bernard: That’s a thing that people often talk about. Warren Spector used to say that a lot. I don’t think that that’s necessarily true. One of the things that I believe, and I don’t know if all producers feel this way, but I say this to people who work with me or work for me is that I try not to ask anyone to do something that I wouldn’t do myself. I don’t think that that’s a fair job to say, “Hey, get the coffee and donuts.” If it’s an important thing to do, then you are going to do it or have it done, and I wouldn’t delegate work to someone that I felt that I wouldn’t be able to do.
Bernard: For instance, I will often take notes at meetings. Even if I’m the EP, it kind of doesn’t matter, because I think that that’s actually valuable for the team, but it’s also valuable for me to know what’s going on, because when you take notes, it forces you to really listen. I actually think an EP that does not take notes at meetings is doing themselves a disservice, because they’re losing contact with the things that are going on on the ground level.
On the importance of taking clear notes in meetings
Bernard: It seems like jargony business stuff, but it’s actually really important, because how many meetings do you go to, and everyone sort of agrees, “Yeah, that’s the right thing to do. The right thing to do.” Then you leave the meeting, and you ask the question, “Who’s doing that? Who needs to own this task? What’s the next thing?” We all agree that there’s a goal and things that are the right things to do, but what are the next steps we take to actually doing it? What are the immediate things that people have to own? That’s a step that sometimes people don’t want to take, or they’re afraid to take, or they just don’t take, or they think the other guy’s taking it. I think that that’s the … I use that sports analogy of the ball falls between the center field or the left field. They’re like, “I got it. I got it.” Actually, you don’t got it. Somebody’s got to commit to doing it. That’s part of learning how to work with a team is knowing what’s something you have to do, what’s something the other person has to do?
Bernard: Taking notes also clarifies that thing. It’s like, “Okay, here’s the thing to do. Who’s doing it?” I think part of it is the written reminder of things. Sometimes people have different takeaways from meetings, so that there’s a record of what the discussion was, and not for any mad, bad reason. It’s like sometimes just see things a different way, and they’ll hear something, and they’ll take something different away from it. It’s not just being a note-keeper or an accountant. I think it’s really important to do.
Leonard: One of the main rules of producers is to maintain and ensure communication across the lines and across the group. It makes sense that producers are the one that, in case there’s a discrepancy of knowledge, in this case, there’s people that recall different things, it makes sense that the producers can come back and produce one of those artifacts and say, “Hey, this is what happened. This is what we agreed.”
Bernard: That’s right.
On the importance of building a good plan for time-boxed development
Bernard: [On his experience in PopCap working in Plants vs Zombies 2] …. People hated standups, and people didn’t want to do cost estimates. People didn’t want to sit and plan the work, because it took all day. Yet without those things, you could never have built a system. You could never have built a plan to build a believable production plan to get the team to finish and to make trade-offs.
Bernard: We cut features based on the production plan and the features we listed. If we knew feature X took a month, but we could get features Y and Z if we took back that month, Y and Z were more important than X alone, we’d say, “Okay, we can give up X, we get Y and Z. That’s a good trade-off.” The designers were like, “Okay. I’ll take that trade-off,” but you can’t do that without a plan.
Bernard: I’ll tell another funny story. EA did production audits. They came in, and they asked me some questions and they’re like, “Ha, I don’t believe you can reach your dates.” I told them how my tech director and I built this project estimates, and how his estimates held up to the actual product planning, and that I had all this data that said we could reach this date. I’d be happy to walk them through the spreadsheet.
Bernard: The EA production guy was like, “Na, that’s okay. I believe it.” You have to have the data to be able to have that discussion. EA is paying your paycheck. They want to know that you’re doing the work and that you can get this done on time, and at least you have a plan to try to do it. That’s not to say that that plan will always stay intact, but we did the work. We were trying to make the decisions, the best decisions we could. That’s the stuff that I introduced to PopCap, and PopCap had never really done that before. They didn’t have to.
Bernard: When you don’t have to work on a schedule… you can ask all the Blizzard Titan team, the MMO that got canceled how rigorous were they? Probably not too rigorous, because they had a lot of money, and they were given this luxury of time, and Blizzard makes a lot of money. I didn’t have that impression when I came to PopCap. I’d seen what EA had done to other studios that didn’t perform. I felt like every day I came to work, I wanted to make sure that our team treated the project like the studio depended on it. I think it did.
On optimal detail in planning
Bernard: I think it varies from team to team. I think you both need a bottom up and a top-down approach. Like I think you need documentation that sets the tone and is a reference point for people. It should be simple enough that it doesn’t have to be maintained I detail. I think prototypes also, like actual builds, can also serve as product documentation. I don’t think there’s an easy answer.
Bernard: I tend to believe that a high-level set of user stories is sufficient documentation for a lot of it. For certain stories that are really complex, you may write a much longer document, like a combat system probably doesn’t fall into an easy user story, but a combat system user story may involve a very detailed spreadsheet of values and numbers and weapon types and concept art and things like that that describe all the weapons in the game and the damage and the reload times, and the special buffs that I can give you. There’s a ton of document that can be written about that, but there’s still the core stories feel fairly simple, potentially. Like I’ve got a rifle. I’ve got a shotgun. I’ve got a grenade launcher. I’ve got a knife. There’s probably not a ton of detail that the story needs. If the story needs detail, then you can write supporting documentation for that.
Bernard: The nice thing about the user story is in theory it’s kind of human readable. You can read it and say, “Your hero can scale walls and leap from window to window and climb on features.” If you’re writing the Uncharted user story, you could write what you want the player character to be able to do at any given moment. It’s pretty simple. How you build that system may require documentation and physics and prototypes and video references, but I think the era of, whatever, a 400-page design doc is gone. We don’t do that anymore. A document is only useful if it’s usable.
On good risk management
Leonard: What is your personal approach to risk management? How do you handle the known unknowns, and the unknown knowns?
Bernard: Well, the known unknowns are really pretty straightforward, because you tackle them right away. Those are things that you try to front-load. Any known risk, you want to tackle it first. We’re working on a particular feature for VR right now. One of the implementation features seems pretty risky, because we weren’t sure all the knock-on effects. You want to get the system up and running so you can start playing it first, and there’s where you can make a better evaluation.
Bernard: I think the unknown unknowns, you just have to kind of brace for, because by definition, you don’t know them. But the known unknowns are things like we know this feature has a lot of potential effect, knock-on effects. Why don’t we prototype it and start using it? Put it through a user research session of 10 to 15 users and see what they do? Start getting a feel for how much work it is, and have a contingency. Like, “Yeah, that feature, it’s cool, but to really make it polished and great, it’s going to take us a lot of time. Let’s just do the simpler, less ambitious version.”
On developing VR games
Leonard: Is it very different to do production for a VR game than for a mobile game or for a triple-A game? What has been your experience building for Oculus?
Bernard: I think the biggest learning is working with hardware that … Well, two things. We have nothing to copy, right? As much as Destiny was a great thing, they had built Halo. Anywhere between 60 to 80% of that game was already well understood. All the traversal mechanics, the running, the jumping, the shooting, the environment, they understood that better than anyone else. There’s 20 to 40% of the game that maybe wasn’t understood, but there’s a ton to go off of.
Bernard: When you’re working in VR, there’s no previous blockbuster to copy or even get inspiration from. We’re inventing that new. I think that’s new. Then you’re also working with hardware that’s never existed before. When you’re working first-party, you’re working on hardware that’s not yet released. I think that those are the big challenges of working with early prototypes or EVT or engineering verification test models, which are still in development. The firmware is not done, and the OS’s features are coming online. You just have to be patient. That feature’s not ready yet for you to use. Then it forces you to shuffle your schedule around a little bit. But that’s sort of counter-balanced by the fact that you’re building on something that no one has ever seen before.
Bernard: When we built out some of our experiences for the Rift and the touch controller, no one had good VR hand presence before. Vive’s controllers were really like wands in space. They didn’t try to simulate hand gestures, like pointing and picking up objects and things like that in a way that felt natural. We’re the first people that built an experience like that. That’s super exciting. It was super hard, because the hardware wasn’t working until fairly late, so you had to kind of make due and figure out how to push builds to devices and things like that, but you get the thrill of doing something that hadn’t been done before, which I think is, to me, the best thing about working in VR.
Leonard: Do you ever have to consider motion sickness or anything of the sort when you’re producing for VR?
Bernard: Yeah, I think our team, our goals on my team is just to build something that had the least discomfort for anybody. Want our stuff to be played by everybody. We don’t do things like forced camera movement where the camera moves independently of your head and your body. Other studios may choose to do that, but that’s not something that we do or we have done historically on my team personally, because we want to build the most comfortable, accessible experience for the broadest segment of our owners, our people.
On the future of production as a role in game development
Leonard: How do you see the role of producers evolving in the future? Do you think it is shifting more toward a product owner, product manager role, or will it stay as the hybrid that it is now?
Bernard: I think the more senior you become on a project, the more you end up being a product owner or product manager role, because I think at some point, you’re responsible for not just the operational success of the product, but the business roll-out success of the product. An AP or producer is probably not responsible for the game’s success, but if the game doesn’t succeed because it’s made the wrong trade-offs or made the wrong decisions, that becomes an executive producer or senior producer responsibility, I think. I don’t know. I don’t have really a theory about how that’s going to be. I think that producers, you kind of learn the nuts and bolts of the product. Then you start dipping into the strategic implications of what you’re building and why you’re building it. That’s sort of a natural evolution.
Bernard: Some people may not ever make that jump. Maybe people are very happy being hyper-operational, that they’re always interested in working on a product without the business implications of it. I think that those are people that really find a happy place for themselves inside big teams, or they don’t necessarily want to become an EP or have that responsibility for a product.
Bernard: In that way, I don’t necessarily see it evolving that much. I think as long as you have creative decisions and people working together, production is something that we need, just to keep projects moving and coordinated. I don’t see that that need is going to change in the near future. I think unless you understand the product you’re building more, you want to be involved in helping make good decisions for its overall product success. I think more senior producers become kind of product owners, right? There’s always a healthy tension between the producer and the designer, because they’re both interested in goals. They’re just taking different ways to get, in theory, to the same goal.
Leonard: Okay. Thank you, Bernie. Thank you for giving me an hour of your time. You’ve been very gracious to play along with me for this hour. I’ll take what you just told me and unpack it, digest it, and try to see how it can improve my production game.
Bernard: Well, thanks for being curious. I look forward to hearing from what you’re working on in the future.
Leonard: Thanks. I’m also looking forward to seeing any demos for Oculus. Be sure to keep an eye on that.
Bernard: Yeah, let me know when we have something, and you play it, let me know what you think.
Leonard: I will. I will. Thank you, Bernie. Have a great evening.
Bernard: All right, man. Take care.
