Opinion: You Can’t Please Everyone… Can You?
Starting up a new project has me thinking a lot about ways to improve team buy-in and enthusiasm about the game that we are building. I’ve worked on many different team types over the last decade and have seen many ways to run things… with varying degrees of success. As team sizes are easily in the area of 100+ people on the types of games I generally work on, communication alone becomes difficult.
The small team on the beginning of a project is usually spending their time thinking about what key features they want to build the game around… or what new features to add in the case of a sequel. Some teams use this early time to make the plan for the game and nail down a lot of the top level decisions before everyone else rolls on so people can hit the ground running.
Other teams may decide to use this time to keep things very loose and come up with lots of ideas for ways to go in various areas of the development. This could mean having front-runners in areas of decision as a basis to work forward from, but essentially waiting for a bigger chunk of the team to come on board and help make those decisions final.
There generally, in my opinion, seems to be two types of game developers when it comes to moving onto a new project. The first group really enjoys to be a part of the decision process. If you choose to lock some Design decisions down early, they will feel that it’s too late for their ideas to be heard and they may not feel like they can fully get on board with the decisions that were made.
The other group prefers to have the big decisions made so they can apply their expertise to the situation and make the best game possible within those constraints. If you keep things open, they may feel that the group doesn’t have their heads on straight, what have they been doing all this time, and how can I be effective in this lack of direction?
How do you accommodate both types of people? It would be ideal if we could get the people who want to be involved first and the others much later on… but that kind of thinking is from a dream world. So, what are some potential ways we can get people to buy-in and truly get behind what we are making regardless of what method is being used? I wish I had answers… but I do have a few thoughts:
I think it’s important to go out of your way to ensure that every person coming onto the team knows exactly what decisions have and have not been made right away. Give them as much context as possible and try to help them understand why. If every team member gets the proper info right away, then any misconceptions can be washed away and a new groundwork can be laid for moving forward. They may not be happy with the decisions made, or not made, but this allows a great starting point for discussions.
Sometimes you’ll think that everyone is on the same page about a decision and find out that you weren’t effective enough in getting the message across. It takes great effort, often multiple tries, to make sure the right info gets to everyone. This step is sometimes deemed important by designers because they don’t feel they have to justify decisions or even expect that team members will read the documents they have created about each topic (they won’t).
I think there is often a lack of understanding of what a Design team does and how even our best laid plans early on can go horribly wrong. There are a lot of assumptions that have to be made by designers in the early stages of development and those sometimes have to be re-evaluated as the game evolves or cuts happen. Coming up with ideas is easy…it’s finding the ones that fit in the vision of the game and with your constantly changing time constraints that make them good Design decisions.
Other disciplines often view this as Design changing their minds or not knowing what they are doing and it’s hard for them work toward a moving target. The team members who prefer to be involved may say the decision would have been better if only they would have been included in the first place. This can quickly lead to resentment of the Design Team, and that kind of respect is hard to regain once lost. Taking steps to fix the before mentioned communication will help with this, but nothing sucks more than someone doing work that later needs reworking or deemed unneeded entirely.
You have to do your best to make sure people understand as best as possible what goes into the decisions that are made. Respect goes both ways and you need to keep in mind that every team member’s time and opinions are valuable even if the opinions may not fit with your current goals. This kind of understanding can at the very least get you some empathy and keep the respect levels at a place where everyone can work together effectively.
I’m only partly kidding about this. If you find that some of the team members are having difficulty buying in to the game that everyone is making… try taking the discussion outside. Go somewhere outside of work and have a drink or lunch together and just talk frankly about what frustrations they are having. A very free conversation like this can often help you understand each other better and alcohol can only help with that right?
In the end…this is something I’m thinking a lot about for my project before team members start rolling on in large quantities. I obviously don’t have the answers, but really wanted to use this as a topic for discussion. What ideas do you have for helping with this? (Source: Gamasutra)