So, it's come to the junction where you've decided that you'd like to form and head up a project. It's time to recruit a proper team and build something real. Should be no problem, right? Your idea is bloody brilliant, and you're certain that people will be clamoring over each other to join when they hear your idea and see your logo.
Allow me to provide you with a reality check.
Nobody wants to join your project. Some people might very much like to see your project completed, but nobody really wants to join all that badly. We all have our own ideas and pet goals, so why on earth would anyone care about yours? But your idea is so much better, you might think. Nobody cares. If you want to start a project, you need to convince people that you have a lot to offer them, enough that they should work on your dream instead of their own.
So how do you convince people? Step one, have a real skill. Ideas are not a skill. Game design is a skill, but it's usually not strong enough to stand on its own. (And I'm talking real design here, which means a hundred page game design that sounds fun on PAGE ONE.) Art and programming, those can do the trick as long as you're good at it. And because you're good at it, you will have no problem coming to the table with an existing demo. Or a serious, substantial portfolio that you'd be comfortable sending to a potential employer.
Let me reiterate. You need one of these three things:
- A real game design document which sounds fun from the first page.
- A working demo of a something that at least behaves like a game.
- A real portfolio of artwork, preferably artwork for this game.
If you don't have at least one of those three, go home. You're not properly equipped yet.
Okay, let's say you've gotten your act together and one of these three is actually in your possession. The next big step in getting a team together is starting the other two. The more you do, the better.
- I don't know how to design a game!
- I don't know how to code!
- I can't do artwork!
Once again, go home. In fact, stop and ask yourself this question: Can I do this project entirely by myself? If the answer is no, don't start a team. It's okay if you'd do an awful job, or if it would take you years upon years to finish. But if you don't have the skills right now to actually complete this project on your own, you've got absolutely no business running a team. A team lead has to be aware of all the issues that the team is going to run into, on all fronts, and be able to assist and participate in the decision making process. Note: I'm not suggesting micromanagement, but you should be able to understand at least generally what your people are doing at any given point in time and what problems they're facing. Otherwise you're not a lead, you're just another passenger.
By the way, it should be obvious at this point that recruiting a team comes several months into development. Project first, team second. That's how successful online projects work.
Lastly, you need to be willing to lead. That probably sounds stupid and obvious, but it's a critical point and people don't consider what it entails. Leadership does not mean "I'm the forum admin and also have the best ideas." It means being a manager and a boss. And make sure you understand what that really means.
Deadlines, milestones, and deliverables needs to be set and adjusted realistically. And this is especially for the teenagers -- if you've never been on a software project, you don't know anything about milestones. Sorry, but professional experience (not necessarily as a manager) is basically a prerequisite.
Be ready to fire people. In the real world, people's livelihoods are on the line; there's incentive to do a good job and there's incentive not to fire people callously. Without the money involved, neither side is really bound by those rules. Now life happens, and nobody will really be able to dedicate their entire lives to side projects. But if somebody is consistently flaking out on you, you better have the spine to end their involvement and go find someone else.
Promotions and demotions can happen. If someone is way better or worse than expected, don't be afraid to change the hierarchy. Some tact is called for when you're telling someone they suck and have to follow another team member, but that's part of running a project. And if they're not willing to accept those decisions, see the previous point.
Last but oft-forgotten and maybe the most important -- you are the lead, you are the manager, and in some sense you are a dictator. But communication between you and your team needs to be two way. Software projects tend to mutate and evolve drastically over their lifetime, and that's not a top down progression. If you trust your people, you'll give feedback and suggestions an honest chance, and be ready to pick their ideas over your own. And if you don't trust them to provide that kind of support to the project, you're not fit to be leading it.
If any of this makes you uncomfortable, it's time to reconsider whether or not you're really ready to lead a team. And remember that a lot of professional developers don't want the hassle and will turn down a lead position. There's no shame in helping to produce someone else's project. Just remember this checklist when you're picking a team to join. It could save you from joining a dead-end group, after all.
