Game Develops Conference 2016

If you've come here for the notes from the Art Leadership Roundtables, you've come to the right place.  I apologize that they are not yet ready to post.

The good news is that I have started transcribing the notes from all 3 days.  The bad news is that post-GDC plague, taxes and family commitments yielded delays in their delivery.

I haven't yet given up, and as soon as they're ready, all will be notified.  Thank you for your patience and expect an update within the next month.

Cheers.

Back End of the Bell Curve

Or. ...  Being a recruiter is hard

With GDC 2016 around the corner, I wanted to prep some topics for the Art Leadership Roundtable. One of the topics I'd like to discuss is identifying and addressing poor performance. In fact, this whole post was going to be about what I call "the ass end of the bell curve"

I won't go into an elaborate description.  Succinctly, in any organization there is a distribution of performance. For those who haven't done this, if you plot performance against population, you see a bell curve. A select few inhabit both the bottom and top performer ranks with the rest being scattered in the middle ground -- this is still true even in "high performance" environments.

I've been fortunate enough through my career to really work with some amazing developers who clearly inhabited the top tier of performance. Like everyone else, I've also witnessed a number of people who inhabited the "ass end."  But, as I said, this was going to be about the bell curve.

Instead, I've decided to talk about recruiting.

Recruiting for a studio is hard. I've had to source talent for projects over the years.  I recently received a message from a third-party recruiter that was such a powerful example of the ass end of the bell curve that I couldn't help but share.

I'm keeping the recruiter's identity confidential, but it's worth sharing this as I see it as a teachable moment:

First of all, this initial contact lacks even the vaguest attempt to personalize the message. Other than my name, this is likely the same block of text that several dozen other potential candidates received.  One of the first rules of sourcing a candidate is to know who you're contacting. Do a little research. How long have they been in the industry and what types of positions have they held?  Is it someone at the beginning of their career, or a veteran?  The reason to do this is to make the candidate feel special.  Even if the candidate isn't interested, the recruiter should make an effort to make the candidate feel valued.  This is not accomplished via bulk email formatting.

Now, let's break down the information in the message:

Sony Amsterdam, huh?  Okay, this isn't a problem for the recipient but highlights a lack of experience by a third party recruiter. You don't tell the candidate who your client is. For those who may not know, third party recruiters almost always collect a commission if the person they source is hired (percentage of starting salary).  If the candidate knows who has the opening, then there's nothing stopping that person from just applying directly and bypassing the recruiter entirely.  Also, sometimes companies don't like the recruiter mentioning them by name in initial contact as some people don't like working with recruiters.  For this reason, the client may not want their company's name associated with a poor recruiter experience.

It's never a bad idea to mention a few perks. However, I question this recruiter's choice of "perks" for the initial email.  Free games?  Great, but that's not really the bait you use to attract talent with more than a handful of years of experience. Subsidized public transportation?  I don't know what to make of that.  Are you implying the pay grade is so low that public transportation represents a significant portion of the salary, to which the studio is willing to contribute?  It's just a ... weird ... choice to list as a perk.

Just to be clear, this recruiter is trying to sell me on international relocation.  Two months free rent?  I wouldn't classify that as an amazing offer, but rather standard and certainly a minimum for international relocation.

2000 euros?  Seriously?  This recruiter is trying to pitch me international relocation at that price?  We've already established that the author knows nothing about me. Am I single?  Am I married or have a family?  Do I rent or own a home?  The author quoted actual numbers in initial contact - generally considered a faux pas in almost all situations - without learning a thing about me.

For those who are interested (converting to USD but without adjusting for inflation) that's a little less than what it cost me to move myself and my wife from Indiana to California in early 2000.  The suggestion that I could relocate my family to Amsterdam in 2016 within a 2000 euro budget is either absurd or the recruiter left off a zero.

Hopefully you readers now understand why I'm sharing this as an example of the ass end of the bell curve.  Recruiting is an incredibly difficult job and I have a lot of respect for those who do it well.  It is worth noting that this is not the worst interaction I've ever had with a recruiter in my career.

However, this was bad. This was so bad in fact, that I had to share. I wanted to share it with you readers. More importantly, I have many good friends who work at Sony.  As such, I passed this message along to the head of talent acquisition at Sony. I know that, we're I working at Sony, I would want to know if a third party recruiter was poorly representing my organization.

Like Batman....

Clearly, I have found a Lazarus Pit....

It's good to be back.  With the GDC Art Leadership Roundtable just a few short months away, it felt that now was the right time to return to this blog.  Both personal and professional challenges of the past year kept me away from writing for the past year.  I'm hoping that this first post of 2016 can be a sign of better things to come.

I've spent a fair amount of time recently thinking about the Project Management Triangle or the Cost-Scope-Time Triangle or any of the myriad other shapes and terms by which it is known.

Instead of focusing on any one of these attributes, I instead wanted to bring to mind a relative under-addressed axis called complexity.

Complexity is often combined with Scope and/or Quality, but I believe this to be a confabulation of sorts.  This is especially true in the game development industry.  For me, simplicity/complexity is the force multiplier; it moves the whole triangle.

To illustrate my point, think about Riot's League of Legends or Rockstar's Grand Theft Auto.  Most people would agree that the scope of LoL is smaller than the scope of GTA (though time continues to narrow that gap by significant amounts).  Though different in scope, I expect there underlying gameplay systems have similar levels of complexity.  However, I also presume that their asset pipelines are quite different.  Comparing the rapid content updates of LoL to the prolonged release schedules of GTA titles clearly indicates that LoL has a less complex asset pipeline.  Obviously, there are numerous other underlying factors that speak to their scope and complexity, but this example alone shows why you can't combine the two.  Likewise, one would say that the relative quality of each title (aside from purely subjective taste) is comparatively the same.

Complexity is an axis worthy of more significant contemplation.  Where does the complexity reside within your project?
Are your gameplay systems simple or complex?
Is your asset pipeline simple or complex?
Is your workflow simple or complex?
(Note: It would likely be far more telling to plot these answers on a scale rather than purely binary.  Ask the same questions of different departments, and collect their answers.  What variations to see in the data?  Do the gaps tell you anything about the team's perceptions?)

People will always ask how to get a project done faster and cheaper without sacrificing quality.  The logical next question should be: how to make it simpler?

Reflections

Wow.  That was a particularly extended hiatus from posting, huh?  Simply put, I haven't felt like writing for a while and I didn't have a lot that I wanted to share.  However, that's going to change in these last few months before the end of the year.

With, TITAN officially cancelled:

And with OVERWATCH officially announced:

I feel like I can now write about my experiences at Blizzard.  For the record, I left Blizzard earlier this month to pursue new opportunities.  Regardless, I am still bound by my NDA and so what I plan to share in the near future will be focused more on lessons learned and personal observations.

If you come here expecting juicy gossip or spoilers, you've come to the wrong place.  However, if you come here to read about industry leadership, then "stay awhile and listen" (read, actually).

 

More to come soon.

GDC 2014 - Day 3 - Artists

The third and final day of the Art Leadership Roundtable was intended for Artists.  By the last day of GDC, people tend to be tired and a bit less-likely to speak up.  As such, I've learned to permit the topics to run a bit longer and on less-dramatic topics.  Given that the day's topics were intended to be Artist-centric, I wanted to provide a chance for mentorship -- a chance for art leaders to answer the questions that artists might have.

There are many art leaders in this room.  But we didn't start out as art leaders.  We started out as artists.  Then we found ourselves in leadership positions and we stumbled and failed and learned and became better leaders with time.  This session is about giving back to the artists -- to the next generation.  What questions do artists have about leadership or direction?  What insight can we provide into how projects and teams are managed?

The session got off to a rocky start.  If I recall correctly, the first person asked how to get artists to relinquish the rights to their artwork for use in mobile applications.  Interesting question, but completely unrelated to the topic that was proposed.  One person responded with "talk to a lawyer" and then we quickly redirected away.

The second attendee to respond presented a much more relevant issue.  I can't remember exactly how the question was phrased, but the key concern was getting artists to do what tech art is telling them to do.  The speaker expressed frustration in working with artists who only care about the visuals and don't want to understand how the pipeline works or care about technical limitations.  What I wrote on the notepad was:  Tech Art vs. Art.  FIGHT!  However, this is a very real concern that exists at the intersection between visual goals and the medium (technical limitations) within which we work.

Given the way the question was phrased, attendees were asked what techniques they used to engage artists in the pipeline and technical processes early in development.  Here are the suggestions that were offered:

• Work with a select group of artists (role models) to create benchmark visuals which lead the content creators to the pipeline.  Show them the results first, then the tools that achieve those results (rather than the reverse).  In short, make the tools part of the art style.
• When it comes to tools development, involve artists in the mockups of interactivity.  Encourage them to think about user experience.  How the tool functions is just as important as what it does.
• Active technical mentorship.  Weekly discussions or informal "brown bag" lunches where pipelines and tools are open to discussion and dissection.
• In the cases of student projects (where some students create content and others create rigs), implement a clear mediator (faculty) to resolve conflict.
• Develop visual documentation.  Documenting tools is an important component, but artists tend not to read long-winded instruction docs.  Image-heavy documentation is more likely to be read and understood.
• When creating new tools, ensure you're focusing first on the big problems.  Leave the micro-details for later.  Over-engineering is the Achilles' heel of tech art, and artist-involvement can help to avoid that scenario.
• When new pipelines are implemented, make sure artists are actively using them from that first day.  Don't roll out a new tool that artists aren't planning to use until 2 months later.  Coordinate development to happen concurrently so that the tool evolves with the art staff.

We also talked about why this type of issue arises.  What causes fractures to erupt between the tools group and content group?

• Authoring tools without input from the users.  In this scenario, artists are less likely to use a tool if they felt it was created without their opinions given reasonable consideration.
• No clear value.  People are inherently suspicious of change and new tool deployments are no exception.  Artists won't embrace a tool that is rolled out without a sense of investment or especially if they fail to understand the benefit.

Last, we talked about how to keep a fracture from forming when tool deployments fail or the unexpected happens (as it often does).

• When things go wrong, involve the artists proactively.  Postmortem new tools quickly and be clear about what next steps will be taken (and which won't be taken).  The whole purpose should be to define and redefine the goals.
• Encourage artists to question the workflow/pipeline.  Just like games, rarely are tools perfect on their first iteration.  Artists need to be open to the iterative process, but they will only engage in that process if they feel encouraged to engage and see the results of their feedback take shape in future iterations.

There were a handful of other comments offered, but all of these represent the most significant components.  Artists need to be involved in tools development.  And tech artists need to engage them.  This is about the craft of what we do.  The final result will amount to shockingly little if people refuse to pursue the craft, but the responsibility belongs to both parties.  Exploration and iteration are cultural components of learning.  Learning is how we progress.  If we fail in that charge, we fail to advance our discipline and our industry.

As the topic was drifting to an end at this point, I asked the attendees if there were any more questions from artists that people in leaderships could respond to.  One student attendee was bold enough to raise her hand and ask the following.

Why aren't more studios hiring for entry-level positions?  How are students expected to get into the industry in the current workforce climate?

• As to the why, the first response highlighted the cost in mentorship and training.  Much has already been written and discussed about the competitiveness about the job market.  However, the additional reality is that it requires a lot of effort to "train up" new hires with little experience.
• As to the how, another attendee responded that students need to be prepared to do literally anything to get that first industry position.  If they are still students, they should be applying for internships.  If they've completed school, then they need to look for tangential entry-points such as QA.  In fact, this comment was repeated multiple times in many ways, the culmination being to just "get through the door."
• At this time, the counterpoint was offered that QA Leads and Managers hate losing good people to development teams.  It is frustrating to train people into a position where they have impact and then lose them once they've built up a breadth of knowledge.  When pressed for how to successfully initiate such a transition, it was suggested that those entering QA speak to their long term plan but also be dedicated to the QA role for which they are applying.
• Another responder commented that their studio is more isolated from the industry, and so they make more of a concentrated effort to draw hires directly from the schools.  The implied suggestion here was that students should explore studios that aren't already in dense, competitive market locations.
• The comment was offered that too many students or recent graduates are expecting to just land in a AAA studio right out of the gate.  This person strongly suggested that job seekers have more realistic expectations.  Given their overall lack of experience, it was suggested that they tap into the indie development community, where they might be able to explore contract opportunities that could afford some early experience.  They should also actively pursue contributing to a mod, a gamejam, a hackathon or whatever else might build upon their experience and expand their network.
• Wisely, another attendee suggested that students really need to solicit and collect personalized portfolio feedback.  Many schools are cranking out students whose portfolios are largely interchangeable and fail to highlight the students' individual strengths or area of interest.  I can agree that I've seen way too many of these as well.  In order to combat the pool of portfolio mediocrity, students need to network with the intent of soliciting feedback.  When you get out of school, you have a job -- that job is to replace everything in portfolio with a stronger piece.
• Although I don't recall the context, the book Mastery by Robert Greene was recommended.  LINK
• Another attendee lamented that students miss out on opportunities from poor philosophical instruction in school.  Students become so focused on creating the "cool piece" that they fail to grasp the context.  They don't think about how the content is part of the product.  In order to combat this problem, it was suggested that students build a "visual experience" instead of just things and then actively share their work with the greater artistic community to get feedback.
• On a related note, it was also strongly suggested that students and new developers become more visible in the development community.  They should be participating on forums and in art challenges.  This was coupled with the feedback that it is no longer sufficient to simply submit a resume and a cover letter.
• The final (and frequently heard) comment was that new artists need to cater their portfolio to the prospective employer.  They must also be willing to build long-term relationships and not become bitter if it takes a long time to land your "dream job."

Although there was only time for two topics, the day ended on a high note.  Once more, I would like to thank everyone who attended.  Below you will find the unedited feedback from the session.  My comments, if warranted, were added in orange.

Art Leadership Roundtable: Artists

Friday, March 21 from 2:30 PM to 3:30 PM

Room 112, North Hall

Total Headcount: 82

Percentage of Evaluations Returned: 42.68%

Percentile in Visual Arts Track: 35th

Percentile in Overall GDC Main Sessions: 37th

Session Totals (This Session)			All Main Sessions	Visual Arts Track
Response	Count	Percentage of Responses	Average Percentage of Responses	Average Percentage of Responses
Excellent	22	62.86%	62.42%	57.67%
Good	8	22.86%	31.02%	34.84%
Poor	4	11.43%	5.61%	6.59%
Terrible	1	2.86%	0.95%	0.91%

Comments

Very insightful and helped to network quite a bit. Surrounded by the people you want to work with and having them help me get started in the industry is just wonderful.

This was a leadership round table and we talked way too much about how to get a job as a student which we aren't anymore.
While I understand the sentiment, the simple fact is that there are MANY students in attendance at GDC every year.  The idea that their questions should be ignored is unwise and, in my opinion, an example of poor leadership

The third session was dedicated to artists but focused on new artists entering the industry. That should've been done in a careers roundtable versus an art leadership roundtable. He should've focused on the art leadership and art management. I waited in the first two sessions and did not get in. Was looking forward to a revamp of the things they discussed in those meetings at this one. Will try again next year.
I regret that you were unable to attend the previous sessions.  I hope that you are able to learn from the notes from those dates.

This was pretty great. Answered a lot of questions.

I was very very disappointed in this session. I think that the type of artists to attend this suggestion should have been defined as technical artists.  This clearly was not for artists who deal with mobile devices. I was very disappointed that my question on licensing art was clearly told that it would be discussed if needed after this session. What is the audience you expected to come to this session? Perhaps there needs to be a session for casual gaming or casual gaming art.  Artists are used in this format as well considering this is a GDC not just in the XBOX or playstation platforms.
I'm sorry you felt this way.  However, I fail to see how an exploration of the question of tech art / tools or gaining entrance to the industry is exclusionary towards mobile development.  Given the fact that your question about licensing art received silence and blank stares from the room, I think it was reasonable to redirect rather than to force a topic without traction.

This was my first roundtable.  Keith was great at leading the discussion and keeping the room on topic.  I primarily attended this one despite some others I was interested in because it was not recorded for the Vault.  It was interesting, but I think I may stick to the regular talks in the future.

Keith has a good command of the room, although I was a little disappointed in what we discussed in the roundtable. A lot of it seemed like rehashing of information about how to break into game art that I've seen plastered all over the internet.

great information and topics discussed for new and old art directors.

Keith did a nice job moderating this roundtable. The group did not have a great number of ideas they wanted to discuss at first, so he goosed the conversation. It flowed nicely from there. His follow-up promise of notes from the roundtable sessions are also greatly appreciated for those of us that could not make earlier ones.

Good discussion.

again iT NEEDS TO BE LONGER!!!!!!!!!!!!!

Best part of GDC for me.

Always a good dicussion

Talk was ok, a bit too much focus on "How do i get a job as a student"

Keith is a fantastic moderator - best of all the roundtables I have attended at GDC.  Please bring him back for future sessions.

 

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.