Communicating is the hardest thing you’ll do.

My name is Patrik and I’m the producer at Arrowhead, a position which I took just 5 months ago. Before I was a producer I worked as the designer and, during the later stages of development, as team leader on Helldivers.

Recently I was asked about the impact communication has on games: is good team communication essential for playing co-op games? My answer was less of a “yes” and more of a “hell yes” with a growing realization of just how much communication really does matter.

In any team-based game the quality and amount of information you provide your teammates with is critical to success. This prompted me to think about how we have used communication at work and to start defining what the issues were and what we could do to solve them.

The blogpost that follows is based off of my personal experiences, and I’m sure there is a big bunch of research on communication issues that you could look into for more in-depth reading.

1. Team (un)Scalability

Someone else has probably made this observation already, but I have found that as soon as a team reaches the size of more than 5 people the work efficiency lowers significantly. Adding another person is not equivalent to adding 100% more work on the game, instead it turns out to be more like 70% and in some cases even less.

As soon as you reach 7-8 people you start to need a proper team leader, someone that takes time out of their day to make sure that everyone is up to date and has the latest information.

When you reach a team of 15+ people, this quickly starts to resemble a full time job, and I do recommend you to find a dedicated team leader at this point. Someone who is not expected to produce anything for the actual game (though if they happen to contribute a bit, that can always be nice).

2. Bastumöten (decisions made in ad hoc meetings)

This is a term used in Sweden (eng. sauna meeting) and I have yet to find a better English equivalent. Essentially these meetings are what might occur when a few of the devs go out for a beer, hang around late at the office, or just generally sit around discussing the game. They find some feature that would be really nice, or revise a feature already in the game, and somehow they end up at a decision to change something.

The problem here is often not that the decision is bad, many of the best ideas come from a more relaxed informal environment, but rather that the change never reaches the entire team. It is essential that whatever you decide in meetings like these gets noted down, and that they are distributed to the whole team.

A great solution is to have a mailing list that incorporates your entire team – and make sure that it is used! However, don’t over-saturate your mail with information that not everyone needs to know, people will get tired of reading the “spam” and miss important information.

3. I thought you told him?

Plenty of times I have found people to simply not be up to date on what’s being worked on. It’s very easy to just forget that someone was sick the day that a decision was made, or that they were in a meeting and no one ever told them. Mailing out these small changes, however, could easily clutter up an inbox if they are mailed out every time you start working on something new.

A common solution is to use some form of Agile or Kanban workflow, where tasks are clearly defined and everything is up on a board for all to see. Yet in my experience people seldom have any idea what’s going on anyway since they tend to dig into their work and not look at boring organizational stuff.

I have found that morning meetings is the best way to go. Just gather quickly every morning and step through what people are going to spend their day on before getting started. Repeat this process daily and it becomes second nature just continuously update your team on what’s being worked on.

4. And on the topic of morning meetings…

I love these, others hate them. They have some downsides, like enforcing an interruption of work if they aren’t the absolute first thing in the morning, they can get tedious, and most of all they require that people are on time.

They neatly solve a lot of problems though. Like making sure that everyone has the latest information, an idea of what’s being worked on and can make sure that any blockers are well known. My preferred way of doing morning meetings is to just stand(!) in a circle, quickly present what you are working on, if anything is blocking your work, and anything else you might need to inform the team of (change in design, change in direction, that you have a dentist appointment and will be absent for a while, etc.).

A word of warning: make damned sure that the morning meetings do not become drawn out affairs! You are going to do them every day and people lose interest fast. Also it is important  to make sure that the morning meetings do not become a point of review, the purpose is not for the management to check if you were slacking off the day before but to facilitate good information flow. As your team grows I would recommend to have the morning meetings in smaller groups, and do a larger morning meeting where only one from each team talks.

5. “Someone” please fix this

This is a lesson I learned early on when I did reception duties for new students during my time at the University. If you ask “someone” to do something, no one will do it. “Can someone fix this asset?”, “Can someone fix this bug?”, requests are often ignored because everyone thinks someone else will take care of it.

I have found it immensely helpful to make sure that a name is attached to everything that needs to get done. This goes all the way from sprint planning to small issues found here and there. As long as people know that they personally do not need to do it, but they are responsible to make sure it gets done. It’s fine if they ask a co-worker to handle it instead, but this simple responsibility attachment is critical to make sure that the task reaches completion.

For sprint tasks, I make sure that each task is assigned to a team. It is then up to that team collectively, and primarily that teams lead, to make sure that the task gets done. Gameplay teams often have tasks that are 80% programming, but it still hinges on design.

6. Sprint planning

There are as many ways to organize your team as there are grains of sand in Sahara, many of them contain some sort of sprints. Currently at Arrowhead, we use a system where we plan one week sprints every Wednesday and do a rough planning of the following weeks’ sprint. Every Wednesday morning we then evaluate the sprint and mark down which tasks were completed and which failed (and for what reason). We then revise the rough plan we had in place and make a new rough for the following week.

Every task is assigned to a team, Gameplay, Art, or Code. It is not necessarily the team that will do the most work on the task, but rather those responsible for the completion of the task and the team that can clearly tell you when a task is complete.  Each task is also easily verifiable; they have a clear line where we can say if it passed or not.

7. What is Blockout and what is Greybox?

As we grew in the art department we quickly found that tasks we planned for sprints had vague descriptions. It used language that one week said to greybox something and the next week used blockout. It also tended to use wordings like “make pretty”, which we quickly found out was nigh on unverifiable.

We soon realized that we needed a common language with solid definitions of what words imply. This led to a larger overhaul of our art workflow, defining absolute terms for asset creation and level creation respectively. We are still revising this as we go but just a simple sheet with clear definitions of the words and what they imply will help your team speak the same language.

8. Language as a barrier

As with the clear definitions of words it’s important to realize that words have different meanings to different people – I say potato you think I mean tomato. Maybe not in the same extreme, but often disagreements between people can be boiled down to having the same opinion but communicating it differently.

This is especially true for people that have not worked with each other before, or simply those who may have a harder time reading social cues. People tend to naturally adapt to each other’s specific meaning if they work together for a long time, but just being aware that they might mean slightly different things with what they say compared to how you interpret them and this can make you think twice before getting into a heated argument.

9. What was it that I was supposed to do?

Another common issue is that someone may request for another person to do a task, but that said person can’t do it right away as they are already in the middle of something else.

The task is then misremembered and the end result is not what was requested. This is more common than one might think as the human memory is very unreliable. A good practice for this is to have a list, or just make a little post it note specifying the task that needed to get done. There is then a physical agreed upon  guideline to adhere to and the risk for tasks being misremembered or forgotten entirely is lowered.

When I give people specific tasks that need to get done “soon™” I have taken up the habit of asking them if they want it on a Post-It note or where they want it written down. Some like Post-Its, some have their own pads where they keep stuff that needs to get done, and some use Trello or similar.

10. To poke or not to poke the programmer

As we all know, programmers are of a special kind and like to shield themselves from the outer world. This is for a good reason though and applies to everyone: as soon as you are interrupted in your work you lose your flow and need to find it again. Being constantly poked by other people who require your attention can be infuriating.

Try to find ways of building a message queue instead. Use a chat program like Slack to send messages, the person can then go over Slack once they have the time or a natural break in their work.

Sometimes you just need help instantly because something is blocking your work or several other people’s work, and in that case of course you need to get help immediately. Just think twice before disturbing other people.

On a final note…

Communicating efficiently and at a good level is no easy task, as with everything it is best in moderation. Or as we say in Swedish: “Lagom är bäst.”

Save

Save

Save