GDC 2017 - Art Leadership Roundtable - Day 2

For the next day, I really wanted to just open the roundtable up to any attendee who had questions or topics that they were wanted to discuss.  For those who haven't attended my roundtables in the past, you should know that it's pretty much first-come-first serve.

The first person to raise their hand asked the following:  How do you deal with a (senior) developer who openly challenges you?  The following suggestions were offered in response.

• Speak to your own boss.  As much as this may feel like "telling on someone," the purpose should be for you to develop a strategy to deal with the issue.  If it becomes too problematic, then the issue can be escalated.  However, working through the problem with a colleague may provide different insight.
• Avoid "stooping to their level" in the sense of disrespect should not be met with equal disrespect.  This will fail to resolve the issue and further compounds the problem by causing you to act in a way which is not professional.
• Make sure the difference in roles is clear.  Sometimes individuals are insubordinate towards authority, but more often individuals may not be aware of responsibility and accountability.
• One attendee suggested that you try to "reframe to be the supporter."  This is a delicate strategy to employ.  This doesn't mean that you reinforce their challenges, but rather offer them the chance to express why their idea is better.  In short, you take the stance of finding the best solution rather than whose it comes from.  The onus then follows on the other person to advocate, while you hold the responsibility of final say.  At a minimum, this can help reinforce an atmosphere of collaboration with the larger group.
• You should also have a direct conversation with this individual in private.  Act quickly and try to get to the core of the matter.  Listen to their story.  As a lead, you do want others to feel like they are part of the process.  However, that doesn't mean that you have to tolerate open hostility.
• Another attendee recommended the book "Crucial Conversations" as a guide on how to approach critical conversations.

The next topic that was put before the roundtable was centered upon a small studio who is currently growing.  While they have no formal managers, they have identified a need to create a more clear structure.  As such, they were looking for advice on how to manage through this type of change.

• The first recommendation was to avoid putting people into positions you just need to fill, regardless of skills.  Rather, match the skills of your staff to the positions that are available.  If you have positions with no skill match, then you're better off opening the position to applicants.
• For the comfort of the team going through this restructure, make sure you clarify what the goals are and what you want out of the structure.  This gives the team to best possibility of supporting the change and potentially helping achieving the goal.
• Assuming that your new structure also defines new career paths, make it possible for developers to have career paths that don't require becoming a lead or manager.  Develop a career path for craft experts as well.
• One attendee suggested avoiding the term "manager" all together and instead finding "owners" to avoid frustration during the change.
• Clarify that you are changing the responsibility structure, not the communication structure.  Developers sometimes confuse organizational hierarchy with how they interact and this should not be the case.
• Lastly, do not rush the process.  Organizational change is difficult.  Work through the problems and resistance rather than avoiding difficult conversations.

The last major topic of the day focused on crunch.  How do people handle crunch, or any situation where there is simply more work than time.

How do people handle crunch -- situation where there is simply more work than time?

• In this particular instance, the art director and the lead were taking on the majority of the extra work to "save" everyone else.
• While this is a common and somewhat noble goal, a number of people voiced concern that this isn't practical or effective in the long run.  The AD/Lead is still required to maintain the vision.  They are expected to guide others, not to take on the responsibility alone.  You have to pull back to the broad view to preserve perspective.
• Statistically speaking, there is reduced return on investment if the organization relies on the same small group of individuals to handle crunch in every instance.
• Delegate anyway.  Delegation is how you challenge others and is also how people advance in their own careers.
• Have you looked at reducing scope?  Although this is an obvious question, it should unveil some potential problems in your development process.  Sometimes scope is crafted with little insight into development bandwidth.  Sometimes there are late additions -- without the requisite subtractions.  It is often too late to resolve crunch late in the process, but crunch should be seen as an indicator of where something went "wrong" (not bad).  Use this as a litmus test for how to improve your planning.  What are the early warning signs?  If those are observed, rescope quickly.
• Look for alternative solutions to scope cuts.  Are there other resources that haven't been explored/utilized?  For example, are there individuals in other departments who aren't crunching, but who are interested in helping out or learning more in a different area.
• Although "crunch" has a strong negative connotation, I asked the roundtable (by show of hands) who had experienced positive crunch.  A number of hands went into the air.  Crunch can be a positive experience.  For example, crunching because you're passionate and want to make something even better is good.  Crunching because your pipeline is terrible or because the culture mandates it is bad.  Two key things were proffered as critical to crunch effectiveness and morale.
• Community building.  It's awful to be forced to crunch because someone else is.  However, it can be culture-affirming if the crunch is felt across the group.  This is most effective when it is managed bottom-up.  "We want to work together to get this done.  This is important to us."  This is decidedly different from top-down managed crunch.  "We need you to come in this weekend.  You aren't working hard enough."
• Timing is everything.  I'm sure most people have seen a project enthusiasm or tranisition curve.  Most studios have learned to make crunch cyclical rather than persistent.  However, there haven't been many who take into account the excitement curve.  Unsurprisingly, crunch at the bottom of a curve is far more problematic than crunching during ascension, when enthusiasm is growing.

Speaker Evaluation

Once again, here is the unedited report from the day's roundtable

Art Leadership Roundtable: Day 2

Thursday, March 2 at 3:30 pm

Room 120, North Hall
------------------------------

--------------------------------------------------------------------------------------------------
Total Headcount: 81

Roundtable Session Ranking within Visual Arts Track: your session is ranked 3 of 12

Roundtable Session Ranking within GDC 2017: your session ranked 33 of 421

Session Totals (This Session)
Response	Count	Percentage of Responses
Excellent	25	86%
Good	4	14%
Poor	0	0.00%
Terrible	0	0.00%

Comments

It was my first roundtable, and I am definitely going to take part in the one that is planned for tomorrow.
If I could I would take part in art related roundtables three times a day for the whole conference.
Do more art related roundtables.
Loved the roundtable, will definitely come back for all of these!
Lots of valuable information on these talks. Would be great if the elaboration time was cut in half for each question though, because it sometimes felt like we were going in loops and would have been nice to address more issues with the time we had.
Good second session, too bad a question was repeated from day 1 which I didn't find interesting at all.
Focus was less than on day 1, but all in all an ok session.
I was expecting more of an art related discussion in this roundtable, but it was all about management. Thats not to say it was bad, it was a good discussion about managing people and dealing with crunch, etc., but I think this should have been billed as a management and production talk. I know I'm not really the intended audience since Im a programmer, but I had hoped to get some insight into visual development. From my perspective, you could have had a room full of lead engineers and had the exact same discussion.
I couldn't get into the first day because it was full, and I missed the third installment, because I didnt get there by 10, but I really enjoyed this roundtable. I would love to see more of these.
This was one of my favorite things in the conference.
Invaluable! Not only because the moderator was excellent, but also for all the attendees experience which was both enlightening and practical. Again, super great.
Highlight of my GDC for talks. Loved the topics and sharing.
My favourite of the art leadership sessions.
Would have been good to have more time to meet or introduce people. Last year there was a quick introduction for each person in the room.
Keith Roundtable is my favorite talk almost every year. I make it a point to come every time. Id even suggest adding an Art Leadership Mixer for people who come every year as there are a lot of familiar faces, and we dont get to mingle much.