Working with other people, or How I learnt to play support

In my game development life, I have had to work with other people many times. Every time is different, requires different skills, tactics, methodologies etc. You can't do that without learning something new each time. When I worked with 2 people on A Maze Ball, I learnt that people could be unreliable and instructions need to be clear. On Hearth, I learnt that there is in fact a way to have too many people on one project, and that project management is a lot harder than I thought. On SpaceRace I'm learning that clear, concise documentation isn't enough to make sure that everyone knows what they're doing. But this isn't a bitchy blog. This is a reflective blog.

When I say "clear, concise documentation", I might have misspoke. See, I wrote the documentation for SpaceRace to be clear and concise. But my teammate doesn't agree. So, without assuming he didn't just NOT READ my documents, let's dive in and find out why my document isn't up top scratch. We'll start with what I missed.

Timeline

I didn't put a timeline in. Let me say that again. I DID NOT INCLUDE A TIMELINE! This is absolutely my biggest mistake, and I don't even have a good excuse. I mean, it takes no time at all, and it covers my arse if things go awry. But no. I didn't. And when I come back to read this blog, I will remember how much pain this caused me during this project.

Assign Tasks

When working with a team, it's essential that you have assigned roles to each member. We have our programmer, our designers, our artist, our audio team, and they all have jobs to do. That, in itself does not mean those jobs will be done. As a project manager, it is my job to make sure everyone knows and does their job. A timeline would help with this, but for the most part, it's assertive delegation. I didn't know the strengths and weaknesses of my team members (I've never worked with any of them before), so I was unsure what tasks should be delegated where. A bit more of a process to find that out, and more time dedicated to delegation and this problem should sort itself out.

Don't write it all yourself

People don't like reading. Especially things that they are forced to read and they didn't have a part in writing. A peer of mine gave me a great analogy to deal with how to make people join in writing the document. If you have a dog, and the dog poops on the carpet, you don't go poop outside, just so there is poop where it is supposed to be. You punish the dog and make it learn to poop outside where it's damn supposed to. That means, if someone doesn't help write the documentation, don't just write it for them. Make them write it. It's not the job of project manager to write the documentation. It's the job of the TEAM to write the documentation. Then, everyone HAS TO KNOW what's in it. Also, there is less of a problem getting people to read it.

I don't need to be the hero

It's fine. Really. I wanted to be a game designer and an artist, but I suppose I don't mind the backend stuff. It's not all bad. Being in control of the document means you know everything.l Knowing everything means you have to answer everyone's dumb questions about their own project. Truly though. I'm not bitter. It's just that I pour so much work into nice, clear, concise documentation and nobody reads it. Really, it's fine.