The rules of effective communication
Hi, I am back again with another Medium article. This time the article will be expanding on communication, a topic I have touched on briefly in my previous article:
If you had asked me two years ago what defines an effective communication, I would have given you a different answer compared to now. Here are my learnings I have gathered over the past 2 years of working at Mighty Bear Games.
I would like to point out beforehand that what I am sharing here is just my personal take. Some of these suggestions might not work if your circumstances are different, for example different team size or different hierarchy of your work environment.
Hopefully whatever I shared here will be applicable and helpful to whoever is reading this. Without further ado, let’s dive in.
To properly convey your message across to the other party there needs to be a proper structure to your message. Take some time to pause and compose the message in your head before speaking. The other party does not know what your thoughts are so you will need to bring them up to speed.
For example, if I was discussing a bug I am encountering with a fellow engineer, the structure would be as follows:
- Explain what I am trying to do/solve. E.g. To make a bullet spawn when firing a gun.
- Explain in detail the bug I am encountering. E.g. The bullet is not spawning on server but on client.
- Explain what I have done. E.g. I have tried spawning the bullet under the SpawnBullet script.
Back then I would have just mentioned the bugs I am encountering without any context causing confusion and taking up the fellow engineer’s time as they try to unravel the issue piece by piece. Without the proper communication structure both of us would have to spend more time trying to understand the problem rather than solving the problem.
Adapting Communication Style:
As an engineer I am used to speaking in engineering lingo (back-end, front-end, client, server, etc.). Sometimes I forget that other disciplines are not as well versed in this communication style and might not understand what I am trying to say.
But this issue is not just an engineering problem, every discipline has their own way of speaking, and as the new guy I don’t always understand what the other party is trying to say, or even misunderstand what they are trying to convey and make my own assumptions.
Stop the other party immediately if you do not understand what they mean, and vice versa. If you see someone that looks confused about what you are explaining, check with them to make sure they’re on the same page before progressing any further.
Conveying intention vs conveying decision:
This is something I learnt rather recently myself, and I feel that it is as important for us to convey our intention as it is to convey our decision. But most of the time, what is conveyed is only the latter.
For example, if I was asked how long would a certain difficult feature take to implement and if I was to just give my estimate, that would be pretty much the end of the conversation. The Product Owner/Project Manager would then take what was given and plan with only that knowledge.
But what if there is an alternative to that feature? What if we can implement just part of the feature or have an alternative way of implementing it?These are options that PO/PM might not know/have when making their decision.
That is why it is important to convey our intention when making a decision and let the other party know of it. That will give them a better understanding of our decision making process and maybe they will add some of their own ideas too, creating a better environment for discussion.
Finally, do not be afraid to ask questions. If there is something you don’t know or don’t understand there is bound to be someone else also who is in your situation. Question how things work, at worse you might get embarrassed when something obvious is pointed out but at best you might learn something new today or bring up an issue someone hasn’t thought of before.