This blog post stemmed from Allar’s blog post: Confessions of an Unreal Engine 4 Engineering Firefighter. If you haven’t read it I recommend the time investment. If your in a management position, it may just help you save yourself thousands of dollars down the road.

Over the course of my various projects at Champlain College, I have found one aspect most crucial on a small game development team is Trust. Without trust, crucial issues with hide in the corners of the project and potentially derail the entire thing. With trust, these issues can be identified, prioritized, and dealt with when needed. In general, the easiest way to have trust on a team is to collect people who have worked together before, but this pipe dream isn’t always possible. So instead, I’m going to go over some things I’ve done, and learned from, over the course of this semester to further strengthen the trust on our team. Even through the current hair pulling project that is getting our game released on Steam.

There are two main aspects that I feel generate trust among team members: open communication and resulting actions.

Open Communication

Open Communication, for me, indicates that a team is willing and able to discuss the project at length. This can be anything from an issue with code, design, art, direction, management, or anything. Being able to sit down together and talk about any given thing is important for members feeling valued and identifying potential problems.

If team members know they can bring up questions about everything with a project, their more likely to feel like they are an integral part of that project. Not only do they become more familiar with other people's’ work, but can understand the value more in their own work. Maybe a task doesn’t seem important in their eyes, but seeing their co-worker’s face light up and get passionate about what they’ve just made is incredibly rewarding.

Additionally, potential problems can be found by everyone on a team. Just because the designer has a long history doesn’t mean he has all the types of players in his head. Most people making games are gamers themselves, and can expose that player perspective on why people tend to never use that one ability. Then the designer can take this into account and work through how to adjust for that possibility. This is an example, but this type of discussion can happen across a game team.

Resulting Actions

While open communication is important, in order to cement that trust there needs to be follow-up actions based on the discussions. If an idea brought up and accepted, share that iteration with the initial point of contact. Maybe get their feedback and discuss the iteration with them about the benefits and costs of that version. This will remove any potential confusion around if someone is being heard, and that’s the important part here: actions are an indication that someone was heard. Without that validation, someone is likely to get discouraged on making meaningful contributions over time. If they tried to notify someone about a potential problem early on, nothing happens in response, and the place comes crashing down, then why should they bother bringing up another issue? This dismantles trust on a team and will only lead to more problems.

This is also true for disciplinary and rewarding actions. When something good, or bad, happens it should be responded with an action in a timely manner. Notice how I didn’t use the word: immediately, since that might cause even more problems. Instead, as a producer, I’ll reiterate what I’ve heard: de-escalate the issue, investigate the issue, and act accordingly. Never make split second, emotional responses and instead get to the bottom of the issue before making a decision. However, a decision must be made, and, in the case of large situations, needs to be communicated across the team. A word of caution on this though: actions should be the same across the team. Don’t give a Lead a break just because they are a Lead.

I realize most of this stuff might be considered basic. However, not only am I student just learning my way, Allar’s blog post seems to indicate to my the things I’ve talked about might not be happening. I wanted to write down my approach to minimizing discourse on a team, and I hope it might help someone deal with a problem on their own team!

Note: I went to GDC this year and am only now getting back on track with my blog posts. I plan to start rolling out more over the coming weeks!

Thank you for reading!

Enjoy the read? Want to chat? Follow me on Twitter @LiamCraffey