This is the fourth post in a series about asynchronous collaboration. By asynchronous, I mean that people on the team don’t always work at the exact same time. It’s common on distributed teams, especially across time zones. You can see all the posts so far on this series right here.
In the previous posts, I shared how I emphasize shared context in pull requests and commit messages. In this post, I talk about sharing and organizing context in interpersonal conversations over Slack, Hipchat, or IRC.
This is not a comprehensive guide to comportment on group messaging apps. Instead, we’ll focus specifically on three useful practices for the asynchronous, remote conversations common to distributed teams.
Useful Practice #1: Channels for Conversations
In this post of my last series about remote work, we discussed the issue of sharing context among colocated employees. Consider the following scenario:
“You and your colleague, Nina, are working on a project together. Roger, who oversees the project, stops by your desk with a speculative question about that project.
Nina isn’t around right now, but Roger just wanted to ask you one thing real quick, so the two of you start talking. Inadvertently, you dive into a deeper discussion, and maybe some sort of half-decision is reached.
At this point, you both know: really, Nina should be involved in this. So you set up a meeting later for the three of you. In that meeting, you now need to rehash the conversation that you and Roger had to bring Nina up to speed.
For you and Roger, this part of the meeting is repetitive: you’re spending double time doing the same thing twice at work. Meanwhile, for Nina, the beginning of this meeting is hammering home for her that a whole conversation happened about a project in her purview while she was out of the room getting coffee or something. She didn’t get a say in any of this buildup part of the conversation, and now she’ll need to proffer an opinion with less time and consideration than the rest of you had to ponder this question.”
This scenario centers a colocated team, but the same thing can happen on a distributed team. This sort of accidental decision-making can easily happen in a private message on slack or similar.
Enter the channel:
You can make public channels for members to join and leave at will, and you can also make private channels to which you add and remove people. When I’m collaborating asynchronously with people about an ongoing discussion, even if it’s just a few people, I make a channel for the discussion.
I can add the people who should be involved in the discussion, and they can all see the history in the channel of what everyone has said before about this topic. Had you and Roger in the example above defaulted to a channel, Nina could have returned to her desk and participated asynchronously in the discussion. The three of you may not even need a meeting! But if you you still needed to meet, you would all enter the meeting on the same page—laying the foundation for a more productive meeting.
Useful Practice #2: Threads
We have very few useful tools for discussing multiple topics in the context of a single conversation.
Take group emails. Have you ever muted a group email? Why did you mute it? Maybe too many people were responding with some relatively repetitive message like “Congrats!” Or maybe 15 people were discussing when to meet, and you didn’t need to hear everyone’s personal schedules; you just needed to know the end result.
What’s worse than an email thread that you have to mute? An email thread that you want to mute, but you can’t. Suppose 6 people are asynchronously discussing 3 different things on the same email thread, and one of those 3 things is important to you. First of all, the UI of email threads can make it really hard to follow who said what, and in what order. Second of all, you now have to sift through a bunch of extraneous information to find the part you need.
That’s what meetings are for, right? They solve this email problem! Wrong. In a meeting, we discuss a list of topics synchronously. Suppose we’re brainstorming ideas on one topic. What if we finish brainstorming, and then you have an idea later in the meeting? The larger the meeting, the harder it is to drag the discussion back to the brainstorming.
You know what’s even more common? Someone with a low caucus score has an idea, but everybody else talks over them. Then someone with a high caucus score suggests we all move on, and now the person with the low caucus score feels dejected, plus the brainstorming session (as well as all future ones where this person feels too dejected to even try to participate) are poorer that person’s ideas.
Enter threading:
If you have several sub-conversations happening in a single channel, you can organize those conversations by encouraging participants to respond to messages in threads. Here’s a screenshot of a thread I started in Slack:
Here, I put a message in the channel, then replied to my own message with a second message, and folks took that cue to respond to my idea as replies to the original message, rather than typing directly into the channel. When you have multiple threads in the same channel, it looks like this:
Here we have a thread that I started, which has garnered four replies. A colleague has started another thread below mine, and their thread has so far garnered 3 replies. (I blurred contributions by anyone who wasn’t me, to protect everybody’s privacy).
Threads allow us to organize, and contribute to, asynchronous sub-conversations within a larger channel.
Useful Practice #2: Emoji Responses
If you’re on a messaging platform like slack, you might be familiar with the little emojis that you can add as reactions to other people’s posts:
They’re a great alternative to those long aforementioned group emails where 15 people respond with a terse “Congratulations!”
I also think there are particular emoji uses that make asynchronous messaging channels friendlier and more productive places. They are:
- A consolation emoji. That’s what you’re seeing in the image above, where 26 people responded to my despondence with a teddy bear hug reactions. These types of emojis reduce the friction of humanizing the message experience.
- A gratitude emoji. I add some kind of “Thank you” response to any slack where I’m an admin. This creates an easy route, and an expectation, to appreciate one another’s work.
- An “I’ve seen this” emoji. Mostly, Slack communities I am in have chosen a set of eyeballs for this one. It’s great for messages where someone might need to think, or do some other blocking task, before adequately responding. The response signals “I have seen this and I want you to know I am thinking about it.”
Conclusion
Distributed teams benefit from sharing and organizing context in interpersonal conversations over Slack, Hipchat, or IRC. So we’ve discussed three useful practices for the asynchronous, remote conversations.
First, we put conversations in channels, rather than DMs, to make it easier to share history and context among multiple team members in an asynchronous way.
Next, we use threads to organize multiple trains of thought more productively than we can on an e-mail chain or even in a colocated meeting.
Finally, we add some quick reactions to humanize our remote, asynchronous meeting space by creating options and expectations around offering sympathy, expressing gratitude, and signaling that we’re listening while creating space to think about how to respond.
If you liked this piece, you might also like:
The rest of the Remote Work Category (including a long series on working from multiple locations)
This post on contributing to open source software (many OS teams are distributed)
Michael Lopp’s book on managing humans (or, if you don’t have time for that, my blog post on the book)