How to Fix Miscommunication Issues in Your Team

Good communication is important in all game development studios, even the smallest ones. You may think that small teams are immune from miscommunication, but if you think about it, you can have miscommunications even with the people closest to you (just ask my wife).  The only way to avoid miscommunication within a team is to be like Eric Barone and make a game on your own. For everyone else, practicing good communication skills is the only way that you can reduce friction in your team communications.

Good team communication may sound like a silly thing to be worried about, given all the things that can go wrong with a game. But I’m sure you don’t have to go back too far in your memories to remember an interaction with a teammate that should have taken 5 minutes, but instead took 30 minutes and left the both of you exhausted.

In the following case studies I’ll lay out some of the communication issues I noticed within our team, and how we tried to rectify them.

Mahirap ba to? (Is this hard?)

Since no one is immune from poor communication, I’ll use myself as an example. Often when new feature request would come in, I would ask our devs the question “Is this hard?” and receive some of the following answer.

Answer 1 : “Not really.”

Answer 2 : “Yeah it’s hard.”

Answer 3 : “It’s not hard but it will take a long time to implement.”

Inevitably, this would lead to more questions as I tried to figure out the level of difficulty of the task. Eventually I realized I was actually asking the wrong question. The last answer helped provide me a clue to what the better question actually was.

What I really wanted to know, in the context of my role as a project manager, was “How long will this take to implement” so that I can assess whether or not it is worth adding to the game, given its presumed impact. Since I came to this realization, i’ve been asking “how long” instead of “how hard”, and saving the team around a minute or two everytime these conversations come up.

Tatamaan Memory (The Memory Will be Hit) and Programmer Jargon

A problem that often occurs when programmers speak with non-programmers is that there are things that are jargon or just presumed as understood by non-programmers. While jargon can be useful sometimes if its clear that both parties understand what’s being said, once it become apparent that there is some misunderstanding, further clarification should be offered. It should be incumbent on the person using the jargon to be the one to clarify what it is they are trying to say.  The following are some common responses given to me by our programmers. Initially they were inscrutable to me, and took quite some time to have them explained to me. I still forget what they mean sometimes, but maybe that’s a sign that I’m getting old.

1. The memory will be hit : This basically means that this will add to the game’s memory usage, and may cause some issues in the long run. It would still be useful to follow up on how much memory this will actually use and what the actual danger would be.

2. This needs to be saved : This basically means added complexity to the game, and larger save files, which we are trying to avoid.

3. We need to “keep track” of that : To be perfectly honest this still confuses me sometimes.

The important thing to consider here is that while jargon can be a useful shortcut between two people who understand each other, there needs to be a clear understanding that if the jargon is not understood, then an explanation is needed. Speaking of which...

The Technical Explanation is not an Explanation

Oftentimes when I ask our programmers what the implications of an issue are, they will respond with *a technical explanation*. It’s hard for me to really explain this, so an analogy might be better. If I ask someone “what would happen if I threw this ball at your face?” the answer I really want, and would be useful, is not *an explanation of the physics of acceleration, mass, wind resistance, etc*. The useful answer would be “The ball will hit me in the face, and it would hurt.”

Similarly, when asked about the impact of a design or code change to the game, it’s probably easier to explain how these changes would impact the player/game, rather than how it would change the code. 

Fewer Words is Better (Not!)

As many gamedevs are quiet introverts, many of us have embraced the idea that saying as few words as possible is the most efficient way to get out of having to talk to people.  This gives rise to two issues when a quiet dev is asked to clarify something in the game/code:

1. The person they are speaking to is either too meek or doesn’t care enough to keep asking clarifying questions. This ends the conversation very quickly but inevitably creates a problem down the road where errors that come out of the miscommunication impact the game.

2. The person they are speaking to is not satisfied with their answer so they will keep asking until they have a satisfactory answer, possibly creating a stressful or hostile environment.

Issue 2 is not only tiring to both the quiet dev and their questioner, it’s doubly unfair to the questioner because they have to expend the effort of finding context and clarifying meaning, which is a lot of mental work

My only advice here is to ask people to consider adding clarifying context to their statements. This may involve some additional effort on their end, but saves everyone a lot of time in the long run.

Zero Information Answers

And here’s me doing a u-turn. Just as it is important to note that using as few words as possible is not the best way to communicate, there are times when we use too many words without really conveying useful information. Here’s an example:

Zero Information : Company A's cost and Company B's cost are far apart. 

Even though this statement may be accurate, it gives zero actionable information and forces the recipient to ask you follow up questions.

Some Information : Company A is cheaper than Company B

This sentence is shorter and immediately provides context. Company A is cheaper, which ostensibly is a good thing.  Recipient can then ask follow up questions like “but do they offer the same level of service?”

Most Useful Information : Company A is cheaper than Company B, but I like company B’s service better.

This sentence immediately provides context and answers a possible follow up question.  It is the perfect answer in terms of information efficiency.

Obviously we won’t be able to reach peak information efficiency all the time, but taking a little effort to think about what it is that we want to convey before typing it in can lead to great improvements in communication. This is especially useful when conversations are in chat or email. There is no immediate pressure to respond, so take your time!

Zero Information Questions

The flipside of of Zero Info Answers is Zero Info Questions.  This is when a colleague asks you a question but does not accurately provide context as to what the question is about. Here’s an example:

Zero Information : Can you review the sizes for the exam results panel? It seems like the numbers are wrong. Some of them don’t add up. Like, the sum of the heights of the student exam header (right side) is not the same as the height of the students grid.

While this question may be accurate, there are no context clues about what the actual problem is and forces the recipient to investigate further.  Instead of saying something is different, say why you think that difference is wrong, and what you assume is the correct solution.

Some Information : Can you review the sizes for the exam results panel? The numbers on the student grid are shorter than the sum of the student exam results panel.

This is more useful because it immediately tells the recipient what the problem is, and they can investigate it.

Most Useful Information : Can you review the sizes for the exam results panel? The numbers on the student grid are shorter than the sum of the student exam results panel. I think they should be the same height.

This is more useful because it immediately tells the recipient what the problem is, and what the expectations are.

Always remember, instead of just saying something is different, provide context as to why it is different (ie one is shorter/cheaper/faster than the other).

Pwede Naman (It can be/can be done)

My last example is a little language specific, Filipino to be exact, but I’m sure there must be similar language cases in other countries. Locally, “Pwede Naman” is a non committal catch all term that can provide different meanings based on context or the person using it. One person’s “pwede naman” might be a yes, but I’d only ever use it to convey a very ambivalent feeling, something like saying “I guess that’s ok…” in English.

This is fine when used in casual conversation, but I absolutely hate it when used in a decision making context. Here’s an example for when someone is asked “what do you think about adding this mechanic to the game?”.

Zero Information : I guess that’s ok.

This gives no context or value judgement whatsoever. It conveys no opinion. If you are not sure about the impact of a mechanic, it’s better to very clearly say something like “I really don’t have strong feelings about this” or “I need more time to think about this and then I’ll get back to you.”

Some Information : I like it, but I have some concerns OR I think that’s a bad idea because (concerns).

This clearly conveys how you feel (either positive or negative) about the mechanic and that you have concerns about the design, and what they are.

Most Useful Information : I love it, but I have some concerns OR I think that’s a terrible idea because (concerns). Then explain (concerns)

This is basically the same as the previous example but with a further explanation of the specific concerns, and the use of stronger language to convey your feelings about the mechanic.

This bothered me so much that during our company outing last and team building event last year I brought it up and made everyone promise to never use the words “pwede naman” again in a work context. Did I succeed? Well...pwede naman.

Conclusion

Any team of more than one person requires good communication in order to succeed, or at least have a more harmonious work environment. This is even more important in smaller teams. In large organizations poor communicators can be hidden away or have better communicators or team leaders assigned to them in order to facilitate communication. In a small team, there’s nowhere for these issues to hide. This is especially important if you are the leader of your team. You may not think that there is a communication issue because, well, people never communicate it to you. But in fact people are either too scared of you to ask for clarification or will just make their own assumptions about what you meant, either of which will lead to bad outcomes in the long run.