Communication is Key

Ever have one of those days, or one of those weeks in my case, where one hand obviously is not talking to the other? Not to sound like Andy Rooney, but I have. It's become so frustrating to the point that I am going to make a blog post about talking. That's right: talking.

Let's start by talking about bundles. There have been a lot of those lately, from The Humble Indie Bundle to IndieRoyale to the latest Indie Game Music Bundle. As was mentioned on the blog Dino Farm Games, these are great for the developers who actually get in, but not so great for those left out. To be fair, it's not like every indie game ever can be in a bundle. After a certain point, there would be too many games included in a bundle for the price to be economically viable per developer, or it would be too expensive for most people to pay in the first place ($100 for 100 games seems awesome, but how many of those are you actually going to have time play?). For the sake of argument, however, let's say a new bundle pops up, and you are an indie developer with a game you'd like to be included, so you send those who run the bundle an email with a link to your game on the day the bundle goes live. A week goes by, you hear nothing back. You send them another, still nothing. Finally, on the third email, you hear that they are not accepting any more games for the next bundle. Sounds like a pretty frustrating scenario, huh? Sadly, it is a real one, and a tough one to avoid if you are just starting out.

Keep crying, no one loves you.

For all this talk about how great social media is, the one thing we've stopped doing is talking to each other. Situations like this could be avoided if people just had the guts to speak up and send out rejection notices immediately instead of dragging people along for weeks on-end. Unfortunately, lack of communication can really eat into a developer's schedule, no matter how small the team may be, and this goes for both outside-in (in the case of bundles or publisher deals) and strictly internally. In fact, internal communication breakdowns are probably the easiest to occur but also the easiest to avoid. For instance, if you have two programmers on team - say one handles input and the other handles AI - and neither programmer is letting the other know what's going on, certain features may end up neglected at build-time, and neither programmer would be happy about that.

And then before you know it, you're out of a job.

The first instinct is to go to the Project Lead or the Producer with new features to go in, and on big teams this make sense. If a problem arises, you want your Producer to know so she can find a way to solve it. As Extra Credits pointed out, though, your Producer will probably pull you into another Programmer's office and say, "Hey, can you solve this problem?" You can save 10 minutes (at least) in your work day by going to that Programmer's office yourself and asking the same thing. Plus, you save your Producer the headache of having to help you do your job. As an employee anywhere, it is part of your job to make sure you know how to talk to everyone there, not just your boss. To be completely blunt, nobody likes it when you go over their heads to solve a problem with which they are involved. People much prefer you'd come to them personally, and I think Producers/Leads would prefer their staff talk to each other instead of having to fill in every tiny hole themselves. Save your company time and money and let your peers know you have a problem. Then you can tell your producer at the daily meeting that you solved a problem on your own. That'll make everyone feel good.

A happy Producer is like a warm summer's day: forgiving!

On a small team, going to the Project Lead to solve a problem instead of the team member whose responsibility it is to solve said problem is practically inexcusable. Something is bound to get lost in translation in the short game of telephone between the three team members, and since your team may not be working out of one central location, it's not exactly easy to drag someone into someone else's office. If you have everyone's contact info, contact your teammates directly. Project Leads on indie teams wear many, many hats and really don't have the time to call someone for you when you have their number.

That's a lot of hats for someone who's not selling hats.

Which brings me to my final point. If you are on a small team, have a phone you can always answer, and if for some reason you can't, always return your phone calls. There is nothing more frustrating than leaving an important message on someone's voicemail only to have them not get it or not return it. Blackberries are notoriously bad at not letting their users know they have a voicemail. Android, iOS, webOS, and even flip-phones do a better job. When you are working, keep your phone next to you, not in your pocket, so that if you get a call you can see the phone light up instead of wondering if it is vibrating (and if you are in an office environment, please do set it to vibrate for the sake of your co-workers). People (well, extroverts at least) much prefer face-to-face or even voice-to-voice communication over six-word (or worse, six-page) emails. Emails are okay, though, especially if what you need to tell the person on the other end is highly technical (fix this code on like 346 to read blahblahblah, for instance). Text messages are too impersonal, and they often cost the receiver money for information you could have called them about or put into an email.

You paid a lot of money for this shit. I don't care if the call quality sucks: USE IT!

Lots of things to keep in mind, I know, so here's the TL;DR version:
1. Groups who run bundles get flooded with a lot of emails from a lot of devs. If they happen to get to you and select your game to go into a bundle, consider yourself lucky.
2. Talk to your peers first, not your leads/producers, when you have a problem they could easily solve.
3. Answer your gorram phone.
4. Emails are good for highly technical problems.

All in all, just don't be afraid to talk to the people you work with. It's hardly even going an extra mile, it's going an step. That's as far as you can go before you go any further.