Most problems in project management are, in fact, communication problems. How we communicate makes an enormous impact on our work. In this post, we talk about one of the best strategies for improving communication in a team: making it open.
Over the years, we at ivelum have developed a work culture that relies on open communication, an approach borrowed from open-source communities. We prefer to publicly discuss most work questions so any team member can follow the discussion and participate if they'd like. It can happen in chat channels, a project management system, or open video meetings, which anyone could join.
We discourage work discussions in private talks. This is not to say that we avoid direct communication entirely; of course, there's no replacement for it for sensitive topics. However, there's nothing sensitive in most work talks, and we prefer to have them in the open.
We're not the only company that practices open communication. However, it doesn't seem to be very common. Most companies follow a more traditional approach. In most companies, if Alice has a question for Bob, she is likely to ask Bob directly rather than posting a question in a group team chat. At ivelum, we do the opposite. Many folks who join our teams notice that we communicate differently from how they used to do it at their previous job. We explain why and try our best to ensure a smooth transition.
Simple: it boosts team performance - a lot. Of course, it takes some adaptation effort for new team members, but the effect is so significant that it soon pays off.
At first, it may seem that when all work communication is public, it might cause a lot of distraction. In reality, the opposite is true because of how chats work. Slack, which we use, and other chat platforms (Discord, MS Teams, Mattermost, etc.) are configured by default like so:
As a result, when you send a direct message, you distract your colleague, but when you post a message in a group chat, you don't distract them (unless you mention someone explicitly via @).
From our experience, the vast majority of work questions are not so urgent that they require an immediate response. Most topics can be discussed asynchronously – you post a question when you have time, and your teammates will respond when they have time. It greatly helps to minimize distractions, which is especially important for developers. To be productive with code, they need prolonged periods of focused work.
Okay, reducing distractions is all well and good, but why would people in a team chat browse through lots of messages which are not addressed to them directly? Well, in practice this information is actually very useful:
Finally, proper organization of chat channels reduces the risk of information overload to a minimum. Each chat channel can be dedicated to a particular project or a team, and people follow only channels in which they're interested.
Even when teams agree that they may benefit from open communication, they sometimes don't rush to implement it in practice.
One obstacle is that people can be shy. Many are reluctant to talk in public because they're not used to it and don't feel comfortable doing it. They may think they're asking a trivial question and don't want to attract too much attention to it. The best thing we could do to help with that is to be friendly and welcoming. No sarcasm, and never treating any questions as "silly." A positive atmosphere is crucial for learning, and continuous learning is vital for team success.
Another common problem is too much focus on secrecy. Open communication can be perceived as a risk of information leaks, and in some cases, it can be a risk indeed. However, by imposing communication barriers, companies not only mitigate these risks but also greatly harm their productivity. Even one of the most secretive companies – Apple – is now reconsidering its practices because the downsides are so significant.
There are certain things that the most productive teams do differently. Of course, open communication is not a silver bullet that magically solves all potential team problems, but this is certainly a big one.
Numerous studies show that in one or other form, communication problems are behind most of the reasons why IT projects fail. Involving themselves in frictionless team communication is arguably the best thing a team leader can do, as the rest of their team members will most likely follow suit and make it a habit.