GDC 2014 - Day 2 - Art Leads

The second day of the Art Leadership Roundtable was intended for Lead Artists.  This ended up being re-translated in the announcement to Art Leaders.  This wasn't a major problem other than the fact that it may have set different expectations.  I tried to reset this direction at the beginning of the session.  Ultimately, it just meant we had a large population of attendees -- something that continues to amaze me each year.

Art Leads are often put into their leadership positions without a great deal of leadership training or guidance.  Given that, we should discuss our own leadership challenges.  Where did we (collectively) fail?  How did we resolve the problem?  What did we learn?

 

Lesson 1: External Development

This was a pretty big question and received a fair amount of silence in response.  One bold attendee was the first to raise his hand and talk about working with contractors.  In his particular example, the Lead was challenged with working with an outsourcing team to develop content for his area.  When pressed for the specifics of the problem, the attendee spoke about a "lack of vision" for the project.

When talking about "lack of vision" relative to an outsourcing effort, this can manifest in more than one way.  For one, the external developers (the outsourcing team) may lack the vision.  They may not understand the style.  They may not know the purpose (or the gameplay) behind the content they are generating.  Either way, the Lead is tasked with making sure that the assets being created are consistent and meet the needs of the project.

The other area where "lack of vision" manifests is from the internal team.  The team may fail to understand the vision of how outsourcers are part of the development effort.  They may see external development as the "enemy" and seek out opportunities to point out the failings.

Outsourcing has certainly been a topic of past roundtables, and I won't go into the full breadth of it here.  However, regardless of which "lack of vision" scenario you may be facing, the Lead is going to find themselves in a position of micromanaging the relationship.  First, the Lead will have to micromanage the content being created externally.  Furthermore, this antagonism towards the external team may motivate the Lead to micromanage the internal team to the same degree (out of a sense of fairness, out of a sense of needing to maintain close contact with the onsite team, or out of a perceived need to keep the groups separated).

In this particular case, the attendee spoke of artists being unable to see the fight.  They weren't exposed to the Lead's struggles.  This may have been the fight to bring the external development team in line.  This may have been the struggle with the project directors to get others to see how external development impacting the team.  Regardless, what the team did see was that the Lead's time was being invested more heavily in the external team than the internal team.  This perception led to a growing loss of trust.

How was this resolved?

In this particular story, the problem was resolved by bringing a new Lead into the picture.  Although a change-up in leadership is rarely desirable (and always difficult), sometimes it is necessary in order to reset expectations.  The new Lead then set up regular one-on-one's with each member of the team to 1.) preserve the vision of the project and the understanding of outsourcing's place in the development goals and 2.) ensure that regular contact between the Lead and the internal team members was happening.

Lesson 2: Student Project

The next attendee to speak up was a Lead on a student project.  Rather than immediately dismiss the student project as "not real game development," I wanted to hear more.  I suspected there was something to be learned in this example, and so I encouraged the participant to share more of the experience.

The basic description was that, as a student project, it was relatively small with limited resources.  However, there were a lot of unmet expectations from the various team members and the project ended up a mess in the end.  The attendee was looking for direction from the audience on how to address these types of projects in the future.

So, how do try to resolve this type of scenario?

Several suggestions were offered.  For one, build a scalable project with clear "kill gates" when you start missing deadlines.  More importantly, establish more frequent check-ins between all team members (especially in the early stages of development).  The check-ins should be focused on priorities and current status as well as an opportunity to reinforce expectations.

In addition, despite being a smaller student project, it was suggested that clear milestones be partnered with an asset tracker.  "Done" can mean different things to different individuals, and so an asset tracker could help ground progress in reality and the milestones can be tied to the specific kill gates as that second layer of reinforcement.

Another attendee suggested that students not jump straight into trying to create the final project.  Rather, attempt some smaller and time-boxed projects.  Spend ~1 week doing a demo (or vertical slice, or core combat, etc.).  These will accomplish two things.  One, it will prove out the technical feasibility as well as scope of the overall project.  Two, it will teach the team how to work together or prove out which members of the team aren't a fit.

It was also suggested that the team formalize its structure.  Even a small team should have clear areas of authority and responsibility.  However, in the case of any student project, this MUST be supported by the instructor or faculty.  Failure to meet your responsibilities must have real consequences -- just like the real world.  The problem with student projects is that technically everyone is a peer.  Formalizing your structure (with faculty support) will break through any perceived ambivalence or half-assed contribution.

Lastly, student groups should investigate how successful mod communities organize themselves.  There are groups who have figured out how to operate in similar situations.  There's no upside to figuring it out on your own when others have already learned the hard lessons.

Lesson 3: Inexperienced Authority

This is a tough one.  The next participant to share with the roundtable spoke about their experiences working with an outside party.  This individual(s) had a great deal of authority over the project, but not much experience working with the actual development team.  This is an extremely common thread, and it is one that persists in relationships where the development team is independent of the publisher.

Regardless of the specifics of the scenario, it doesn't take much effort to see how the relationship can potentially go badly.  I can speak from personal experience when saying that this type of scenario spins out of control from a lack of respect or consideration between the two entities (developer & publisher).  In this particular tale, the attendee spoke about a growing lack of trust and the diminishing sense of ownership.  Ultimately, the issue did not get resolved and the project died.

How do you resolve this type of situation in the future?

There was a variety of advice offered for when the relationship starts to sour.  To start off, you should make it your responsibility to be the first to involve the other entity in your work.  Maybe you setup regular checkpoints.  Maybe you establish monthly milestone reviews.  Moreover, you make sure that the other group feels like they are part of your group (rather than being separate).  If possible, make them feel part of the creative process.  The whole goal is to engender trust -- with the realization that this also takes time (and consistency).

Someone pointed out an interesting perception while on this topic:  Too many artists don't care about the business of making games.  While I am not going to claim to know the overall trend of artists across our entire industry, I can say that I have certainly spoken with a lot of artists who are reinforcing this perception.  The only counter to this limited mindset is through educating younger (and sometimes seasoned-yet-myopic) developers in the business of game development.  This is difficult as there has generally been a "behind the curtain" approach to the business of development for years.  This is something I feel needs to be stripped away.  I could probably write a separate blog post about this topic alone.

However, in the short term, it is for this reason that I elect to refer to our profession as game developers rather than artists, designers, engineers, producers, etc.  The latter are our roles in development.  But we are all developers.  The adherence to the role or the title does more to separate than it does to unite.  It is also for this reason that I changed the name of the roundtable from the Art Director & Lead Artist Roundtable to the Art Leadership Roundtable.

Lesson 3.1:  Catharsis

In response to the previous topic, one attendee shared a story about about a publisher (who is no longer in business) who was only interested in copying another publisher's game and just giving it a different title.  We see a lot of this in our industry, but this particular tale was exacerbated by the fact that the publisher's desired source kept changing based on whatever new best-selling game had come out the previous quarter.

There was no resolution to this problem.  It was purely catharsis.  And yet, a small lesson can be found.  Some problems can't be fixed.  Sometimes leadership lands in the hands of the ill-prepared.  Sometimes you are required to follow direction, even if you don't agree.  And sometimes things fail, despite everyone's best intentions.

Catharsis can be closure.  However, I will also caution that catharsis should never be used an excuse not to think about (and learn from) past experiences.

Lesson 4: How I Killed a Project

Candidly, I didn't take very good notes as the next attendee shared his personal story.  The short version, as I recall it, was that he was the new Lead on a small team with a rather extensive (and unrealistic) scope.  As the Lead, he felt compelled to constantly make sure the team was doing what he wanted them to do, to work himself as hard as possible and maintain control over the whole development cycle.  He felt responsible for creating the best work in the game and also for fixing the work of others that didn't meet his expectations.  The attendee spoke openly about the frustration he felt from the team, of the ridiculous hours he worked and of his own waning health during the worst of the development cycle.

He then told everyone that the project was completed.  The previous paragraph doesn't do his tale justice.  As such, I should point out that no one in the room expected the project (as he described it) to have been completed successfully.

How did he resolve the situation?

When pressed for details on how the project recovered, the attendee admitted that he couldn't accurately recall that development cycle.  The long hours and high stress had robbed him of the memories of the experience (kinda like child birth, I guess?).  I seem to recall this was also his last development cycle and that he had since moved on to academic and a teaching position.

Given that, I pressed him for any lessons he feel like he learned going through the experience.  First and foremost, he talked about realizing that the leader can't always be "on the front line" themselves.  The lead has to learn to delegate and entrust responsibility to others.  Moreover, he talked about setting realistic expectations.  The team was small and the scope of the project was already unrealistic.  This created an environment whereupon more unrealistic expectations could be heaped.  As such, he set unrealistic expectations for himself, for the new hires to the team, for the quality of the work and for the scope of the project.  Ultimately, the most significant unrealistic expectation he set was for himself -- and yet the project was completed.

I feel confident assuming that there are some of you reading this right now who are reflecting back on your own experiences in our industry.  Reflecting on your own unrealistic expectations.  How did that work out for you?  Was it a better project in the end?  Were you a better developer?  Or did the cost prove too high?  Did you learn something from it?

Practical Resources in Leadership

For the last 10 minutes of the roundtable, I asked the attendees to shout out key philosophies as well as resources (books, videos, training, etc.) that had helped them become better leaders.

I've already collected that list in a separate blog post.  If you haven't read it yet, check it out here:
http://hyphenatedkeith.blogspot.com/2014/05/gdc2014-become-better-leader.html

 

Speaker Evaluation

As before, I wanted to do something new with the write-up this year.  Here is the raw, unedited report from the day's roundtable.  If I felt a comment warranted a response, I added it below in orange text.

Art Leadership Roundtable: Art Leaders

Thursday, March 20 from 4:00 PM to 5:00 PM

Room 112, North Hall

Total Headcount: 82

Percentage of Evaluations Returned: 42.68%

Percentile in Visual Arts Track: 91st

Percentile in Overall GDC Main Sessions: 86th

Session Totals (This Session)			All Main Sessions	Visual Arts Track
Response	Count	Percentage of Responses	Average Percentage of Responses	Average Percentage of Responses
Excellent	27	77.14%	62.42%	57.67%
Good	7	20.00%	31.02%	34.84%
Poor	1	2.86%	5.61%	6.59%
Terrible	0	0.00%	0.95%	0.91%

Comments

First of all, thank you also for all of the kind words written below.  I appreciate that people are willing to invest their time attending these sessions.  I hope that others are learning from the roundtable and building long-term relationships across the industry. 

 Best round table of the conference, Keith is amazing as a moderator and a leader

Very good learning lessons and experiences

A little scattered, ended well

This was my very favorite pannel, learned a lot

This was awesome!

As long as the "horror stories" are followed up by times of learning, analysis, and review, it's even better.  Keith does a good job of leading the roundtable, making sure it proves challenging instead of just a swapping stories sessions.  A larger room would be better as a lot of people wanted to get into the roundtable, but could not.
I concur.  Sharing failures is only valuable if we share what was learned or how to react when faced with a similar challenge.  Unfortunately, I disagree with the larger room.  We've tried that in years past and I feel that it does more to hinder interaction than encourage discussion.  However, I agree with the sentiment that it is unfortunate that not everyone can attend.  I hope some of those who don't make it through the door at least get something from these posts.

Content was relevant and the roundtable was run in an efficient, focused way. 90 minute session would be more productive.
I've asked for a 90-minute session.  We'll see if that ever happens. :)

This is the most valuable aspect of GDC by far. I just wish they weren't becoming so crowded!

great panel.

I normally love this session. This particular one seemed like it lacked focus, and was geared towards bitching about problems.
I apologize if the discussion seemed to come across as "bitching."  The intent was sharing and learning.  I agree that there is a fine line and I will try in future sessions to make sure we're on the correct side of it as much as possible.

Very honest feedback and discussions! Would love to see moderated so others can speak as a few select contributors dominated the floor time. 
Good feedback.  Thank you.

 NEEDED MORE TIME!!!!!!!!!!

Best sessions of GDC

It was an alright round table. I feel like not much came from the discussion though. I feel like more topics could have been covered.
This is a perpetual struggle.  More depth or more breadth?  I do try to find the right balance or "judge the room" for when a topic has momentum or needs to be shifted.