This week's article is the final installment in a 3-part series. In this last section, I'll address some more nuanced tips not covered in #1 or #2.
Compliment Freely, And Often
Whenever your teammates send you any notable work, have a look and tell them what you like about it before anything else. Be specific and genuine -- as genuine as you can. (People can see through fake compliments in a heart beat.) This should be a golden rule for life in general, honestly. Compliments are magical; they keep people happy, spread positivity, and help everyone feel like the game you're working on is a quality one. Compliments also predispose teammates to accept criticism with a good attitude, should they ever be faced with less-than-glowing feedback. People are worst with feedback when they're at their most defensive, and are at their most creative when they feel liked and appreciated. Continue to tell them their work is awesome and, in some weird kind of confidence spiral, they'll start to produce stuff that is even more awesome.
Even beyond compliments, try to be encouraging in your language. "Good point." "You're right." "Well said." "I didn't think of that." These are important phrases for any producer's vocabulary, but they're especially important on an indie project, where the work is much closer to peoples' hearts.
Communicate A Lot, Through Multiple Channels
I've seen lots of teams fall into a rut of bad communication. It usually rears its head in one of two ways: either the team lead disappears, or the project mates do. If you're the team lead, your job is to check in with your entire team at least once a week -- ideally more, and ideally at weekly meetings. (See Part 1 for tips on running those.) Keep a running e-mail thread if you're worried about spam. Encourage people to frequently check in whenever they finish a task or have any questions they want to raise.
If you're finding that your group doesn't respond to any kind of group e-mails, contact folks one on one through their format of choice and try to spur them to respond within the context of a group; communication which is splintered through individual channels can lead to lots of confusion really quickly, and it prevents the rest of the team from staying on the same page.
If your project mates are the ones pulling a vanishing act on you, reach out individually and check in on them. Hopefully, you followed Rule #1 from Part 1 of this series and picked dependable teammates who will respond to text communication. If they don't, cut 'em loose. The kind of person who can't be bothered to respond to a "hey, haven't heard from you in a few weeks, what's up?" email within a couple of days is not the kind of person you want on your team.
And lastly: if you decide to make a sudden creative change, for the love of all that is good, inform your teammates as soon as possible and get them in on the changes. I've made this mistake myself as a team lead on college projects, and I paid a hefty price for it: teammates left, feeling divorced from the overall creative vision. I have also had the misfortune to be a part of indie teams where the lead(s) woke up one morning, had a sudden creative epiphany about the project, and began moving in a new direction without talking it through with the team first. In all cases, people quit or checked out. This isn't uncommon in the mainstream industry, either. If you've never been on a team where this has happened to you, it feels like waking up to find a loved one has been replaced by a total stranger.
Don't do that to your teammates unless it's necessary, and if it really is, make them a part of any major creative decision which concerns them. Instead of "Hey, folks, we're going to do X," phrase it as "Hey, folks, I was thinking about doing X last night. Can we get on a quick Skype call to discuss? Want to hear your thoughts."
In my experience, when my teammates have been reasonably dependable on a project, there has never been such a thing as "too much communication." On Elsinore we've had everything from a constant Skype group chat to an email d-list to thrice-weekly Google Hangout groups. The frequent back-and-forth helps keep people invested in the project, and ensures all of us know what other project members are doing. When people understand the project, have a sense of others' progress and feel connected to each other, everything else tends to drop into place.
Solve Disagreements Firmly, But Politely
You've come to a crossroads where two teammates are disagreeing. Bob strongly feels that the rhino NPCs need to have three horns, and Jane strongly feels they need to have six. Neither of them are backing down. What do you do?
Most people's natural instinct is to be overly diplomatic. "Jane and Bob, I think you both make some great points. What does everyone else think?" Everyone else raises points for and against the rhino NPC horn counts. They, too, sense your nervousness about having to 'pick a side,' and couch their language in "maybes" and "coulds." Everyone politely agrees that everyone else's ideas have merit. Silence falls. No choice is made, or if it is, it's such a weak decision that both Jane and Bob are confused on whose idea won. The team goes in circles.
Every team needs a creative dictator sometimes. If you've delegated people to be leads of certain disciplines, the best team lead move is to let them decide. Make sure everyone communally understands that, in the same way they deserve the final call for their own discipline, others do, too. "Jane's the lead artist, and this is a purely cosmetic decision, so Jane has the final call here." If you haven't delegated, you're going to need to make a polite but firm call on the situation as the team lead. "As Kevin noted, Three Horns is the title of our game, and everything in the game comes in threes. A rhino NPC with six horns could look really cool, but ultimately it's more important for us to stick with our theme, so we really do need to go with three-horned rhinos."
Even if you're rejecting someone's ideas, make sure they feel heard. Re-phrase their idea back to them to make sure you understand. If the idea is good but not appropriate right now, let them know that their idea is not forgotten and will be raised in a future discussion. Then remember to actually raise it.
Outright shooting someone down -- "No way, that's dumb" or "Ugh, I hate that" -- is the quickest way to make them resent you. They'll feel frustrated and hurt. People who do this frequently classify themselves as "direct." Other people call them "a total jerk." Always be respectful. Polite but firm is the way to go.
Have Some Optimism
Your indie game is like your first baby: you think it's adorable, special, and unique. Everyone else sees it as mildly interesting, capable of wonderful things, but currently little more than a sentient potato. They will not foster any special love for your game because it is not theirs. When you talk about it with friends or colleagues who aren't part of the team, you're likely to get blank stares at worst -- and at best, a very mild "oh, that's neat." Not all of us are Top Name Indie Devs destined for overnight fame, capable of making entire audiences pee themselves at the sight of a nondescript piece of concept art. And that's OK! Try not to get discouraged from the overwhelming apathy you'll face, in general.
Because of this drain, when it comes to team management, you're going to need to stay seriously optimistic. There's a difference between "optimistic" and "delusional" -- which hopefully, constant solicitation of feedback from your team can help you navigate -- but at the same time, there are going to be times when you're going to need to play head cheerleader for the team. Even when it doesn't look good and everyone's grumpy and you're on Day 3 of your weekend jam and everyone's exhausted from their day jobs. Cheer on. I honestly can't count the number of times I've persuaded the Elsinore team to forge ahead on something we weren't sure would work out, pretty much through optimism alone. Thankfully, everyone on the team is absolutely brilliant at what they do (see point #1 from section #1 of this series) so it's almost always worked out for the best.
Playtest Way Before You're Ready, It's Magic
This October, Eric (lead programmer) and I took our pre-alpha Elsinore prototype to GeekGirlCon. We're both in Seattle, so it was free to show up and demo. We were placed on the lowest floor, along with the board game crowd, and were terrified: our build was broken in several obvious ways, the art wasn't even out of its alpha stage yet, and the gameplay was anything but polished. We'd had a team Skype call right before the con, and one of our designers made a comment that "we don't need to really bother with an 'end' for the prototype -- no one will see it anyways. They'll barely play for a minute."
People loved Elsinore. It was ridiculous. We had an average playtime of over ten minutes. The highlight of the show, for me, was watching a ten-year-old girl play the game for almost an hour without looking away. Was she processing all of the intricate Shakespeare-based political intrigue and social economics going on in our gameplay? Nah. But who cares? It was an ego boost we all sorely needed.
Sometimes, when you're all too close to your game, it's easy to feel bad about it. After a while, you can only see the holes and ugly flaws. It's important to let others play once in a while so everyone on the team can remember why you started making this thing in the first place.
Overall, never forget: Your game is awesome. Believe in its power to give players that same sense of wonder which other game developers once gave to you. Keep moving forward. The horizon is distant, the path is blurry, and there are some really sketchy-looking skeletons on the wayside, but I promise, you'll get there.