Managing a team

Hello every one, I'm glad to be back after the holiday. I also apologize for the delay in making a new post. It's been pretty hectic here and I also have a special topic today that I wanted to prepare for.

Before the holiday a fan suggested that I make a post about how to effectively manage a team. He – and many other people I'm sure – have issues keeping a team together and moving forward. I too struggle with this and only recently have been doing better at keeping a team together and on track. So today I will cover a few practices I have discovered or read about to help you manage your team better.

Communication:

The biggest and probably most obvious aspect of effectively managing a team is communication. This is even more important if your team is scattered across the globe. Communication is key to everything from giving feedback, setting up due dates, explaining your project and the more.

For me I like to have a set day every week where the team all gets together and discusses the project. We talk about what we did for the past week, what needs to be done for the next week and also discuss any concerns, questions or ideas we had during the week that we just didn't get around to fully discussing in smaller chat sessions or meetings.

I try to keep my team in contact by e-mail and skype. I personally prefer skype so that I can have a more casual conversation with my team mates and I can also respond quickly. With an e-mail you don't know when the person will even check it so the turn around for the conversation could be much longer.

Be prepared:

Communication also leads into being ahead of your team. Hopefully you've done everything the blog has discussed up until now and you have much of the game planned out and most of the assets or programming done. This will help you a ton as your team should never have to wait on you. Before I gathered my team I created 80+ models and textured them all. I then made menus and GUI for all the screens and menus I have planned. Now that I have a team they don't have to wait on me, instead if they need a menu I have one ready to go. Now I'm not saying there won't be rework. As team members come on they will have a voice and want to change some things and that isn't bad. Every one on the team wants to make the game as strong as possible and so some tweaks may need to be done. But at least you have something to work with and a jumping off point.

You also should have a playable game by the time you look for a team. If you don't then you should hold up and make something playable. Even if you aren't a programmer you should have a physical prototype that you can play and win. This early version should also have been tested over and over again to knock out as much bugs as possible. (If you haven't made a prototype check out my earlier post here)

That way when you gather a team and they ask you about some interaction or “what would happen if I do this” you'll have an answer and, if need be, an explanation for that answer.

The goal here and with communication is to limit the amount of time your team has to wait on you. The less time your team waits on you the more confident they will be with you and the faster they can work thus actually producing something.

Due dates:

You and your team should set realistic due date goals for your tasks and mile stones. Talk with your team and figure out about how long something will take to be done and ensure the whole team knows about that due date. Keep in mind that shit happens and not all due dates can be kept. This shouldn't be a regular thing hopefully, but it does happen.

I enjoy due dates because then the team can see that in X amount of time this much of the game will be done. It also motivates people to actually make time and work on the project.

If I'm looking for a team member and they don't want to work with dead lines then I don't work with them. That’s my personal stance on the matter, but I want a product I can play and show to people which means work needs to be done. I'm also trying to make a business, not just enjoying a hobby. I aim to make revenue from my games and I can't do that unless I have a finished game on the market. I also don't want to have one team member waiting on another and holding up the whole project which harms motivation.

If you don't like dead lines that's fine and I know many people who don’t like em'. But I work with them and I ensure my team does too.

Motivation:

Make sure your game is small. I can't stress this enough! For your first game or first couple of games keep it small. I mean really small! Ideally you should have something playable and testable within one or two weeks. If you don't then your game might be a bit too big.

Having a small game, and thus a product you can actually play, test and show to people, is huge! This You and your team will easily see progress being made and thus get more motivated to keep going. Also if you have something playable early on you can show it to friends, family and random people online to create buzz for your game. This buzz will in turn help motivate your team even more.

Keeping your team hungry for more is huge, especially if you can't currently pay them. People also are visual creatures and thus need to see progress. They need to see the project grow and branch out. The faster you can do this the better off you'll be. If your team can't see any real progress happening for a week or more they may feel the project is going no where and not be as excited to keep working on it. A big part of these low budget teams is the hope that one day the game they created will produce some kind of profit. But if the project moves slowly that hope starts to fade as they can't see the light at the end of the tunnel.

So keep your game small and your goals easily obtainable!

-As a side note going fast doesn't mean cutting corners. Don't release something that you don't feel meets your standards. Your game should look amazing and finished. The design should be solid and the program shouldn't have bugs. Again this is why you want a small game. You can keep a high standard or polish and still get something done fast. Just don't mistake speed for compromise.

Team size:

I used to only hire on 1 programmer at a time in my early ventures into the game industry. I'd find a programmer and show them all that I've accomplished and I'd keep in contact with them regularly. We'd be motivated, keeping on time and making the game just as intended until suddenly the programmer would come across something they didn't know how to do. I of course am not a programmer so I couldn't effectively help them. I'd attempt to send links and see if it helped, but often times the programmer would lose motivation and eventually just stop working all together.

Now I hire 2 or 3 programmers. I try not to hire more than 2 and keep the team small. This way the programmers can help each other when they hit a wall. They can talk it out and discuss possible solutions. This goes for you programmers hiring artists too. When I model, texture, rig or what have you I some times run into a problem I can't figure out. I ask the community and try to solve it, but nothing beats having some one there and asking them. 2 heads are better than one!

This also helps the project move along faster and keeps people motivated. One programmer or artist can work on one aspect while the other works on another. Also if one is taking a break due to school, work or whatever the other can still be making progress. When the first comes back they can see progress has been made. They just might need to be brought up to speed.

Just be cautious of hiring on too many people. It might sound great to have 10 programmers and 10 artists all working to finish a game, but I assure you that you'll quickly become over whelmed. With the more people you add on the more likely communication will break down. Some people might work on the same thing causing more confusion. Some might lose motivation if they don't feel they are doing enough and some might miss dead lines which effects much more people.

I once worked on team that attempted to make an ambitious game (already a red flag). The project sounded amazing and every one was motivated to work. I believe the team ended up with 20 people (red flag no.2). Right off the bat the person who organized the game started assigning tasks and roles which was done by a vote. I ended up being the art director and I'd report to another guy above me who then would report to the guy who organized this whole thing. The next day when I checked in with the team we found out that another 10 or so people had been trying to join, but went to the wrong destination (another red flag). So now we had to re-organize the team which took hours to do in the first place. Again I had the same role and just a few more people to work with. Next we had to start assigning tasks to our teams and getting the ball rolling. Since there was no organization set in place every one could write in the GDD to add whatever they wanted (yet another red flag). Soon the GDD was a mess and had to constantly be re-organized and we'd have to keep explaining the GDD to our teams, who then would make more suggestions. There was no due date so this just kept going on (what is this, the fifth red flag?). Mean while I'd assign tasks to my team to get prepared for making the art assets, however the guy above me would also tell them to do things without telling me, which made them and myself very confused (we're going to six flags folks!)

I left the team shortly after this for the reasons I expressed here and much much more. The project was a disaster and fell apart very quickly. What started with about 30 eager people and dropped to a handful of skeptical people and then dropped all together. Much of this could have been solved by keeping it a small team to start with to lay out the basics of the game, then grow a tiny bit to get the basic structure then further to fill out the rest.

This story also leads us to the next topic

Organization:

always keep organized! Keep naming conventions and sort all your assets in a way that makes sense to the whole team.

Have a task list so every one knows what they should be working on and what others are working on. This also helps the team know when due dates are for various aspects of the game. It also helps for when a team member comes back from a break they know where they left off, what tasks still need to be done and what they should be doing next. I personally use Trello for this and it has been very helpful so far.

Another good idea is saving your files 3 times. What I mean by this is make sure you save any given file in 3 different locations. For example one on your desk top, one on your laptop and one on an external hard drive. That way if your computer dies for whatever reason nothing will be lost.

Ensure that you and your team also have a set way of dealing with version control. Talk with your team about how you should handle version control without overwriting files and recovering files if some one accidentally overwrites them.

I hope this helps you and your teams as you move forward with your games. I'd also love to hear what has and hasn't worked for you as far as managing team goes. Do you have any horror stories you'd like to share?

Please share your experiences in the comments and if you have any suggestions for future topics let me know!

Take care everyone and I'll see you next time!