Leadership in the Games Industry
polycounter lvl 5
Hey everyone, I'm a 3d artist and student at the Guildhall at SMU in Plano, TX.
Throughout the program's curriculum, we make several games, each getting progressively more complex.
I was lucky enough to apply and earn the Lead Artist position for my team and we've been in production for ~8-9 weeks on a retro-futuristic CTF title.
Overall, the experience of being in a lead role has been very positive and could see myself loving it someday as a career.
However, team management and communication (especially cross-discipline) has proven to be its' own beast and is something I would like to improve on.
To any industry vets out there, management or not, have there been any nuggets of wisdom you've received over the years about the following:
-Task Prioritization
-Team Motivation and Buy-in
-Conflict resolution and indecisiveness
-Defining roles and responsibilities on small indie teams early on, to avoid later conflicts with confusion, departments feeling stepped on, etc.
Sorry this is such a long post, but team leadership and dynamics are important to me and something I hope to evolve in. Thanks!
Throughout the program's curriculum, we make several games, each getting progressively more complex.
I was lucky enough to apply and earn the Lead Artist position for my team and we've been in production for ~8-9 weeks on a retro-futuristic CTF title.
Overall, the experience of being in a lead role has been very positive and could see myself loving it someday as a career.
However, team management and communication (especially cross-discipline) has proven to be its' own beast and is something I would like to improve on.
To any industry vets out there, management or not, have there been any nuggets of wisdom you've received over the years about the following:
-Task Prioritization
-Team Motivation and Buy-in
-Conflict resolution and indecisiveness
-Defining roles and responsibilities on small indie teams early on, to avoid later conflicts with confusion, departments feeling stepped on, etc.
Sorry this is such a long post, but team leadership and dynamics are important to me and something I hope to evolve in. Thanks!
Replies
Overall goals should be prioritized by the stake holders. If the stake holders aren't involved in the decision process, then there's a great likelihood that they won't fully understand the work that your team is doing. This can cause future large workloads on your team, as well as undervaluing of your team's accomplishments. Report to stake holders on a regular basis on your departments progress - even if it's quick and concise. Very few people turn down a lead or manager that's reporting on their progress efficiently - it saves them from having to ask later.
For individual project task prioritization, this is going to be semi-dependent on your companies policies for how they manage their projects. Personally, I like to break down tasks that are able to be completed within a 40-hour work week. If a task is set to above 40 hours of work, then it's most likely too big of a task and can be broken down to further individual tasks. You want your team to have realistic goals and expectations, and breaking down tasks like this keeps momentum up and stagnation down.
While the book is targeted towards software development, overall I find it's a great read for entry level managers who have the job of task prioritization - and so I would recommend picking up the below book:
[ame="http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?ie=UTF8&qid=1399010089&sr=8-1&keywords=the+mythical+man+month"]The Mythical Man Month[/ame]
Team Motivation and Buy-In
I've always felt like that if someone isn't motivated to come into work and do their job so that they can continue to get a paycheck and put food in their mouth and their families, then they're not really worth saving.
That being said, often times work-related issues aren't the cause, or underlying issue, for most team demotivation - it's all the other distractions outside of work that end up sneaking in and messing up a team. As a manager, you're going to find that you not only manage people's work lives but you become a psychiatrist to their personal lives. Doing as much as you can to help team members with any issues that they have outside of work, will ultimately give you better results in the workplace.
Which brings up a good point, know your team members. Know their individual personalities. Some people want accolades and pats on the back throughout a project - give it to them in a way that will reassure their confidence in their work. Some don't like to be put on the spot like that, instead they would rather have a thank you or some other form of less-public reassurance. Some people like little things like management providing breakfast one week a quarter, while others could care less.
Get to know your team members on an intimate, professional level and you'll know what to do when the time comes for motivating them.
Conflict and Indecisiveness
Ways in which to resolve conflict is never an easy decision, if it was there wouldn't be conflict - But, as a lead/manager - you get paid to resolve situations like this. The best piece of advice that I can give is to listen to all sides of the conflict, and never play biased. You need to play the role of a mediator.
Is this a personal conflict between two or more employees or is this a work issue?
If it's the former, does this personal conflict break any company policies? Is this resolvable or is this a grey area? Bring both/all parties into a room together and just let them talk it out, with you mediating it - most of the time people come to reason or end up getting bored of their ownself arguing a point and talking.
Once the personal conflict has been resolved, is there anything that you can do in your position preemptively to make sure that it doesn't happen again.
For work issues, most everything will fall into a category of policies or orders being brought down the food chain. The best that you can do is continue to motivate your team by reassuring them, and properly discuss the policies/orders in a way that's going to make sense to them.
Most issues in the workplace can usually be burnt out before they turn into a full blown conflict by watching for things that are out of place and squashing these ideas prior to them coming to full fruition.
Roles and Responsibilities
Simple Chain of Command applies here. You don't want anyone stepping on your toes, just like no one wants you stepping on theirs. As a lead/manager, you have the advantage of funneling everything through you and being a meat-shield to your employees. On the reverse, it's your responsibility to have your employees understand that to continue to work in a cohesive environment, that certain things need to be approved by you prior to it being done.
If one of your employees, or another departments employees begin doing something that seems like it should be in your department, then this is a perfect time to utilize your managerial skills.
Often times if someone asks politely, there's no issue and people don't feel like they're being walked on. If X department begins working on a task or doing something that your department should be doing, then schedule cross-training. This allows you to make sure that if they other department does do something in your realm, that they do it correctly. It also allows the other department and your department to build a relationship - inter-department trust is important. Never lock down information in the workplace just because it "isn't someone elses job" - that's not the answer, and there's possibly good reason that said person/department seeking information, or a task that is your departments, otherwise - they would not be trying to do it.
Furthermore, in terms of your specific department. Defining roles and responsibilities is good, but don't nail them down to the point that your employees are doing the same things day after day. If you have some slow time on the schedule, or some extra resources - task team members with jobs that reflect their least confident areas in the workplace. If Employee A has had a lot of trouble performing Task B then task him with it when you both have the time. It's easy as a manager to task an employee with a job that he's already an expert at, but that doesn't further your departments expertise as a whole and there may come a point when that special employee is no longer with you.
Also, if you could elaborate on the specifics of "cross-training", that'd be very helpful! Specifically, I'm curious about the relationship between Level Designers and Artists. A very common cause of confusion with all of the teams in my class has been a lack of pipeline between the two disciplines.
Often times it boils down to cross-disciplined gray areas of when art affects gameplay, aspects of an environment like lighting, composition of clutter assets, etc.
Another factor I think plays into the departments bleeding into each other is the team size. Our teams are currently 6-8 people, and for our final Capstone game they will most likely be around 12-15 people. Any insight into division of roles for small teams would be great as well! Thanks again for the response!
Seems like your teams are really small so you answer why do you think that management and communication cross discipline has been challenging? Mainly i think this issue tends to be because people are not on the same page. Specially if you have leads running rampant making decisions to people that maybe are not involved in those aspects.
-Task Prioritization
Always have the big picture in mind, and a detailed schedule delivery helps keep this in check. Tasks will change as you move through the project, but make sure your decisions are not always reactive but planning ahead. Leaf buffer time for revisions and also for things going south.
-Team Motivation and Buy-in
This i guess depends on a lot of things. But just hard work man. Doing your best and showing your commitment to work and things coming together will motivate people. Leads have to set an example, and communicate. When people feel they are organized and working towards goals that make sense they tend to work harder. So be tranparent and make the project a place people want to be in.
-Conflict resolution and indecisiveness
Be careful here. Listen. Always listen and identify what the real problems are. Ask questions and try to get the facts before making a comment. Resolution comes from all parties involved reaching a common ground. So try to level everyone to the same place and explain priorities, goals and overall scope of what is needed.
-Defining roles and responsibilities on small indie teams early on, to avoid later conflicts with confusion, departments feeling stepped on, etc.
I think i explain this further down.
Also, if you could elaborate on the specifics of "cross-training", that'd be very helpful! Specifically, I'm curious about the relationship between Level Designers and Artists. A very common cause of confusion with all of the teams in my class has been a lack of pipeline between the two disciplines.
Often times it boils down to cross-disciplined gray areas of when art affects gameplay, aspects of an environment like lighting, composition of clutter assets, etc.
This is a communication area. What i have learned as lead is that ART enhances functionality, design and gameplay through consistent, substantial and aesthetics.Which involve lighting, composition, decisions on where to decorate with what. So you have to know, and everyone in the team what is going on. Know the goals of the project, the goals of the team, and individuals working on it. Everyone has different perspectives and knowing that can only help you steer the boat in the right direction. I don't think in a small team you can effectively remove disciplines. They will cross, and if you use it to your advantage you get better morale, motivation, hard work and a game that benefits from inter discipline decisions.
Here at 1p i try to make sure that people are involved, i never make a decision without asking for opinions, and having other people look at it form design and code and animation it can only help the overall quality and efficiency of the art created.
Always listen, think about what you want to say and most often than not try to explain and solve. I know it might sound a little obvious. But there are people that just say.. noup. can't do that and thats it. Its easier to say, hey, maybe we can't do this, but what exactly is it that we are trying to do, and then come with a solution that benefits everyone. Also, think of personalities and how you can be more effective when interacting with people.
Another factor I think plays into the departments bleeding into each other is the team size. Our teams are currently 6-8 people, and for our final Capstone game they will most likely be around 12-15 people. Any insight into division of roles for small teams would be great as well! Thanks again for the response!
Think of it as an advantage. Its easier to know people in a small group than a big one. Play to that strength. As mentioned before you really need to know your team members. Talk to them. know what their inclinations are, what their interest in the project is, what they would like to do or learn or push. This can only lead to new ideas, tech, hard work and lots of positive attitude towards the project. Never make a schedule and not run it through the artist that will actually do the work. You create that trust with people and things start to fall into place, and always have people be responsible for their tasks. Ownership will always take a big role, and make sure you don't stomp on that. Do lots of reviews, or just revisions on where the day is at, things that are needed or blocked and be a mediator.
HAVE CLEAR ROLES. at this point you can see that a lot of people put on different hats. You need to. But its very very important how clear those roles are between the team. Assign roles that make sense to the strengths of the artists and make sure other disciplines are aware of who does what. As well as know who does what on other discipline. This streamlines communication and helps with distractions.
The bottom line is that being lead is not just tasks, schedule and direction. Its more of mediating and communicating ideas from everyone on the team. Be transparent and always ask questions. Make sure people are on the same page and the scope and roles are clear.
I wrote some notes on an IGDA leadership i went to a few years ago. I looked for the thread here on polycount that had this but i could not find it haha. So here.
http://brau3d.blogspot.com/2011/11/igda-leadership-forum-session-notes.html
Just thoughts and some more insight on my interpretation on lead qualities and things to keep in mind.
Best of luck to you, and i hope my 2 cents clarify or help in your situation.
Let me elaborate on this pitfall (indie game studio, my second time as a lead):
My task was to get all the artists on a project to a similar level as fast as possible, building up a core team. The plan was to set a foundation from where it would be easier to add new members to the team if needed.
There was this guy who constantly delivered half assed stuff. He was new to the team and company, so at first I thought he just wasn't up to speed yet.
So I showed him what I wanted and how I wanted it in detail - although it should've been clear from the start since we had a very well defined art style. I showed him ways to improve, exactly how he could fix misktakes. I even went so far and had tutorial-like sessions with him. I constantly patted his back when he showed some progress. But the more I showed him, the sloppier his models and textures became. I kept sitting next to him, sometimes stating in meticulous detail how I want something done. Then it dawned on me: all he had learned was that he simply did not need to even bother to think for himself, solve his problems or make progress. I was doing that for him already. I basically did his work.
When I realised this (way too late for my liking), I took him aside and talked to him - trying to find out what the problem could be, whether he felt not motivated enough and whatnot. Turned out, he simply was lazy as fuck. Period. I had never encountered this type of "artist". But ultimately it was my fault for playing along.
These people exist, even in our industry. Try to spot them in your team early before they steal your time. Never do someone else's work.
some
The best are those that try so hard at doing as little work as possible, that in the long run they end up doing more work than if they would of just originally done the work they were assigned to begin with.
Luckily, my company has a motto "Hire Slow, Fire Fast". Problem employees are given the necessary means of showing that they're useful, productive, and professional - if not, they're let go.
Beginning in late May/Early June, I will be doing something similar with a newly formed Capstone team at the Guildhall at SMU, if I am selected as Art Lead again.
Is there a "checklist" or established method you've found helpful to initially build that art team? I've certainly gathered it's important to know your team, but was curious if there's a way that's proven successful for teams in the past. The more expicit the instructions, the better!
This could also segway into initial general practices for divvying and setting up priorities/task lists for a team.
Thanks again everyone!
The project I worked on was somehow special in the way that we did not have to come up with a ton of unique designs since it was based on a wide range of pre-existing plastic toys for kids.
We had a relatively small art (asset) team (6 including me). The game target audience were kids, so no high end stuff, no fancy shaders, no next gen. As an indy developer, we did not set out to be the best looking game on the market, but to be a solid middleground with coherent graphics that would not grow old too fast.
The design goal was to achieve a hand painted look without deviating from the existing toys in terms of forms and "feel". Of course, entirely new assets had to be made, but again we had to think about how they would look like if they where actual toys. It is kinda hard to desribe and I would like to show some pictures, but unfortunately I am still under NDA.
So take my words with a grain of salt regarding the portability of my experiences to other, bigger projects.
Pre-production
I was to define a tool pipeline for the project as well to organise our side of the CMS. We kept code and art as separate as possible due to specific restraints and necessities of the project (again, I wish I could be more precise...).
I had to come up with naming conventions and folder scructures for textures, meshes, exported data, scene management, scipts, animations, effects. I made a wiki with all the info needed from starting a model to finishing it in the engine (technical aspects especially). These wiki pages proved to be a vital part.
I have experienced absolute horror in previous, less documented projects when trying to find a certain object with all its recources. Especially when projects get bigger over time and/or new members join the team you are pretty much fucked big time without such a guide.
Together with the enivronment art lead, the next step was to make lists over lists of objects we thought we would need, somewhat sorted by importance. I estimated how long it would take (in full working days) to create any given object, assigned object names (largely automated) and transformed these lists and all the additional info into individual tickets (we used a customised trac version throughout the project). This helped a ton to keep track of every aspect of the art production.
Finding my team
So my first step to assemble the team was to create an art test. Instead of providing extensive concept art, I chose to write a short but detailed descriptive text of what the object was for and in what setting it would be found. I gave examples of existing games that used a similar art style we were trying to achieve. Then I gave relatively strict modeling guidelines (poly budget, texture size, alpha usage).
I wanted to see how a candidate can adopt to a certain art style within tight restrictions, to get him thinking, to test his/her creativity and eye for detail. I did not want the candidate simply recreate a 2D concept.
Defining the roles
I chose the candidates that where not excelling in one particular area of the whole test but the ones that showed a really solid understanding in techniques, both technically as well as artistically. I wasn't looking for the "rock star of character modeling" or the "texturing god". The reason was that I wanted to form a team with evenly distributed and solid skills to build upon. I figured it would be a bad idea to constantly slow down that one stellar guy and to push all the other team mates just to even out the field and get consistent output. This could have ended up in frustration for everyone involved.
Of course every team member had his/her strenghts and weaknesses. I had one that could nail geometry down fast and clean but lacked a bit on the artistic side of things when it came to painting textures. His job was to create all the bigger architectural assets as well as different modular systems.
The second one was the exact opposite. She got to create unique textures mostly as well as variations of existing textures.
Then there was my "joker", a guy that did both jobs very good but was a bit slower than the rest. Bored easily big huge objects, he was the one to churn through all smaller and/or important game objects (mainly hero assets for point of interests for the level design department) as well as giving finishing touches to some architectural stuff.
The other 2 where given scene filling items such as barrels, crates, signs, fences, what-have-you.
Production
I made sure that everyone knew at any time what he/she had to do. I tried to avoid the point where an artist would come to me asking what to do next.
I always assigned a bunch of tasks/tickets with similar priority to every member of the team. That way they had a little freedom. If they did not feel like making yet another chair that week, they could start on something else. They also where able to suspend tickets, taking a pause from one object (especially with large tasks spanning a week or two) and working on another ticket. That helped a lot to keep motivation high. The artist seldom found themselves doing repetitive and boring tasks and could sometimes start with a fresh eye on an object they left off previously.
To check my estimations of how long an object would need from start to finish, the ticket system required the artists to fill out a "time spent" field. Sure by far no optimal way as you could easily cheat, but within our small team it worked pretty well. Additionally to that, I monitored their progress daily, although not in an orwellian way.
I tried to stay away from calling meetings too often. Again, we were a small team and there simply was no need for meetings every day or week. I made sure everyone was informed well about the state of the production through a short, personal chat. Although this practice may occasionally cost a small bit more time, I was able to listen to the needs of the individual artist. Some of them would have never spoken up in a larger group meeting.
Another thing I made sure was that no other department interfered with my guys. If someone from outside my team wanted to have something built or changed, they had to turn to me first. I did this not to cultivate bureaucracy but to be able to plan, time and track new tasks. That too meant that I had to turn down requests occasionally (in consultation with the project manager) as they sometimes could not be realised within our time budget. Tough decisions, but you don't want to bite off more than you and your team can chew.
On a side note, another reason was to shield my guys from sometimes overly stupid requests ("Could you please make a green roof for that building, my cousin lives in a green house and he would love to see that in game!"). Although that may sound silly, it happens.
I also mostly tried to stay away from ""Wouldn't it be cool if..." discussions with my team and other departments. Although certainly not a bad thing per se, these things tend to lead into assloads of extra work. With a tight time budget, you simply can not afford to dream up stuff you can not handle in the end. Do what you planned and what is absolutely needed in the first place, then see if there is room for improvement. That being said, I sure kept a list of "things we'd like to add" in my notebook and worked some overtime myself if I felt it was worth it.
Well, thats it for now, I could go on in more detail but I did not want to type a whole page.
I hope it was somewhat informative.
some
In my tickets for the artists I included a link to one or more reference images (located in a special folder in our VCS) of the existing toys if possible, otherwise I'd quickly scribbled what I had in mind and let the artists run with it.
Additionally, I gathered some (preferably tileable) reference textures from previous projects or created new ones. This was to show the look and feel of different materials that I thought would be needed on a regular basis (wood, stone, metal, etc.). Although the artists used these as an orientation, I let them paint new textures from the ground up (and not use mine).
I also tried to streamline the way highlights and shadows where painted to some extend. We had to mimic the palette of the toys (client provided rbg swatches). By defining what layer styles to use (e.g. soft light, overlay, etc.), I made sure the hues of highlights and shadows of a given base color looked somewhat similar across all textures.
But that is a bit special and was due to the nature of the project and the picky client.
some
http://www.gamasutra.com/blogs/OliverFranzke/20140926/226504/So_they_made_you_a_lead_now_what.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GamasutraNews+%28Gamasutra+News%29