Art Management For Artists

What is a "lead artist"? How is a lead artist different from a production artist? Lead artists are less "artists who manage" than "managers who are in charge of artists". A lead artist is, first and foremost, a manager.

Despite your role as the keeper of the vision for the look of your project, you will likely spend the bulk of your time doing paperwork, email, meetings, and managing your artists. This was a shock for every lead artist that I talked to, and it was a shock to me. (This is, by the way, a fact of life for any lead, especially engineers, who are just as likely to think they can contribute a significant amount of code and still manage a team.) You will have to change the way you gauge your own success, because you will no longer be able to look at the amount of art you have done to see how you're doing personally.

What does your boss expect to see from you?

Your boss requires primarily two things: on-time delivery of art assets and clear communication.

We'll get into the specifics of how to manage time and people further on in the paper, but it's worth mentioning here that hitting deadlines is essential to your success as a lead. It is the single thing that all bosses love to see and are guaranteed to expect. No manager in his right mind will put you in a lead position twice if he knows you will consistently run over hard deadlines. Some slippage is expected, and something unexpected always comes up. Deadlines can even be moved without a major fight if you have a good argument for why it has to happen. But any company whose existence rides on hitting ship dates can't tolerate avoidable schedule overruns.

The second element that is essential at all levels of the art lead's responsibilities is clear communication. Many beginning leads are afraid to present problems to their bosses because they think that it will reflect badly on their ability to do their jobs. That's what managers are there for. Don't be afraid to tell people that you are new to a situation. They probably already knew that, so if you manage to fool them into thinking you're doing great, you are more likely causing trouble farther down the line.

Be aware, however, that communication means asking questions as much as giving information. Talk to your boss. Your responsibilities as Lead Artist may or may not include what you expect. Make sure that you are clear on what your direct superiors expect from you, and what aspects of the project and team management you can expect from them. I have run into very sticky situations that I thought were my responsibility that were not, and only found out afterwards.

Are you responsible for hiring and firing artists? Who is responsible for disciplining problem employees? How far does your responsibility extend before it becomes a matter for the art director? Are you in charge of the art budget? Will you be evaluating and buying your tools and equipment? Do you need to coordinate with the marketing team, or is that the responsibility of the producer? Ask.

What is your new yardstick for judging your success?

This question is the toughest one, since it depends most on your situation. How smoothly your schedule was run, how few complaints there were from engineering, how good the project looks compared to the competition, and how adaptable you were to bumps in production - these are typical and should be expected. And, of course, these are only a few criteria that your boss could use. Depending on the scope of your authority, other factors may be involved.

Keep in mind that your artists, not you, will likely be the ones creating the vast majority of the artwork. That complicates how you are able to meet artistic standards, and a fat portfolio of new work for you may mean that you have been neglecting your responsibilities, not fulfilling them.

Take a minute to think about this question; "How will I tell when I'm doing my job right?" This will be critical later in the project when things get hairy and you are off-balance. You will need to have some objective way to tell how you are performing. If you don't have a ready answer to this question, found out at your first opportunity.

Managing The Project

Chances are, you are good at managing yourself and your own time. That's one of the things managers look at when they decide who to promote to lead positions.

But, managing a small portion of a project and managing an entire project require different skills. You are no longer just concerned with getting your slice of the pie done. You are also responsible for making sure that others get their work done, and that both the people you work for and the people that you manage understand where the project stands at all times.

Scheduling

How do you start? The first element necessary for building a schedule is the design document. The design document is the blueprint for the entire project, and lays out what the final product will be.

Determine the assets required by the design - number of levels, characters, kinds of animations, shell screens, fonts, weapons - the meat of the project. Once you have an idea of all the pieces that need to be assembled, start looking at dependencies. Most decisions about what needs to be done first will be common sense, but certainly not all. If levels can be tested with old character models, then new models could be done early or late in the process. Objects for levels may not ever be critical issues in development, so they could be stuck in anywhere in the schedule. Shell screens could be polished at any point in the project. It is at this point that talking to the engineering lead is critical.

The art schedule and engineering schedule have the greatest chance of clashing and causing conflict. This is common sense, really. Engineering needs to use your art, and your art needs to be supported by their code. These facts lead inevitably to a number of "chicken and egg" scheduling puzzles.

One of my schedules on a previous game had levels being completed first and characters later. Engineering, as it turns out, needed the character models to write climbing code. If we hadn't caught that conflict, we wouldn't have been able to test any levels that required ascending a ladder for several months after the level was done.

Sit down with the lead engineer and try to find potential conflicts in your schedules. Some will be more obvious than others, so devote some time to this and ask a lot of questions. If you have trouble poring over schedules face to face, email them to each other and schedule a time to talk about them later. If you have concerns and priorities, bring them up. Are you worried about a usable interface? Are your character models doing something they've never done before? Is there an effect or several effects that you feel are necessary to sell damage models? If you have a good relationship with the lead engineer from the start, then he will more likely be able to accommodate your need for tools, testing and scheduling. In the same way, you can make his job much easier when you can accommodate his needs and concerns. Individual items may require some debate and compromise, so be informed about your own needs up front and be flexible.

By the way, it is never too late to work out these conflicts, it just becomes more painful the longer you wait.

What do you need to plan in to the schedule in case things go wrong?

You know from experience that something always goes wrong. No matter what your level of experience, you will hit roadblocks that you haven't encountered before, or some that you've dealt with before that you still have no solution for. Resist the temptation to schedule so tightly that any problem will throw you off.

When talking to engineers, they will tell me with a straight face that they schedule everything to take three times as long as it will really take. How often do engineers find themselves running behind schedule? At least as often as artists do. That should give you pause. If they schedule that way and still slip, what chance do artists have of doing better, with artistic temperaments and less well-defined problems?

The reality for most companies is that teams can't schedule that loosely, so have good, solid reasons for what you do pad out. Where is the team least experienced? Where are you most likely to need to re-do art assets? Where is the project breaking new ground in technology or playing style? Look for areas that have the most overlap with other parts of the production team, and there are you potential liabilities.

No one can plan for every contingency. Three things will give you the best possible defense against slippage in your schedule:

Managing The Team

At the same time that you will be working out the technical issues of the schedule, you will be spending at least as much time and probably more on people issues. Be aware that the art lead will be managing up, down and across - not only people under him, but the managers above him and the leads on his level.

How will you keep up with the artists? (You could also pose this question as, "How will you know if you are on schedule?") The answer is complicated by the fact that you will spend some time working on your own art tasks, and a lot of time in meetings outside the team room. The problem gets worse the more people you have on the team, and the more inexperienced people you have working under you.

At Red Storm we have tried a number of ways of getting information on individual and team progress. One was to ask everyone on the team to email his or her leads with a daily report. Everyone hated that, so answers ranged from helpful to downright insulting. I had at least one artist who just sent me the same note every day by hitting the re-send button in his email. We had some very good engineers who flatly refused write anything at all. It could have worked, but it didn't. From there, we went to weekly emails, which were better received, but people had trouble remembering what they had done earlier in the week. We have also tried setting up an internal web page where team members could check in with updates. Lately, we've developed time sheets with task areas already typed on them, and empty blanks for hours spent. None of these methods were complete failures or complete successes, and they emphasize the need to have one-on-one contact with your team.

A balance of direct and indirect contact is important, not only in getting the data you need, but also in understanding what people are saying. The methods you choose for knowing if you are on schedule and on track should be developed early and tinkered with over the life of the project. In the same way, you should count on trying different approaches to maintaining contact with your artists. Some will naturally require more attention than others, and that time will shrink as you get later into the project. But cycles of turbulence are natural, so let's take a brief look at team dynamics.

Team Dynamics

All teams go through a predictable cycle of chaos and order that can be summed up in four stages: Forming, Storming, Norming and Performing.

"Forming" is the stage where the team is first put together. Everyone is very polite and excited, but tentative. People are still floating, unsure of their role on the team.

The next stage is "Storming". At this point, problems have started to surface, and people start to drive each other crazy. Everyone knows they are in over their heads, and they can't get out. There is too much agreement in meetings, while inside everyone is smoldering with resentment. Fixing problems almost always involves stepping on toes.

Everyone wants to avoid this phase, but it is unavoidable. Storming is where the rubber hits the road, and all your best-laid plans start to show their weaknesses. Reality begins to exert itself. Teams and entire companies can get stuck in this phase, because solving root-level disagreements is painful. People often deny that those problems are there, or end up leaving in frustration if they feel that issues important to them are not being addressed.

The lead needs to help the team through this phase. If the lead is part of the problem, then a neutral party needs to be brought in. The Neutral party doesn't need to be a professional, just neutral. This is the "Norming" stage. General solutions or technical fixes are unlikely to solve the real problems, because they are caused by conflicts between personalities and agendas. Solutions require that people to talk to people.

The Norming stage requires honesty, patience, and the ability to apologize. Feelings will get hurt - yours as well, because, as a lead, you will be the focus of much of the conflict. At this time, it may become clear that some people are in the wrong position, or doing the wrong job. At Red Storm, fortunately, we are too small a company for these conflicts to be solved by firing people, except where a situation has been proved to be hopeless. Actually working out problems is much more difficult than downsizing, but it is well worth the sweat and tears. After one or two rounds of Norming, you will feel like you can face anything. You will also have a better understanding of your own abilities and the abilities of your team.

If a team successfully passes the Norming stage, they will move on to "Performing". This is the stage that you hear the most about from successful teams. "I dunno, we just jelled!" "We had an awesome team, and it felt like we could read each others' minds!" Teams like that get write-ups in business magazines. Don't be fooled. They didn't skip the Storming stage, they just don't talk about it.

The more experienced you are, the shorter the round trip is through the four stages, but you will go the whole circuit. A few things need to be pointed out about this model:

Take a minute now and think about your current project. What is happening now? Jot down a few notes, and compare them to the development cycle. What stage are you in? What are the next steps you need to take with your team?

Pitfalls for New Leads

New leads take a while to settle into their position, and, based on their temperaments, there are certain patterns that they can fall into in dealing with their new responsibilities. Lead artists are less artists who manage than managers who are in charge of artists.

The manager is simply that - an administrator. His time is spent with graphs and charts, on the phone, in meetings and in frequent conferences with individual artists. The art load, if there is one, is very light, and likely to be off the critical path. The art lead needs to have good data on whether the project is on track, and where the problems are if it isn't. The manager thinks of himself as the one who keeps the wheels greased, management informed, and his team happy and well-supplied.

If you stay in your job long, this is the type of lead you will be. I have exaggerated a little from my own experience and that of some of my co-workers, but only slightly. Keeping up with data and keeping in touch with your managers, your team, and your outside dependencies makes up the majority of your responsibilities as a lead artist. Developing those skills will be the story of your career.

If you don't enjoy at least some of that, you're in the wrong job. And it's not impossible to maintain a creative life, as long as you are realistic about what is expected of you, and you plan ahead. But there are pitfalls that you need to be aware of in developing that position. Here are a few that I have seen, and that friends of mine and I have fallen into.

The Other Leads

One of the purposes of the lead artist is to shield his or her artists from the other leads so that they are not interrupted in their work. That means that you will need to have a good relationship with all the other leads on the team, particularly the lead Engineer and the designer. You are the gatekeeper for the artists, and they should expect not to be pulled in different directions by your manager, the producer, or engineers.

Engineering

We've already talked a little about how important it is to be in synch with the Engineering lead. Art and Engineering are likely to have the most friction on a team. When dealing with engineers, remember that they need a different kind of information from you than other artists do. Find out first in any negotiation what the engineer needs to know, then work from that point.

My favorite story about this kind of thinking was from a talk by Dave Perry of Shiny. He asked an engineer if characters could ride motorcycles in the game they were developing.
"No", said the engineer.
"Could we have moving polygons?" he asked.
"Yes."
"Could they slide along the ground?
"Yes."
"Could an object be attached to that polygon?"
"Yes, …"
"Could a character be placed on top of the object on the polygon?"
Sigh "Yes."

A good Engineering Lead will act as a translator between you and his programmers. In turn, respect his boundaries and get permission to work directly.

Design

Designers are some of the most overworked people on a team at Red Storm. This fact and the fact that most design work is paperwork means that designers can become isolated from the team. Even the best designers can't predict all of the kinks in his vision. That means they will need to adapt as conflicts arise. Since adapting means re-design, the Art Lead needs to try to predict, to some degree, where changes are likely to be made.

At the beginning of the project, there are some things you can do to minimize future problems. Sit down with the designer and feel out how open he is to informed criticism. There will be areas where your particular expertise can help avoid problems or unnecessary waste down the line. After all, you as Art lead will probably know what is possible to build and what is the most efficient way for your artists to work. If you are not pushy or overbearing, you may find that the Designer is very open to good ideas. You won't know what parts of the design are most flexible until you ask. Be ready, too, to adjust your plans when the design cannot be modified in your favor.

Quality Assuarance

One part of the team we haven't mentioned to this point is Quality Assurance. Testing tends to be an afterthought at many companies, and Red Storm has certainly had the same problem. We quickly discovered that not including QA in planning and schedule discussions always led to headaches down the road. Why? Because testers have to verify everything that any other part of the team does.

QA develops a test plan that lays out how and when major features of the game are declared to be finished and functional. They must therefore know when to expect them and what they will have to work with. To release a bug-free product on time, they have an established system for rubber-stamping what the artists and engineers have done, so missing verification can mean major interruptions in the pipeline. Worse, it can mean that elements of the game are never tested until there is no hope of fixing them.

If anyone has faced the nightmare of finishing a game, only to find that it isn't fun, then you know why QA is important. Make QA's job easy, or they can make yours very difficult. You have been warned.

Wrap Up

Every company and every team is different, so it's unlikely that the answers you get to the questions I've asked will apply to every lead. Similarly, no amount of thinking on your own can replace experience, and no one has more experience with the problems you will face than other art leads. Use them.

Another excellent resource for pinpointing problems and finding possible workarounds is post-mortems from other teams. If your company doesn't do them, organize them yourself. If done right, they are a gold mine of information on process. Everyone on the team, not just the artists or your supervisor will review your performance. Odds are, people will say things they wouldn't have during the project, because they were afraid of getting fired or rocking the boat.

If you have ever read more than two post mortems, you will probably have a feeling of deja vu. Most projects have a set of problems that are almost identical - incomplete or constantly changing design, poor communication between art and engineering, missed deadlines, loss of staff, and short schedules are on almost every list. These can mostly be dealt with by proper planning, and are within your control.

What makes postmortems from other teams so useful is that they have specific problems, and solutions for them, that you might not have foreseen.

A good source for postmortems from other companies is Game Developer magazine. I'm sure you've seen free subscription forms all around the conference. Get it. It costs you nothing, and you won't be sorry.

I also recommend two articles by Dianne Davies about the particulars of being an art lead. They are still on Gamasutra.

My last suggestion is talk to the people who do it right. If you see a project like yours that looks like it was done well, call the lead artist and chat. If you seeanything done well, if you see any product that shows real excellence, find out how it was done. Call the lead artist. Call the art director. Call anyone who will talk to you. As long as you are polite, people are very receptive. If you call someone who's not, what have you lost?

Other people have done this job before. Find out what they have to say.

______________________________________________________