I’m an artist. It’s what I was trained to do, and it’s how I’ve seen myself ever since I got into the game development biz. There is irony in this statement, because for the past year or two, I have steadily been doing less and less art and more people-herding.
This is something that I’ve always anticipated ever since we decided to hire people to supplement the gaps in our own skillsets. The team I manage is not huge by anyone’s standards: one developer, one artist, and anywhere from one to four interns. However, it does feel funny every time I swoop down from my inner sanctum to lay down the law in the form of feedback and marching orders.
It just feels funny to have turned into The Man.
This is a thing all leaders will have to accept eventually though, and I have so far been blessed to be working with people whose goals and ideals very much align with my own. I’m currently in a place where I finally feel like I am able to keep the entire operation intact and productive, and I’m here to reflect on the things I’ve learned in the past two years.
Don’t train to mold people in your image
Being the lead artist in a team doesn’t mean that you have to mold everyone you’re responsible for into the second coming of you. Wanting to make someone “just like you” is a path that leads to frustration, micromanagement, and many sleepless nights of self-doubt. I know — I’ve done my fair share of “molding” over the past couple of years.
People are not filing cabinets full of stats that can be tweaked and min-maxed, RPG-like, to eventually match your own. Their learning aptitudes for different skills differ, and so do their interests and motivations. Where at first I was showing them exactly what they had to do (so they could do it “my way”), I instead learned to let them figure things out by themselves, stepping in only when necessary to nudge them in the right direction. You will both discover where their strengths lie, and your team will be better for it.
You may roll your eyes and say “duh”, but you will feel the urge to barge in to show newbies “exactly how it’s done”. Resist. Show them the basics, and then let them explore and grow into their role.
Trusting others is easier said than done
Everyone who’s a “team player” will say they are willing to trust their team, but if you’re used to doing things yourself, you may find it difficult to let others truly earn that trust.
Two years ago, I was willing to stay up late fixing others’ work to keep it at the standard that I wanted. Enumerating things for someone else to fix is such a chore, right? It would be so much easier to get in there and fix the thing yourself.
Well, yes. That’s right. It also means that whoever it is who’s making the mistake will never figure out what they’re doing wrong. Take the time to tell them what they’re doing wrong, and chances are, they’ll never do it again.
Consider the alternative: forever losing two hours of sleep every other day because you’re always cleaning up after everyone else.
Go for the jugular
One of my design professors in college liked to hold regular sessions of what he called wildmind writing: a sustained period where the class was instructed to write whatever flowed from their brains into their pens. We were instructed to keep our writing hands moving and not to edit our thoughts. He also enjoyed writing an additional instruction for us on the board whenever we did this: “go for the jugular”.
Go for the direct kill. Make sure it’s dead. In other words, there are no other words.
I’ve learned to consciously hold this phrase in my head whenever a team member (peer or subordinate alike) approaches me to pitch an idea. I don’t turn down ideas often, but when I do, I remember to go for the jugular — don’t make the other party think that you’re considering it if you’re not. You don’t need to be an asshole about it, too. A simple, “No. Let’s test the design as it’s written in the document,” will suffice.
Again, I don’t do this often, but some situations will require you to. In my case, it’s usually when you’re rushing to put together a prototype to try an untested gameplay concept.
It’s not always about what I want
Going for the jugular applies to my own ideas, too. We’re all here working in the game industry because we love games and we want to make our own games. I’m in a position where I can dictate what my team does. The worst thing I can do at this point is to make the team create my dream game.
Our lead developer Vonn talked about scope in a previous post, and it’s a hard lesson that we learned over the last couple of years. Today, nothing sets off alarm bells in my head like a development team collectively listing down feature after feature on a whiteboard, their eyes flashing with excitement and their figurative fists clenched in determination. I know — I was that guy once, and those features were coming from my excited little brain.
Allow me to use a tired idiom here when I state that we bit off more than we could chew during the production of Super Daivolter Z. My memories of that game’s production are a collection of two things repeating over and over: an enthusiastic team brainstorming ideas and writing them down, and the same team, broken, suffering in silence as they dragged a corpse that was getting heavier by the day up a slope that was only getting steeper and steeper.
I wanted Daivolter to have all sorts of crazy features, and we became mired in development hell as a result of all the feature creep. Never again.
Be The Man, but hold on to your skills
Being The Man. Someone’s gotta do it, right?
In 2014, Rock Paper Shotgun published an article on the game developer Firaxis Games that I particularly like, and a statement within especially resonated with me:
As with several other designers at Firaxis, both [Jake] Solomon and [Sid] Meier are engineers as well as one-person thinktanks. The ability to translate ideas into code without calling in technical support or gathering a team is important. “Being an engineer means you can fail quickly and privately,” says Solomon, to a nod of approval from Meier who tells us he has a computer packed with prototypes that he sifts through every now and again.
Failing quickly is an idea that the new breed of entrepreneurs like to champion and put on a pedestal, but many times, the means to fail quickly gets killed by the existing process and the busywork. It’s a huge advantage to have a big-picture perspective and still be able to get your hands dirty if something needs testing or validation right away.
I’m not a programmer, but I am a front-end web developer — a skill that I’ve found very useful many times in the past, but never in game development. I’m currently looking into a way to rectify that, as my front-end coding skills could come in handy when we need to quickly test user interfaces, feedback, and animation.
Look into yourself and think about how your own non-managerial skills can contribute to making your ideas a reality. Anyone can be the idea guy, but it takes real effort to bring that idea home into something tangible and engaging.
tl;dr for the jaded and overly busy
Your team is composed of human beings. Respect them. Let them learn. Let them fail, and let them learn from those failures. Don’t get too full of yourself, and remember to hold on to what got you to where you are in the first place.
If your people still fail to improve after all that, maybe they don’t have a place in your team after all. If you still keep failing after all that, well. Perhaps it’s time to take a good hard look at how you’ve handled the whole transitioning-into-a-leader thing.