If I’m lucky I’ll soon have enough work with RakNet that I wouldn’t be able to handle the workload by myself anymore. That means I’ll be in the hiring market for a bright graduate, someone talented, trainable, and willing to work cheap, at least until business is at a point where I can afford a raise.
Anyway, I’ve been debating internally how many checks and structure to give to a remote employee.
At one end, there’s my own first job out of college as a telecommuter. There was essentially no structure. I didn’t have to write reports. I had a very high level task (write the networking) but never had to write design documents or anything like that. I essentially decided on my own tasks, when I wanted to do them. I even used my own data structures and such in my own code, even though the code base already had data structures.
At the other end I could impose structure similar to my job now. Daily reports. Meetings. When you get a major task you are generally expected to write a design document first. What you work on is given to you in a schedule. (This is still very lax compared to some other places.)
The problem with the first approach is that you need someone who is very good and self-motivated. It would be of no benefit to me to hire someone who made a mess of things and I had to go back and have them redo it, or do it myself. In both cases neither of us will be happy. Similarly, without daily interaction and deadline pressures it’s easy to just have your telecommuter just do nothing, which is wasted money. However, when it works it works great. I considered that the best job in the world, except for the pay.
The problem with the second approach is that it’s essentially a waste of time – all that structure is designed to keep bad programmers from doing bad things and not working. At best it’s annoying to a good programmer and not motivating at all to work on something you don’t want to. You bleed programmers who think the grass is greener on the other side. However, since you always know what your people are working on you don’t get slackers who do as little as possible for years (which also happened at my first job).
This may change with time and experience, but I think the best approach may be to hire the best and trust them to do their best. Guide, rather than force, people to your goals through proper motivations such as giving them options on what to work on (and all the options are useful to you). Explaining why things need to be done rather than telling them to do it. Giving them freedom to make important decisions, both in programming and in game design. I think intrinsic motivations (the desire to do a good job) are more important than extrinsic motivations (money, bonuses) and it’s important to motivate people using the former, while still having the latter as a bonus for a job-well done.