Group Culture
It might not seem like this should be the first point to mention, but I think it is. All games are made with a group. And by all I mean all, except for like two or three (that have been successful). You will probably make your game with a group, and you will encounter this whether you know about it or not. So, better know about it. In regards to group culture this means, when you work together with people in a group, a group culture will form. This is inevitable, and the quality of this culture will play a major part in the success of any project.
But what is group culture? Well, it is hard to define in a compact way, but I like to think of it as the shared values and attitudes of the group members towards the group. This includes things such as how focused the group is on its work, how much slacking off is acceptable, to what standards of quality we hold us, but also what kind of in-jokes there are and what things we put up on our workspace walls. A key component that was identified by different pieces of research is the concept of psychological safety. Psychological safety means that all team members feel accepted and respected, and there is a sense of mutual trust. The benefit of this are plenty: Team members are more motivated to come to work, they are more likely to come up with ideas, speak up, and ask important questions, and it boosts creativity and innovation, in fact it is one of the key requirements for a successful brainstorm (but more on that in another post). How to achieve this, I am probably not the best person to give advice on. I just happened to be in a team where this occurred organically, without specific fostering. However, lots of smarter people have written articles and books about this, which you can easily find. For me, one of the most important things is to show vulnerability, and not criticising other people, which are key points I am trying to improve upon.
In any case, what you do with this is up to you, just be aware that this exists and that it is a key factor in the success your team and project.
Further reading:
- Google’s Quest to Build the Perfect Team – NY Times
- The Importance of Group Culture – Psychochild’s Blog
Manager Time vs. Maker Time
The difference between how managers see time versus how makers, in this case programmers, artists, designers etc., see time is one of those things that you don’t notice at first, but once you know about it it makes perfect sense. If you are one of the aforementioned makers, than you will surely remember instances where you just wanted to focus on the interesting work you were doing, if only people didn’t keep interrupting you. The concept of Flow, which you might know from game design as a state in which one is completely focused on one task and ignoring the rest of the world, is relevant here as well. I know that during my most recent project, I did most of the heavy duty programming tasks only after most of the others had left, giving me some quiet time to get into the mindset and concentration needed to solve some of the problems we were having. The reason for this is that during the rest of the day I would be interrupted by the others constantly, because it was part of my role as producer and director of the game. I had to comment on artwork, make design decisions, assign tasks to developers, and occasionally assist them in their tasks. Since that was what the role required, I did not have the long stretch of uninterrupted time necessary to focus on complicated creative tasks.
This is pretty much the fundamental conflict between manager time and maker time. Managers like their time scheduled in bite sized bits, like a meeting or a review, and if they are not busy then they can be interrupted, since they should have offloaded all of the heavy duty tasks onto the development team. Makers however like to plan their tasks in half-days, not hours, and need those to be uninterrupted. In fact, this is the most important point here. A study has shown that programmers take around 30 minutes just to get back to where they were before being interrupted, and this is of course highly unproductive and frustrating. This is why it is the most important job of a producer, or SCRUM master, or whatever you might call it, to shield the team from interruptions. And not just from external interruptions, but also from internal ones. However, we also need to allow for enough communication to occur, to make sure that everyone knows everything they need to know at any given time, and just to foster a better team atmosphere.
But how do we accomplish this in a production setting? Well, there are some tricks. Firstly, encourage the use of headphones at the workplace. They provide an easy way to block around the inevitable sound in the surroundings – after all, talking isn’t banned, and can often be a very useful means of communication. However, talking directly to people is also an interruption and should thus be reserved for highest priority matters only. All other communication should be happening via chat, e-mail, or other tools such as a ticket system. This allows everyone to deal with the requests in their own time. I recommend to disable the notifications from these programs as much as possible, otherwise they become distractions again.
Further reading:
- Maker’s Schedule, Manager’s Schedule – Paul Graham
- Programmer, Interrupted – Gamasutra
- This Is Why You Shouldn’t Interrupt a Programmer – J. Heeris
A well-aligned group culture 🙂