This comes from a blog post I did for our r.e.B.E.R.t.h. game we're building up for a Kickstarter:
A Team That Works Together, Sticks Together
You could call me the team Producer, Project Manager, or some other form of team unifier, but my responsibility is to make sure the team is organized and marching in the right direction. The position often gets misunderstood as "the annoying guy that makes everyone follow an arbitrary process."* While this can, unfortunately, be true at times, what I want to do today is outline how my role has brought a bunch of people together to bust their asses for a year for a pretty rad project.
*Quote is for emphasis, and not what anyone on the team has actually said.
I'll start by offering a bit of advice...A team, or any organization, needs the same things to work together:
- Goals
- Trust
- Consistency
- Rewards
If you're still onboard with this rousing topic, then keep reading. By the end, it should give some good insight into how an effective team works together.
Goals
A good project has an outline of what should be accomplished by the end. Even if you're not certain that you'll hit every target along the way, its really important that you set goals for the project and the team.
Most people start with an idea that makes practical sense.
"This jumping mechanic be super cool if this was a game."
It's great to hold onto those kind of ideas, but it isn't the rallying cry to gather the troops. You'll discover, as the project progresses, that no one person has the same idea about what the end product will be if that's the way you start development. This should be swiftly addressed.
The way we've handled it on reBERth is to summarize what the ideal game will be in a succinct paragraph. It should answer the 5 questions (who, what, when, where, and how), and address the need for the project. It should capture the imagination of the team, if otherwise compel someone to be interested in the idea. If you have the team's attention, then you can go into a breakdown of the details: What kind of game is it? Where does it take place? Who are the characters? What kind of gameplay should I expect? How is it original?
Most importantly, sell it as a story. The idea has to really paint the same picture in the team's head. Use flowery wording. Write it in the voice of the movie trailer guy. Invoke inspirational sources when selling the big picture.
Next, take the time to set some parameters by outlining 3 (or more) facets of the project that should always be respected in decision making. You may, for instance, choose story telling, atmosphere, and core mechanics. With those set, you make sure to never betray those concepts. In other words, if a decision would make it more difficult to tell the story, but would be a super game play mechanic, you may have to be on the cutting room floor.
With all of that set up, set a semi-arbitrary date for when you want to get it done. Perhaps PAX Prime is when you want a playable vertical slice of the game. Set the date, and work the schedule backwards. Take into consideration release build time, QA testing, polish, code freeze, feature lock, content completion, Alpha, and Beta (yes, even for a vertical slice). Plot it out. If it doesn't work out, reset your schedule and keep building.
I promise you, winging it brings a ton of unmanageable headaches.
The last step is to sell the schedule to the team. Do they agree? Good! Use that to move everyone forward. Voice the goals often and reassess it frequently.
Trust
When we started reBERth, we brought on two people that were familiar enough with the game concept to want to jump in and start working with out Goals. We received good grace from them not because we had a strong idea of what we were building, but because we built trust amongst them. Trust can generally be earned by not being a jerk (i.e. not throwing anyone under the bus).
It's also very important to provide value to their work by either complimenting their workflow, or supporting what they do. More so, it's important to not hinder it. Additionally, listening and acting on input from the team ensures that your team will believe the things you say in the future.If you aim to do right by each person, then trust can be maintained.
Warning: Do NOT ABUSE THIS. IT IS EASILY LOST, AND VERY DIFFICULT TO REGAIN.
Consistency
This one delves into some fun Pavlovian behavioral training. Essentially, people learn fast when the framework (or rules) are consistent, and the reward and reaction are predictable. Make things unpredictable and people become real irritated real quickly, and lose whatever momentum was in place.
The first thing to do is to set up simple processes that happen at consistent times, and have a consistent format. Enforce the format, and don't change it unless people agree to a change. Make sure the processes are scheduled at a time that can reoccur.
For our team, we have the same weekly meeting that follows this format:
- Start with goals review
- Summarize what work is completed r
- Reviews the completed work by each team member
- Sets goals for the next week
We do this every week, and we try to maintain it to the best of our ability.
The second part of this brings me to...
...Reward
We all want to be acknowledged for the good things we do. Without it, its like working in an echo chamber. Even if we work solo, we will eventually show off what we've done, or talk about it. Why? Because it's reaffirming, and presents validity to why we spent the last 14 hours of your weekend working to make sure the build was functioning for the rest of team come Monday.
Reward doesn't even have to be some kind of physical gift either. It can be as simple as understanding the value of someone's output. This is why systems like code review work so well. One person provides output, another person provides input. It's a cycle that can be immensely rewarding.
To make sure the reBERth team has rewarding work, we've made team review part of our weekly meetings. Everyone is given a chance to show what they've done. Everyone is given an opportunity to give constructive feedback. Everyone gets to walk away with some feeling of accomplishment.
This can also be done for larger goals as well. Did the team meet an important milestone date? Was the build passed through cert with flying colors? You might want to think about throwing a pizza party to the dulcet tones of the Slow Jams Pandora station (trust me, its an awesome station).
Conclusion
You have to run your team like anything else: give them something to look forward to, build trust, set expectations and deliver on them, and reward good behavior. If you can manage that, you would be amazed at how a team can gel around an idea and deliver beyond expectations.
The whole site can be seen here: http://reberth.com/, or you can follow me on twitter [twitter]jstaniz[/twitter]
