We’ve had a lot of success using Trello and Slack in combination for the majority of company communications and project management. However, as it is with all things, defining how, when, and why we use these tools is always a process of constant refinement. This article is meant to share our views and hopefully help other teams struggling with the same issues we had of never-ending streams of notifications and distractions.
Honoring "Deep Work" is Priority Number 1
Cal Newport's Deep Work is required reading for understanding the value and danger of tools like Slack. Here's a quick summary:
Technological advance is eliminating a need for humans to do "shallow" work, which means "deep" work is becoming increasingly valued.
Technology has also provided tools for communication which are faster, richer and more rewarding to the "lizard" part of your brain. These conspire to make modern communication more distracting.
Distraction is antithetical to Deep Work.
Success--both for companies and individuals--depends on finding a way to facilitate deep work while minimizing distractions and their effects.
The Deep Work book covers a personal perspective. The author's interview with Ezra Klein focuses more on how companies might design themselves to cope. It covers the dangers of Slack specifically. Please listen:
Not the Police album—it's great—we're talking about synchronous communication (where you spontaneously ask me a question, and I answer in real-time). After reading Deep Work and listening to the podcast, this should be obvious, but unstructured, synchronous communication is the least effective way to get things done.
If I was doing deep work, I am no longer
If I had a plan for my day, you've changed it
In addition to the time it takes to respond to you, I'll pay an additional 23 minutes during which I'll be unable to focus on my prior task
Those are just the direct effects. The indirect, longer-term effects are worse:
It rewards a lack of planning
It disincentivizes learning (why learn something when the answer is a question away)
It disincentivizes documentation
It limits knowledge to the parties involved. Those not "in the room" don't even get a chance to learn the information.
And finally, synchronous communication is problematic because its inherently unstructured. Listen to the podcast for some context on comparisons between structured and unstructured communication. The gist is that efficient, successful, teams master their business processes by learning and designing systems around the structure that underlies their business. They find ways to put the right information in front of the right people at the right time in ways that aren't disruptive to the doing of the work itself (i.e. in ways that are compatible with Deep Work).
For Culture Foundry, this takes the form of Trello card descriptions, Trello comments, checklists Standard Operating Procedures, Reference Documents like the one this post came out of, and Templates.
Some things you can do to avoid relying on synchronous communication:
Write better, well structured Trello cards
Search. Then ask. Check the internal Playbooks, search Trello, Google Docs and Slack history before re-asking a question that might already be answered elsewhere
Ask. Then document. If you had to ask, make sure the next person doesn't have to. Transfer the answer (or a pointer to it) to the place you looked first.
Write more documentation
Write more code comments
Why Even Use Slack, Then?
So we're almost half way through of this "How to use Slack" article, and pretty much everything so far suggests dropping Slack. Maybe we should, and maybe someday we will. For now, it is the least bad of a number of available communication tools.
Channels are a key function that makes Slack superior to email. Take some time to understand the wisdom of "channelizing" communication, and avoid treating Slack like "fast email".
Channels bind discussions to a particular topic and audience. Frustration with Slack can often be traced to poorly organized channels. Consider whether a narrower or broader topic or a different audience would support communication better, and create a new channel to support it. In the interest of brainstorming, here are some potential channel names that reflect patterns used in other companies:
Areas of interest (e.g. #horse-racing, #cms-research)
Severity channels (e.g. #incidents, #emergencies)
Client sub-channels (e.g. #ClientA-discussion and #ClientB-notifications)
Micro-project channels (e.g. #ClientC-launch)
Channels are more efficient than email because they provide implicit context. In the #acme channel, the phrase "this week's meeting," is all you need to say, and everyone will know you're talking about the Thursday meeting with Acme Corp. You might configure different notification settings for #emergencies than for #newco-meeting-notes.
They're also efficient because they provide a way to limit the audience for communication. Not working on #acme? Don't join that channel, and you won't be distracted by its unread status indicator.
Finally, channels provide a permanent, chronological record on a particular topic. Be aware of this in your communication:
When replying to a question, use the Threads feature to keep your response linked to the original message. Don't "cross-talk" against other intermediate messages.
Use the /me feature to insert date-stamped status updates the team should be aware of (e.g. "/me is now working on the rocket ship feature"). This carries a subtle cue that you're not looking for feedback or a response, just FYI-ing the team about something. David Marquet describes this as the "thinking out loud" pattern in Turn the Ship Around!.
Slack provides a small text entry box which results in brevity and interactivity. Unlike in memos, emails, or docs, these short messages encourage collaborative conversation.
Don't abuse the text entry area by copy-pasting email text or the raw text of a web page. Link or excerpt instead. Keep messages focused. For example, consider the post:
"What do you think about the home page design? And I think the About Us Page sucks."
It's the start of 2 separate threads. At a minimum make them two separate posts so that people can respond in a separate thread off of each. Or… you could post about the home page, and let that discussion run its course before bringing up the About Us page. Even better, consider moving those to 2 Trello Cards and soliciting feedback there.
For client channels, use the channel's topic description (the little message next to the channel title) to reflect the status of the dev environment.
For example, when a developer sets up Acme's dev server to test a new Facebook share button, he changes the topic message to "acme.dev.net: owned by all-star developer’s name : Facebook Share Feature." When another developer needs to know if it's OK to overwrite the dev database, they know who to ask without asking the whole room.
Treat a private message with the same care you would use when approaching a colleague's closed office door. Is what you're asking urgent and important enough to interrupt their work, regardless of what they're currently doing? If not… don't use a private message. Avoid @tagging them in a #channel. Put it on a Trello card following the appropriate guidelines and allow it to arrive at their attention when they are prepared for it.
Sometimes real-time conversation is required, or a user needs to be alerted to a message. This is where notifications come in. Here's an overview of what's available order of increasing shoutiness:
Just posting a message. People will see it when they see it. They'll respond as time permits. This should always be your default.
@here send a notifications to only the members in the current channel who are online right now. This is by far the friendliest and preferred way to ping a channel, as it doesn’t disturb people who aren't working right now. If you need an immediate response, but don't want to interrupt someone's lunch to get it, use this.
@user sends a notification to that individual user, whether they are online right now or not. This should be used when you need them to respond right now, but please take care when using it because if they are offline they'll be interrupted wherever they are by an email or phone notification. During the workday, this can be used to draw attention to a message, but respect the possibility that you may be interrupting deep work.
@channel sends a notification all members of the current channel, whether they are online or not right now.
@all and @everyone sends a notification all Slack team members in all channels, whether they are online or not. Use @channel, @all, @everyone only for emergencies.
Mobile Notifications / Do Not Disturb
You can set up your mobile device so that you are alerted to urgent issues during business hours. Slack's automatic "Do Not Disturb" feature allows automatic disabling of those alerts after hours. Set it appropriate to your time zone. Click cmd-, on a Mac, or open your Slack preferences to configure.
Different than Do Not Disturb, this feature lets you temporarily "snooze" your notifications. You'll receive no alert for a certain timeframe, but they'll all be queued up for delivery when your snooze ends.
People who attempt to private message you will be notified that you are snoozing notifications and that delivery of their message will be delayed.
This feature could also be called the "deep work" button. Everyone should use this feature when diving into a deep work session.
Next to each person's name in your sidebar is a presence indicator. There are 3 states you should be aware of:
A filled circle indicates the person is currently online on at least one device.
A filled circle with a superscript "z" indicates they are online, but are either snoozing notifications or in Do Not Disturb mode.
An empty circle indicates the person is currently offline. Be aware that they will receive a push notification to their phone if you private message them or @user-tag them.
Always check these indicators before sending a private message or @user-tagging the person. Be especially aware when you are triggering a notification to someone who is currently offline, but not in Do Not Disturb mode. Are they at a doctor's appointment? Do you really want to beep their phone right now?
These are the little icons you can attach below a Slack message. Consider suggesting that people use these when soliciting something like a vote (e.g. "React with :thumbsup: or :thumbsdown: to cast your vote"). Slack shows a numeric indicator next to the reaction emoji for each person who used it. You can use the 'shift-cmd-\' shortcut on a Mac to bring up the reaction picker.
Slack has excellent and easy-to-use formatting that's triggered by special characters. These features make channel histories much more scannable.
Be Careful with Long URLs
Unfortunately, Slack doesn't provide a way to link to something using anything other than the URL itself as a link. With certain services (including Trello) that use excessively-long URLs, pasting these URLs into Slack messages can generate excessive noise that makes comprehension and scanning difficult.
Consider using a service like Bit.ly to shorten URLs when pasting into Slack. But remember, using Bit.ly obfuscates the eventual URL, so add context to your message, and don’t use if not necessary.
For Trello cards, consider using the "short" URL for cards (available in the "Share and more…" menu). If you're mentioning a single card, and starting a long discussion about it, the full URL can sometimes be helpful because it includes the card's title within the URL. If you're iterating a list of the "10 important cards for launch", then pasting the full noisy URL for each of the 10 is a bad idea. In other words, use judgment about when a short URL is needed.
The #random Channel
It's our digital water cooler. If your team has a #random channel, make sure you turn off notifications, as its core purpose is for the sharing of digital distractions.
The #general Channel
If #random is our break room, the #general channel is our lobby. Keep in mind when posting that the audience in this channel is the entire company.
Avoid starting client-specific discussions here because it takes them out of the sequential history that a #client-name channel provides. Even urgent issues and emergencies should be scoped to a client-specific channel for this reason. "Is this a regression?" When was the last deploy? Who changed what last?" Becomes easily answered by simply scrolling up in the client channel. In #general… there's no context that might help identify a root cause.
Be cautious with opening a 1-on-1 discussion by @tagging someone in #general. In real life this would be like walking to the middle of a cubicle room and yelling for someone to come have a loud conversation there with you for all to hear. Probably not the effect you're intending....
These topics are what we’ve found to be appropriate in #general:
Out-of-office schedule updates (e.g. "I'm on vacation on Thursday and Friday")
Discussions about process (e.g. "I propose we cut the Ready for Dev limit in half. What do you all think?")
Site launch announcements (site-specific, but the whole point is to make sure the whole company knows)
Company wide announcements
Industry news which affects the whole team (post links to articles you think everyone needs to read in #general. The rest should go in #random).
In conclusion, Slack might be a source of constant distraction and even frustration for you or your co-workers, but by implementing some general guidelines and thinking in different ways about how we “slack”, can make it a valuable resource for knowledge sharing and team organization. These tips are just some of the things we’ve found that works for us as a company especially with many remote employees. It has also helped us reassess urgency levels, increase the idea of self-learning, and noise reduction.