This is part 2 of a 3-part series on motivating an indie team. For part 1, click here! 

This is one of the Dev Logs for the indie game "Elsinore." To follow our progress, check us out on Twitter or visit our website.

Last week, I wrote a little about the basics of team management. This week, I'll delve into some more detailed team management tips!

Make Sure You Contribute

Anyone who's been working in games for any length of time knows the "Idea Person." the Idea Person doesn't actually have any meaningful skills and can't produce game content in any realistic capacity. If you're this person, stop. Pick a technical skill -- whether that's writing code, making pixel art, composing music, writing design docs, or marketing indie games -- and go do that for a few hundred hours. Then come back and try running a team.

One of the hard facts about team-based creative endeavors is that teammates will want to work with you a lot more if you're capable of doing stuff. The best way to do this is to come into the project with something prepared; if you're an artist, create some concept art. If you're a writer or designer, create a "one sheet" of the high-level game experience in bullet point format. If you're a marketing guru, develop a plan on how to pitch your eventual game and bring some names to the table of industry folks who might be interested in having a look.

A good team manager needs to get on the same level as everyone else and put in some serious elbow grease. Don't be the one barking orders at your teammates -- be the one committing code to the repository at 3 A.M., after everyone else has gone to bed. That's how you earn respect, and that's the easiest way to keep people invested and excited about your project. If they see you're excited and making meaningful progress on it, then they will be, too.

Test Your Weight, Then Delegate

At some point, if the project's large enough, it'll make sense to give your teammates agency over their various disciplines. With Elsinore, we had a rough time of it at first; I felt a lot of pressure to oversee everything, terrified that the game would die if I didn't micromanage each discipline's task list. I didn't realize it at the time, but I was crushing my teammates' willpower in the process. This is the worst possible thing to do, and in the long run, it will completely suck the life out of your team.

Delegation is hard, but it's so important. For me, being a designer by trade, it was hardest to do this with design; I gave our two designers, Connor and Val, a number of open-ended design problems to solve, leaning on them to get the job done. I cut all involvement with those tasks. In just one week, they produced some fantastic solutions -- far better than I could have done by myself. These days, they handle 100% of the mechanical game design decisions, and I stick to writing, which I'm most passionate about. I may step in to offer my opinions on design issues along with the rest of the team, but ultimately, they have the final say on things. It frees me up to handle other issues that sorely need my attention -- social outreach, Kickstarter planning, and the massive amount of game writing our project requires.

And in many ways, it's made the game better; their vision is not my original creative vision for the game, but it's a far superior one, in my opinion. As a team lead, your intent should be to allow your teammates to feel they have creative control over their area, within reason. Which leads into the next point...

Be Decisive, But Learn to Accept Better Ideas

Your teammates are frequently going to have ideas which aren't in line with the exact feature set you envisioned for the project. Sometimes, they'll be wildly different. Turn a critical eye on your assumptions about the project, and freely acknowledge when someone else's suggestion is ultimately a better one.

Learn to see these new ideas as a benefit, rather than a threat to your "creative genius": If your teammates aren't frequently coming up with ideas that are better than yours, either you're not listening to them, you're being overly defensive of your ideas, or it's time to find new teammates. A team where no one challenges anyone else's ideas is not a healthy one.

Getting Stuck

If a teammate appears to be stalling out on a particularly difficult task, step in and ask how you can help. Don't be accusatory -- everyone on the team will get jammed now and then, and it's totally normal. Maybe it's a sudden curse of writer's block, a coding task your programmer just can't get excited about, or an unclear task your designer doesn't know how to start on.

9 times out of 10, I find that people get stuck on a task for one of three reasons: they really don't want to do it, they feel overwhelmed, or they really don't understand the task.

If the former is the case, try breaking up the task into a few tinier chunks. Ask the person to work with you on a plan to get through the task. Can parts of the task be given to a different teammate who might enjoy the task more? (IE, if you have two programmers, would the other programmer like this task?) If not, can your teammate try to tackle one very tiny chunk of the disliked task, then alternate with a more enjoyable task? Keep putting tiny bits of the task on their plate until they've managed to get through it. I've found this method extremely effective -- even when trying to motivate myself.

If it's a case of people not understanding the task, try to clarify the explicit steps of the task or discuss further. Listen to what your teammate has to say. Is the task feasible? If they don't feel it is, why not? If they do, then where else is their confusion coming from -- can you help elaborate? It's extremely likely that this kind of issue will resolve itself just by talking about the task in detail.

On Elsinore, we dealt with this recently in relation to our art pipeline; I asked for a very large task from our artist without realizing how massive it truly was. He felt paralyzed by the sheer size of it and wasn't sure how to tell me; the task kept getting delayed. Once we talked it over, we quickly decided to pull in our technical designer -- also a talented artist -- to help break that art task into much smaller, more manageable pieces, splitting the workload between the two of them. Everyone's happier for that change, and progress is back on track.

Don't Forget, Everyone's Human

If you've been working on the project for a while, people will sometimes need a break or get burned out. That's OK, too. If you usually meet up in real life to work, go out for pizza instead of your weekly meeting, or hit up a local happy hour. If someone's going through a rough personal time, give them some space from the project for a couple of weeks, and check back in a couple weeks later. Treat your team like you would treat your friends.

Sometimes, even highly committed people may get tired of the project altogether. Again, this is normal; don't assume it reflects poorly on you or on the game as a whole. If that happens, take a moment to seriously reflect on the state of the project after saying your goodbyes. Ask the leaving member if there's anything you can do to improve in the future. How close is the project to being completed? Did the scope expand larger than you intended it to?

Sometimes, members who leave will have an important perspective on your project. Even if it hurts to hear that criticism, it will make your team stronger in the end.

Stay tuned for part 3 of the series, coming sometime next week!