Communication Breakdown - 5 great ways to be misunderstood
We’ve all been there - you said something wrong, now you long for yesterday. There was an awkward silence and it felt like a scene from The Office.
The good news is that nobody’s writing our lines to make us look silly - we write them ourselves. And yes, this is the good news. Communicating well is not a personality trait, it’s a skill and as such it can be trained and improved. It takes time and attention as with other skills but thankfully you get better at it. In the meantime though, mistakes will be made. Let’s cringe together, reminiscing about some of the not so obvious but universal ones.
1. Lack of communication
In my experience, this is the most common problem and I could stop at it really. There are countless reasons for not communicating something: “I thought it was obvious”, “I was afraid to ask”, “I didn’t have time”, “I didn’t realise it was important”. This is why communication is not easy - we prefer to stay mute because it feels easier at the time. However, even when it seems daunting, it’s so much easier to handle things straight away than to wait for them to escalate.
There’s usually this feeling “Maybe they won’t notice, maybe it’s not that important” - if you get it, it’s a wonderful indication that indeed, they WILL and yes, it IS. For starters, YOU did notice that it might be an issue. Think about the most common situations when you struggle to communicate, it will be easier to speak up the next time when you spot them. If it’s usually about the estimations (when you already know you won’t make it in time but say nothing), then next time try to push yourself to talk before the actual deadline apocalypse. I still struggle with this sometimes but realising it’s a problem is already a step forward.
Another reason might be that you just didn’t pay enough attention to know what and when to say. It happens and it’s ok, unless you spend the whole meeting scrolling through cat memes.
Again, admitting to drifting off for a while and asking to repeat the last sentence (just not the whole meeting because cat memes) is better than staying mute, praying to not be asked about anything.
And to reassure you - over communication is never a big mistake that escalates. People can be mildly annoyed or amused, but never furious. As opposed to not letting them know at all.
2. “Debugging the endpoint that is parsing the string requests which is also known as...” parklife!
It’s good to know your crowd. You wouldn’t go into details of AWS cloud formation templates on your first date (that’s a known faux-pas, leave it for the second date). Getting all technical at a high level feature discussion would not bring the positive attention it otherwise might, for example during the Sprint planning or devs meeting. Think about what’s interesting and useful to know for the person you talk to. Even though it might seem that fireworks of technical terms will show your knowledge, people feel safer if they actually understand what’s going on and can trust you.
3. “This feature makes no sense”
Also known as lecturing the client. If you know the domain well, thoughtful advice is usually welcomed as that’s why you’re here for probably. However, never tell the users what they “really” need, contradicting their requirements, even when you have the best intentions. Help them think about their expectations but do not dictate your ideas upfront. It’s good to ask a lot of questions if something doesn’t feel right, making sure you understand it correctly before criticising. Sometimes asking the right questions will be enough to make your point. If you’re still unsure, announcing the fact that your point of view might differ from the client’s but leaving the details until you figure out how to present them might be a good idea.
4. “No worries if not!”
This is an issue of a bit different character. While being kind is crucial, too much humble courtesy can change the message you wish to convey. Something important can be perceived as much less serious, because you painted it as such. In general, think twice before using phrases like “no worries if not”, “it’s not a problem at all” - is it not, really? If it’s a small issue or you can tackle something in a breeze, go ahead. If something is crucial or you will spend a night over fixing something, be honest about it. Do not put yourself in the lost position from the start. Finding a balance between politeness and assertiveness is the key.
source: Natalya Lobanova,* New Yorker magazine*
5. “no”
It’s when you communicate but in a way a grumpy old man would. For “Do you know when I can expect this feature to be finished?” he’d answer “no”, for “Will I be able to test this on Friday?” he’d answer “don’t know”. It’s good to answer clearly and honestly, however adding some more information is how you show appreciation and understanding to the person you are talking to. Otherwise you may come across as someone who doesn’t care, even if you actually do. Always think about what you would like to know in such situations. When your car breaks down and a mechanic is working on it, you would appreciate knowing how serious the fix will be and what is currently going on with your precious car.
Which brings us to...
A bonus track about empathy
When Kent Beck tweeted back in 2015 that “the *craft* programming begins with empathy, not formatting or languages or tools or algorithms or data structures” it struck a note. Some people agreed with passion, while others felt there’s something gimmicky about it, because what about hard work and discipline, and a bunch of other crucial elements. However, since then the idea of empathy as an important skill for the programmers has been explored and it is much less controversial now.
For some people empathy comes naturally. Equipped with other supporting personality traits, they intuitively feel other people’s emotions without thinking about it too much. For others it can be more challenging. It doesn’t help that most of us haven't been taught empathy at school the way we were taught math, so we didn’t think of it as something one should learn. However this is exactly the case - regardless of the intuitive, let’s call it in-born empathy, empathy as such is actually a skill that we can and should practice. If not for anything else, then at least for the sake of the systems that we create.
We all have good times and bad times, I know I’ve had my share struggling with all of the issues from this post now and then. It’s impossible to be your open and positive self 24/7 but trying your best is the goal.
Both empathy and communication can and should be practised. They’re not elusive parts of one’s character - they are skills. Skills that become increasingly important in the way developers and other IT professionals work. Practice them any way you can. No worries if not! But please do ;)
