#15 – Communication is compulsory

It may be because I identified that there was a problem and opened my mind to discovering was it was. Today, it clicked that the problem is communication. Specifically, it is the lack of proper communication. It kind of occurred to me when I called my group members, and they shared their worries about the project (check yesterday’s post). They were not nonchalant. But like me, they handled it in the way they knew how to. However, communication trumps individual coping mechanisms that can be misunderstood and lead to conflicts.

How do you communicate, though? Do you state exactly how you feel? Is diplomacy a better course of action? Say what you think and feel, but try not to sound accusatory. Is that it? To be honest, I am not entirely sure. Me communicating well yesterday was accidental. Panic led me there. If I’m being sincere, my group members steered the conversation better. So, I don’t believe that that’s always the right motivation. Hear me out. When you panic, adrenaline is pumped into your body, triggering a fight-or-flight response. I doubt any logical thoughts will go through your head at this time, only instinctive ones.

We can see now that when, how, and what you communicate are all important. Let’s see when communication is needed.

  1. When you start. You should talk about the beginning of any alliance or relationship. Communicate your expectations, plans, excitements, and availability. The group should brainstorm and agree on a course of action it will take. “Together” is the keyword here. Agreeing collectively would ensure that everyone is on the same page. I’ll use my experience as a project manager as an example. I had to manage 11 teams of designers and developers (initially 14) as they created interesting products at Zuri Internship. My approach (as I had learned while taking some UX courses) is for all members of the team to share ideas in the design thinking sessions. In many cases, this would be the designers’ task (which I don’t agree with). As designers and developers brainstormed together, the devs were able to relate their reservations about certain ideas and designers related the reasons for certain design choices. In the end, both parties had the same expectations and plan. They were excited too. The design thinking session – which I would like to dub, “First communication” – was also an opportunity for everyone on the team to get to know each other. We also talked about the timeframe and when the next meeting will be. Worked sailed quite smoothly after this. One of my teams (PJT-33) with whom I used this approach emerged number 1 among 114 other teams.
  2. When plans change. I think it is even courteous to tell people when things will not go as planned. You would be showing some respect for their time, effort, and energy. If you have a meeting at 9 am but will be running about 10 minutes late, don’t assume that the person can wait. If you can, try to let them know the reason. Whatever it is, do not lie. Avoid sharing the reason if it is too revealing or if you are ashamed of it. Just sincerely apologise. PJT-33 changed the design multiple times even after development. However, this was communicated with justifications. The devs definitely understood.
  3. When you need to make clarifications. One of the worst things that makes group tasks not work is assumptions. If you do not know or are not sure, it is safer to ask than to assume.
  4. When you have some reservations. You shouldn’t really do things that you are not comfortable with. This is why when something does not sit well with you with regard to a group task, you should air it. The trick is to do this with a sincere heart. Telling the group your worries would allow them to see things from your perspective. It could also invite them to re-explain some things you realise you misunderstood. Win-win, right?
  5. When you are sense that others have some reservations. This is tricky because it could just be your imagination. “She did not really sound too excited. Maybe she did not like my idea”, you think. You could ask directly (not confrontational). You could also let it go. Not everyone in a team would agree to a plan immediately. It may grow on them eventually. The clause to this, however, is that you are letting it go for real.
  6. When you end. This is very important for situations that do not have a clear end, like building a website. Sure, it “ends” when you deliver the website to your client. But, what if the client wants a correction today and another next week Friday? Tell people when you want something to stop. Otherwise, they won’t know.
  7. When you have intentions. If you think you have a better plan that was made, that’s absolutely fine. Nevertheless, informing your group members before making changes to your work is very important. You may have missed something. They could learn. It could also prevent conflict later on. Endless possibilities.
  8. When you are done. One of the most frustrating things for me is for someone to leave me hanging. I always appreciate closer. Tell me that you are tired, I’ll understand. Abandoning a task because you lost interest or become busy with other stuff is bearable when you tell other parties involved beforehand. Be nice and courteous enough to do so. You shouldn’t just leave people hanging. Let them know where you stand in a situation.

In future posts, I’ll talk about how and what to communicate

This is 500 words (or more ?)! Talk to you tomorrow!

Leave a Reply

Your email address will not be published. Required fields are marked *

Skip to content