The modern work environment is heavily reliant on written and asynchronous communication. Even more so in a remote setting. Employed correctly, effective communication can be an amazing enabler for your team to work effective and fast. Conversely, this implies that ineffective communication can kill your team’s productivity.

Tools like Slack, Teams, Discord, etc. allow you to have shared, purpose-driven channels. These tools play host to where we find most, if not all, of our crucial communication taking place. Let’s see how ineffective communication can be to our detriment.

Take, as an example, an organisation named Team Magnanimous with the following Slack setup:

# general
# watercooler
# epic-project
# project-ml
⁃ Sarah (Project Manager)
⁃ Lucy (Tech Lead)
⁃ Dave (Designer)
⁃ Pete (Software Developer)

Team Magnanimous, consisting of yourself (a dev, for this sake) with Sarah (PM), Lucy (TL), Dave (Designer), and Pete (Dev) is doing projects epic and ml . Channels general and watercooler are aimed at organisational announcements and off-topic chats and banter respectively.

Team Magnanimous wants to move fast and deliver Minimum Viable Products (MVPs) at a strong pace. Let's take a look at some examples of how the manner in which they discuss certain topics can impact this goal.

In other words, here are some of the reasons why it’s good practice to have discussions in a public channel, rather than in private Direct Messages (DMs).

Consider the following examples:

Shared context

Pete (one of our devs) and yourself (also a dev) have come across a bug in _project-ml_. For some reason, it sometimes happen that when a user uploads a picture of a dog, our Machine Learning (ML) system classifies it as a cow.

Digging through the data, you and Pete realise that this only happens when the affected user’s date of birth is before 01/01/1970. Why this happens, is a mystery to you and Pete*. You’ve checked the inputs to the ML model, and they all seem good. The dates for these users are stored as expected. Everything looks good.*

After half a day of looking into this, you now decide to go to Lucy (our TL) for her wisdom. After explaining the problem, she first dives into the data and also finds the correlation between DoB and the affected users. She now digs through the code, only to see that the ML inputs look good, and that the dates are stored as expected. This also takes Lucy half a day to do.

From there, however, Lucy notices some rogue test code that overrides “dog” to “cow” when the user’s DoB is before 1970.

Had Pete and yourself had this conversation in a public space (ideally the project-ml channel), where Lucy could review it, she would’ve been less likely to have to also spend half a day coming to the same conclusions. Instead, she could’ve confirmed your methods of finding these correlations, trusted it, and then immediately looked further.

Building context is a time-costly thing to do. It’s therefore always advantageous to share the steps to building the context so that someone else can also gain the context and contribute to the solution earlier.

Reviewable knowledge

Sarah (our PM) and Dave (our designer) are busy reconsidering the designs for _epic-project_ in a DM. ==User research has shown that if they were to add some confetti animations in between button clicks, this will increase the level of epicness perceived by the users.== Having agreed upon this, Dave heads off to conjure some incredible confetti animations. This takes him a day to do.

The following day, during stand up, Dave presents this to the rest of the team. Lucy (TL) is not at all happy about this, though, because she knows that neither her nor any of her devs have ever worked with animations before. Besides, they are done implementing all of Dave’s other designs, and are ready to implement the remainder of the flow so that they can ship soon.

From this example, we now have the situation where Lucy and her devs are essentially blocked from progressing toward their goal of shipping an MVP. No doubt, Lucy and her team can read up and learn how to implement these designed animations. However, had the initial conversation between Sarah and Dave happened in the public epic-project channel, where Lucy could see it happening, she could’ve stepped in and mentioned the lack of technical experience to implement this, and further reported on the good progress that she and her devs are making.

This would’ve re-aligned the priorities and expectations of Sarah and Dave, and Dave could’ve more effectively spent his time designing the remaining part of the flow, allowing Lucy and her devs to continue working effectively the following day.

This applies to other scenarios as well:

• Two devs deciding upon a flawed approach to solving a problem, where a third dev could’ve pointed out the flaw early.
• PM and Designer discussing a technically complicated flow, where a dev could point this out early.
• Designer and TL discussing a short-cut in the flow, where the PM could point out early that the part of the flow that’s being cut out is critical for some metric.

Clear history

Dave (designer) and Pete (dev) are busy testing a feature that Pete built, wanting to be sure that it all looks good and behaves in the way that Dave envisioned when he drew up his designs.

During Dave’s testing, his app crashes. He lets Pete know in a DM, who makes a note of it, along with the other notes that he has made throughout their testing of small things that needs to get fixed. Pete is on track to have the feature ready to be shipped in 2 days’ time.

The following day, however, Pete wakes up with a major ailment and takes the day off. Lucy (our TL) sees that Pete has made good progress on completing the feature and marks it as ready to be released.

Here we can see that Lucy is about to ship a feature that still has a crash in some part of the flow. If Pete and Dave discussed the crash in a public channel, instead of their DMs, Lucy would’ve been able to pick up on this crash and would’ve been able to then investigate it to get it fixed before shipping, or delay the shipping of the feature because of it.

In this case, it is easy to see how open communications can serve as a clear history of events that make it easy for other team members to pick up.

Conclusion

By all means, rightfully keep your private conversations in DMs (where they belong). But if you’re having a conversation about anything that is related to what your team is working on, take a second to ask yourself whether it would benefit the team by having this conversation in an open, shared channel.

If you find yourself forgetting to do this after a discussion has already taken place, then be sure to share the conclusion publicly and present this conclusion as being open to discussion. In fact, sharing an explicit conclusion is always helpful even if the conversation has taken place publicly!

If you follow this one rule, I’m sure you’ll see the number of miscommunications in your team reduce and the effectiveness of your team increase.