We are a fully remote company, distributed on several timezones, for quite a few years now. While lately there is a lot of discussion happening around remoteness, collaboration, and productivity, we advocate for a long time that good collaboration can happen only with good communication, meaning, in a remote environment, written communication.
Still, it is good, from time to time, to get back to basics and rehearse what we do in our day-by-day work, just to build muscle memory. Here we share some tips for getting better at asynchronous communication on (but not only) Slack.
Are you looking for exciting engineering challenges in a remote first environment?
Is Slack asynchronous or not?
Do you use Slack in your day by day? Try to run this poll, you may find unexpected results.
We did that and the results showed an interesting distribution: Slack is perceived as an asynchronous tool, but with different response times. While there isn’t a right answer, make it explicit to set the right expectations and avoid people hanging in for an answer which may arrive later.
Things to keep in mind
Remote is Hard: working remotely and asynchronously is challenging: it requires being careful when communicating. As some research suggest, written messages are easily misunderstood than face-to-face communication so being explicit and a bit more verbose could help convey our message. Also, emojis are proven to be a good quick way to set the tone of a message (though in some cases they can be misenterpreted).
There are no silly questions: don’t be afraid to ask for something, remember that a question answered in public can help many people. From a company point of view, this also means investing time and energy to foster an environment where people feel free to do that without being judged.
Assume good intentions: start by assuming that everyone is doing the best they can, given what they know, their skill and abilities, and the current situation (sounds familiar?)
Principles, Tips and Tricks
Overcommunicate: don’t be afraid of writing too much, it won’t hurt anyone. The mantra should be “public by default”. Public messages are a form of shared documentation:
- they allow people to catch up in an async fashion
- a publicly answered question can help many people
- a public question can receive multiple answer, generating options
We do have, for instance, public channels for every team (Curiosity, Delta, Infra, Opportunity, … more on that later :-)) where everyone can hop in, see what’s going on and partecipate in discussions. Plus, there are some thematic channels, like - #releases: where a message is being posted every time something is released
- #tech-talks: where we communicate about out internal talks agenda
- #goodreads: where we share articles, books, we think they are worth reading
and of course some absolutely needed channels like #gaming, #music, #photos, #nerd which are self well, explanatory :-).
Cmd-F is one of our best friend to search inside channels for informations
Keep Notification under control: while being chatter is good, notifications and Fear Of Missing Out (FOMO) is something to be aware of. Slack, but notifications in general, can become quite noisy and distracting, draining our focus and mental energy from meaningful work. Fortunately, there are plenty of things that can be done to prevent this
- Do not disturb mode. Try it: /dnd “silence is gold” and disable it with /dnd off
- Google Calendar integration for updating your status accordingly
- Custom notification schedule, to define blocks of non interrupted work
Enter a channel and mute it: if you are interested in what is talked about without the hassle of notifications you can join a channel and mute it. You will be notified only if directly mentioned.
Osx Monterey has a focus app that allows you to disable notifications based on
- time, ie “no notification every day from 9 to 11”
- location, ie: “no notification where I am at home”
- app, ie: “no notifications when I am using VS Code”
Who What When Where Why: quite an old trick, when posting a request try to answer these 5 questions
- Who is supposed to answer this? Slack mentions are a good way to make this explicit, but don’t abuse @here and @channel, ie: “@infra would you mind… “
- What you want to be done, ie: “running the script X”
- Where: on which system/environment/whatever, ie: “on production?”
- Why we need that? It gives context and helps framing the request in a bigger picture. ie: “…it is needed to fix Y”
- When do you expect this to be done. ie: “it would be great to have it by the end of the day, but also tomorrow is fine”
Hey @infra would you mind running the script X on production? It is needed to fix Y. It would be great to have it by the end of the day, but also tomorrow is fine
This helps who’s receiving the request dealing with it. Don’t expect that something will be done right now.
Post a meeting recap: It is a good practice to end a meeting by posting a quick recap. It helps those who attended to ensure they are on the same page and make the decisions visible to those who did not.
Gather feedback async: When looking for feedback from a wide audience do it in an asynchronous, time-boxed fashion. Try to avoid posing open questions: enumerate all the possible options and exploit reactions to gather feedback in an unambiguous way.
Also, images and short videos are a quick way to give context. OsX preview tool is all you need to do that (Cmd-Shift+5 to record screen, Cmd-Shift+4 to screenshot)
Search, then ask: try a quick search on the channels before asking, the answer could be there :-). Do you know that Slack is an acronym for Searchable Log of All Communication and Knowledge?
Have a private space: sometimes public channels can be a bit intimidating, regardless of the effort to create a safe and welcoming environment. If people do need private spaces for chitchatting and coordinating there is nothing wrong with that. Keep an eye on discussions and when they become important suggest to move them to a public channel
It is not only about Slack
Slack is just one of the many ways communication happens. Also
- Pull requests and code reviews
- Incident Reporting messages
- Post Mortem documents
… and the good old emails are a form of asynchronous communication. For sure several of the principles highlighted here are applicable
also to these channels, and some of them will be explored in the next posts. See ya!