Communication is, by far, one of the most important characteristics of human beings. It all started when a monkey asked “Ugh?” and a second monkey answered “Agh!”. Everything changed in that moment. See, if you think about it, the very fact that you are reading this article is thanks to that very conversation.
According to the dictionary (Google), communication is the imparting or exchanging of information by speaking, writing, or using some other medium. Which means that if I am writing this article I am communicating with you.
And this is exactly what happens in software development, but mostly that’s not enough.
We have all the possible tools available to communicate (chat, commit messages, comments, team meetings, etc.) but, somehow, we fail to do so. Why? I don’t know, but I have some theories.
Developers like to create stuff, not to talk about it
That means we don’t have enough “feature-conversation” (talking about features in a project) within the team outside of formal meetings. The lack of “technology-conversation” (talking about new technology knowledge) is also an issue for the most part. Not to mention the lack of a normal conversation which, well, doesn’t need to be explained.
In a development team this might be one of the causes of delays in projects since, sometimes, a colleague might have the solution of a problem nobody expected to have because nobody ever heard him saying that he was trying some different technology. Not to mention the missed opportunities as someone might come to you to ask about that technology you tested at home and were proud enough to talk about it.
You can address this by talking more about the things you are learning. If possible, check with your team leader the possibility to organize some formal knowledge sharing meeting. I am sure everybody is learning something interesting on their free time, even if it’s a new cake recipe.
There is a lot of misinformation going on
A common problem is when a feature is misinterpreted and implemented in different ways by different people. In the long run, problems like this will cause the team to stop being a productive unit and become just a bunch of people working in the same room.
One of the causes is what I call “selective sharing”, which happens when only some people of the team are chosen to know something relevant to the project. That might not be on purpose but it’s still an issue.
A way to address this issue is to have everything clear from the very beginning: Clear features, clear communication path, clear responsibilities and so on. Also, a clear documentation helps quite a lot as it reduces the already classic “But X told me that 2 weeks ago, I remember”. In this way the volume of misinformation should decrease, reducing the chances of internal conflicts. Or, at least, they will be solved faster.
If someone is working remotely, everybody is working remotely
We always have that person who is working remotely either because decided to take a home office or because he/she is telecommuting. In this case a lot of information is missed due to lack of empathy.
You need to understand that someone (or an entire team) is sitting on the other side of the network and also craving for information. And probably being more productive in one hour more than you are in one entire day.
This can be addressed with a couple of measures:
- Have empathy – You might be the one taking home office and working “alone” some day.
- Make video calls whenever possible – This will always make the ones not sitting in the office an important part of the team.
- Stop the impromptu meetings in the office – Nobody needs them, not even you. Even if you will share the information later. Schedule a video-call.
Of course I didn’t cover everything as I could write a book about it. But I am sure you have a lot to work in your ability to communicate within your team, just like everybody else (me included). This kind of work is a never ending process but it should be done if we want to keep the teams in a healthy state.