The Grand Unification Theory of Game Projects

This post is reblogged from discordia.se
This is a trick title. There is no such thing as a Grand Unification Theory of Game Projects. The Best Way to Manage a Project is a lie, at least in part, and anyone who tells you they have all the answers before a project starts is most likely wrong or slightly megalomaniac. Possibly both. As a new producer, you’ll most likely struggle with the demands of your publisher, the way the team wants to (or doesn’t want to) structure the work and the Holy Grail of Project management, which for the moment is Agile. Scrum or Kanban being the fashionable choices. My advice would be “collect methods”. Learn a lot of them, and see them as tools and not the definitive answer to how to run a project. I’ve read a billion books (maybe not, but at least ten) that has to do with project management, and they will give you good ideas and ways to manage, but in the end, the context will always decide.

Usually it’s all a mess, and you can barely keep your head over the surface. There are demands coming in from all directions, and somehow, you’re the one expected to have all the answers. I know. I’ve been there. So here’s what I’ve learned, both the hard way and the really hard way. I’m perhaps being a bit too honest here, but the truth is I’ve never come across a team where everything has been fine and dandy. There’s always something. The trick is to remove or at least reduce that “something” in order to not have it disrupt the team.

What you really need when managing a project is the following.

Velocity data. You will need to know how fast a team can complete an estimated piece of work.
Accurate (to a point) estimates for a piece of work. The accuracy of the estimates will be dependant on…
Well defined pieces of work. As in “we know what we need to accomplish”
A way to report this to product owners and publishers i.e. the people with the money, in a form that satisfies them and keeps them happy and informed of progress
That’s really all you need. The hard part is how to get there. The first thing you should keep in mind is that all projects are different. They may have the same-ish goals – at the end of it there should be a product – but truthfully all projects are conglomerates of people, end goal (or product) and the company culture. As a producer landing in that mix, you’ll have to be humble, you’ll have to listen and try to define the requirements coming from the team, the company and the project.

These requirements will sometimes be at odds with each other, and at each turn, you’ll have to decide which requirement needs priority. Sometimes it will be very simple. The project needs to deliver, and so you’re left with no choice but to prioritise project needs. Sometimes it’s a lot harder, and you’ll have to weigh project needs, team needs and company requirements against each other. My personal instinct is always to go with team needs first. If you listen to and respect your team, they will listen to and respect you. A part of that respect is to clearly define the work that needs doing. That kind of work takes time. It is tedious, sometimes boring, but if you want something out of the team, you’ll have to do it properly. The good news is that if you are consistent and persistent, the definition of tasks becomes easier and easier as the project crystallises.

Planning – if done correctly – is never wasted.

A clear goal will also help the product owners to say “yes, this is what I want” or “no, I would want this instead.” It is much easier to prioritise when you know exactly what it is you’re choosing to build, and what it is you’re delaying. The clearer the deliveries, the better they will be, even if it turns out that it wasn’t what the product owner wanted.

The one thing I learned that is most precious to me in my role as producer was to listen to the team. They are the experts. They know their systems in a way someone not as acquainted with the feature will not. If you give them the trust they need to create the end result you’re asking for, most teams will a) take pride in what they do b) make sure to be as accurate as they can when delivering.

This won’t happen if you micromanage them, or if you don’t manage them at all. Micro management – in my opinion – kills trust. It kills initiative and it kills pride in work well done. It’s a useless way to manage a team. Never ever let your need for control take the upper hand. It will turn you into a really bad boss. No management at all leaves the team members uncertain and floundering. If they have no clear goal, they have no way of devising a way to get to the goal. It’s just as bad as micro management.

Of course, trust goes both ways. Independence and agency goes both ways. Most people, at least in game development, will rise to the challenge if you let them, and if they are okay with the planning process. Which leads me to the planning process. You might encounter protests when trying to plan a team in a way they’re not used to. I usually try to ask how they want to handle the planning, and I also try to present the demands I have on me from the product owners, publishers etc. If you are transparent with what needs to be “known” by the project, and if you can motivate it, both for yourself and for the team, it is usually possible to reach an understanding. Sometimes it won’t be possible to motivate demands (such as “we need everything documented now“) but try anyway. If documentation is needed, ask the team “what kind of documentation would be useful at this point?” instead of pushing an agenda. Oh and yeah, deliveries should be discussed with the team before agreeing to them. Perhaps the team was just about to deliver a neat prototype when they were asked to write 20 pages of text. I have to tell you that personally, I don’t much mind documentation. I like writing specs and I enjoy defining things for myself. Not everyone works that way.

Transparency, honesty and communication usually does the trick, with a bit of respect thrown in there as well. If team members know what’s going on in a project they can be proactive and take (proper) initiatives that will push the project ahead. If not, well, they’ll make decisions based on incorrect or missing information, or they won’t be proactive at all (for fear of making the wrong decisions). There is very little benefit to withholding information or playing politics in a project. Company cultures or project cultures based on withholding information or manipulation are toxic cultures. Those kinds of environments will have huge churn numbers, and they will lose the developers that are the most skilled and driven. Only a masochist would stay in a company culture like that. Power struggles within projects or companies also open up for playing favourites and harassment of those who aren’t playing along. It becomes an environment that is uncertain and where people are afraid to speak up for fear of being the next one singled out for punishment. Management by fear is a bad, bad idea.

As a producer (and developer in general) I always try to inform about what I’m doing and why I’m doing it. Not only does it give insight into what is happening in the project, it also removes the risk of doubling the work. If everyone knows I’m working on something, they’ll be able to put it out of their minds and do something else.

One way to ensure a good and open communication is through planning and defining what is supposed to be done. It is also very important that all members of your team know what they’ll be doing; not only due to efficiency but also for the self esteem of the team members. To spend time in a project without clear goals is devastating to self esteem and agency. If you know where you’re going, you can get there. If you don’t have a goal defined, how could you possibly have any idea when the goal has been reached? It is incredibly demoralising to not have planned work. It removes the sense of accomplishment that one actually gets from ticking in a box that says “done”.

My attitude towards work has always been to do as good a job as I can. For that to happen. I need some boxes ticked. Since discordia is a game dev-ish blog, and since there is a psychological model being used to try to explain what players want from a game, I can tell you that the PENS model works excellently on developers as well. PENS stands for Player Experience of Need satisfaction. Those needs that want to be satisfied are:

• Competence
• Autonomy
• Relatedness

Competence can be satisfied by giving the developer a challenging task that will make the dev feel effective and stretch abilities. In some cases it doesn’t even have to be a challenge. It might be enough just to tick another box to done. Making developers (or players) feel effective will lead to them working even harder and more intense. And again, everyone is different, so listen carefully to your team members when they outline what kind of work they enjoy doing. You can’t always do what you want in game development, but it should be a healthy mix of challenge and drudgery. No one benefits from a bored developer.

Autonomy ought to be obvious. The developers know the systems. Present the goals, but let the devs themselves figure out how to reach them. Give them the opportunity to choose the solutions for themselves. Sometimes this this will fail, but it will be a lesson well learned. Micromanagement and control freakishness kills motivation. Don’t do it, and if you do, try to stop. Get help. I’ve been there, I used to do it, but it leads to burnout and people not liking you much. But, and this is important, autonomy means different things for different people. Some want that checklist. Some want to know exactly what to do and when to do it. Too much freedom will freak them out. Make sure that you know your developers and what they need to be happy.

The last one is relatedness. This means having good relationships with your co-workers. They can save you from untold misery. Therefore, encourage team building in different ways, but again be aware that not all devs function in the same way. A lot of the time “team building” means “go out and drink alcohol”. This will not work for all kinds of people. Again, poll the team members. Ask them what they’d like to do, what suits them. Beer is not the only way to build a team. Workshops are also good. Team meetings. Lunches. The team will know.

I guess the main takeaways from this somewhat rambling post are the following: Trust and respect your team and it will trust and respect you. A team is not made up of automatons, but of individuals. Play to their strengths and make each one of them feel valued and important and they will be.

For me, being a producer is 99% listening and 1% admin. Okay. maybe that’s not quite true, but a lot of what I did when I produced was to make sure the team was comfortable and happy. If I managed that, the rest came (almost) automatically. The one thing I did try to do though was to be consistent both in what I’d say I’d do and what I actually did. Also, there is no magic project management bullet. Each project will have its own needs, and those needs will be dictated by product owners, company culture and team members. The trick is to find a process that works for your project and follow it until it becomes trustworthy data wise and second nature to the devs that use it. It should change and grow with the project, and the needs of the project.