Modding: Avoid making the same mistakes that I did #2
Keep your team as small as possible
There are numerous reasons for this. Firstly, keeping the team small keeps expectations low. Things remain friendly and it tends to foster an attitude of “we’re in this together”. If you’re working on something with a handful of friends or dedicated workers (who will likely become good friends!) then you feel inclined to pull for the team that little bit more. When FF was just starting, I felt guilty if I let the side down because there were maybe 5-10 people tops who were depending on me, nearly all of whom were working very hard themselves. I’d say we made much more progress (at least in terms of productivity per person) in the early days when our team was tight knit. There wasn’t much in the way of politics at that time, and things were much simpler to keep track of.
The more people you have working on a mod, the more people you have to manage. As more and more people join, you tend to have to add further levels of indirection. Most leaders cannot hope to keep tabs on 40 people or understand the ins and outs of every discipline. Furthermore, if someone joins and finds that they’re 1/40th of an unpaid mod team, they may be less inclined to work hard. This is especially the case if that person can look around and see that 20 people out of those 40 don’t seem to be doing anything. Unless a modder is a very self-driven and conscientious worker, they will feel demotivated by being a cog in a huge, messy machine. Creating something is meant to be gratifying, not galling. This is particularly important if a person’s work has dependencies. If Jim works 15 hours a week on the mod and finishes all of his work, but requires Iain and Bill to put in a combined 10 hours to complete the feature they’re all working on, Jim is going to be severely fucking demotivated if Iain and Bill consistently fail to hold up their end of the bargain. If it’s a small team then this is less likely to happen. If it’s a big team, then Iain and Bill might just not give a shit. After all, Henry and Mike aren’t doing anything, either!
Avoid bad applies
Now, I know this is the INTERNET and it can be extremely difficult to gauge someone’s personality when your communication is handled through emails, IRC or voice chats but… try to do your best. If you get a whiff of something being ‘not quite right’ (be it their personality or their dedication), then tread carefully. For example, if someone claims to have been on multiple mod teams but has very little work to show for it, ask around about them. Go to the mod teams’ websites and get in touch with some of their members. Ask what the person did for them and whether they left on good terms etc. This doesn’t have the invasive, just a cursory check. If someone is a bullshit-merchant, they are not going to be of use to you.
Similarly, be very aware of people who have some cool screenshots of very specific parts of their work but seemingly nothing else to show you. Alarm bells should start ringing if all someone can show you is one room in a level or half of a gun that has been textured. You should move to defcon1 when you’re linked to multiple unfinished images, no matter how good they look in isolation. A lot of people like to do the first fun part of development, but are total flakes when it comes to finishing (or even thinking about finishing) because, in all walks of development, finishing is hard. Doing the horrible little bits like balancing work, general tidying up, bug-fixing and optimisation is a pain. People who cannot finish personal work under their own steam are nearly always useless to a mod. If they cannot be bothered to finish stuff of their own choosing, are they going to muck in with everyone else during the parts that suck? I doubt it.
Don’t recruit just to recruit
This one follows on from the previous point. If someone is keen on joining and they’re good but not outstanding, but you don’t need to recruit because everything is going fine… don’t recruit! It can be hard to pass up a good modder, but you should be very selective if you have something good going on. If you’re just starting out then fine, grab anyone you can! Once you’re moving along nicely, don’t disrupt things unless you have to. Also, before you bring on a new person, you should always know how to get them moving immediately. By this I mean they should feel included and know what they have to do from the first moment. This doesn’t mean you pressure someone to produce immediately, but it means you should give them the means to get started.
This could simply mean that they join the mod and immediately have IRC/forum/vent/source code/bug tracker access and some suggestions on what they ought to be doing (“Hey, it’d be cool if the bug in feature y could be fixed” or “The balance of gun x isn’t quite right, you could try and sort that out when you have time”). If you leave a new modder dangling for days or weeks, it looks bad and makes you look like a bunch of clowns! You don’t want that, do you? No.