Search

We had a focus. We had a staff. We had students. So how’d the first year go?

The short version of the story is it went really well. Things weren’t perfect of course – on day one of the first year I told our 20 participants they were part of the DSGA Beta 1.0 and part of their job would be to help us make Beta 2.0 better. They did a terrific job of that, letting us know through their words and actions where we were succeeding and where we were falling short. Let’s just say they weren’t shy!

On the plus side, our plan to split each day into morning lectures and afternoon lab worked pretty much as planned.

In the morning, we lectured, laying out the concepts of leadership and management. We covered the mundane (what the heck is leadership and how does it differ from management?… how do you brainstorm?… how do you create a compelling resume; how do you interview; and how do you network effectively to enhance the odds of getting a job?… even how to run a meeting so everyone isn’t driven mad!).

We covered, well, whatever the opposite of mundane is (how to conceptualize, flesh out and pitch a concept… how to deal with interpersonal conflict… how to communicate across disciplines… how to turn a bunch of individuals of varying skill levels and diverse backgrounds into a great team with shared goals… how to set up the conditions in which positive studio cultures form… what bumps, challenges and changing expectations you should expect to encounter as you advance in your career…).

And in between, we covered the nuts and bolts of project management (strengths and weaknesses of various team structures… strengths and weaknesses of various project management methodologies… how to work with QA… how to deal with requests from executives who can be, let’s be honest, random at times… how to parse a P&L…)

Obviously, we tried to provide tools for taking the conceptual aspects of these leadership and management issues so they could be applied in the practical environment of actual game development, as experienced in the lab.

The lab itself worked pretty well, too.

For sure, those of us who’d been through building start-ups felt right at home. We had too many people in too little space. We had people with varying levels of knowledge of the their disciplines as well as the softer skills necessary to make a game together. We had people feeling each other out to determine who would be buddies and who wouldn’t. We had people complaining about chairs and where they had to sit. Like I said – it was just like a start-up studio.

But there were some differences as well. Because of our lecture schedule, we didn’t start lab time – actual game development – until after lunch (1-ish), and though the participants all felt they were working hard, their experience didn’t exactly reflect the reality of game development, where hours tend to be long and expectations high. Let me be clear – several of our students put in a lot of time and worked as hard as I would expect any professional to work. But there was a definite tendency for the lab to empty out around 5 p.m. except for our stalwarts. The staff expectation was that the whole team would be in there longer, working until tasks were completed rather than to a time limit. Next year, we’re going to make sure our dedicated few don’t get left alone “after hours!”

Another big difference between real world development and the DSGA was our commitment to giving everyone a chance to lead the team of 20. To accomplish that, we put into practice a plan involving a rotating leadership structure. Every three weeks a different pair of participants would take on the roles of Producer and Game Director (Creative Lead), and those new leads could (if they made their case to the staff) actually change the team structure during their tenure. In practice, this didn’t happen often, but it did happen. Though roles and team structures do change in the real world, they rarely change that often or that regularly, and participants had a hard time maintaining the kind of consistency you look for, both on the management and creative sides of game development. We have some ideas about how to address the artificiality of that approach in year two, without compromising on the idea that everyone will get a chance to lead the team of 20.

Finally, as far as the class/lab split went, we didn’t always see people putting into practice in lab the lessons learned in class. There were communication, skill level and creative clashes exactly like you’d expect in the real world. But where we expected everyone to go right from concept to practice to address those challenges more effectively than untrained (or experientially trained) leaders might, some of the participants had trouble with that. To be clear, many of them were able to use the tools we gave them to lead our diverse team members effectively, but others of them foundered when putting things into practice. This coming year, we’re going to use a lot more exercises and roleplaying to ensure that more of our participants are successful in bridging that concept/practice gap, to their benefit and to the benefit of team and project.

At the end of the day, despite some hiccups, I think it’s safe to say that all 20 participants left with an understanding of how hard the jobs of project leadership and management are. They learned how hard it is to keep a team motivated during an extended development cycle. They learned what it means to be an effective team member and a leader regardless of title and position on a team. All wins…

And here’s one of the most amazing things to me: Despite hiccups, despite radical (though not unrealistic) creative changes along the way and some team restructurings implemented by different leadership duos, the end result was a complete, playable game – The Calm Before (which you can check out here: http://thecalmbeforegame.com/). I told everyone at UT that a completed game wasn’t the product they should expect at the end of the program – the students and what they learned would be the product – but a good, fun, replayable game DID come out of it. (It actually had some of the multi-solution/multi-path stuff I love so much in games.)

So, that’s the high level on class and lab. There were two other aspects of the program that I thought worked really, really well – mentoring and guest visits.

Taking that first one first, the staff met with participants one-on-one on a regular basis, discussing the unique challenges each of them experienced, as a team member and as a lead. The personal and professional growth I saw in our participants as a result of these one-on-ones was inspiring. Of all the things we did, I think these sessions may have been the most valuable.

And then there were guest lectures. We had over 30 industry folks come in to talk about their experiences as game development leaders, as entrepreneurs, as business experts, as discipline leads, and as industry pundits. I’ve been making games for over 30 years and I learned a TON from these folks. Each guest stuck around for an informal lunch, where students could ask questions, engage in conversations and just hang out with people most game developers never even get to meet in their entire careers. I mean, we had the Creative Director from Harmonix come by… founders of Bioware, Bethesda and Certain Affinity… the co-creator of Words with Friends… the President of the Entertainment Software Association… legends like Richard Garriott… industry analysts like Michael Pachter… experts in analytics, HR, game law, contracts, games as a service and even more. The varied viewpoints were critical to what we were trying to accomplish at the DSGA – “there’s no one right way” was one of our mantras – and our students were able to make some amazing connections.

Oh, yeah, and when the program came to an end, many of our students made effective use of the tools we taught, the career fair we organized and the networking opportunities they had and got some really good jobs – at Telltale, Gearbox, Turbine, Disney, 2K and elsewhere.

One Response to “DSGA year one recap, part 5”

I’m Interested to know how you’re going to adjust the lab time aspect – are you going to encourage those who left on time to stay late, or those who stay late to go home on time?

This kind of issue seems key to the culture of a game studio. The ‘working late’ culture seeming to be more dominant in the industry as a whole, and suits keen students but it easily becomes pathological over time. It’s not universal though. The studios I’ve worked in have been fastidious about kicking the developers out on time. Perhaps you could try both methods?