You know those recipe websites filled mostly with the backstory of how they discovered this amazing cookie recipe that changes their lives, and what joy it brings their three free-spirited, yet precocious children every time they make the cookies? This is kind of like that, so scroll down to “The How” if you don’t care about “The Why”.
I love Cal Newport‘s ideas about deep work. He writes a lot about how to protect your time so that you focus for stretches measured in hours instead of minutes, with no distraction. For Joel Spolsky the same concept was “getting in the zone”:
We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.from “Where do These People Get Their (Unoriginal) Ideas?“
Joel followed that up by explaining how task switching is bad, Jeff Atwood echoed him, Rands showed us how he kept distractions at bay and years later, after Slack arrived on the scene making this problem worse, how he used Slack. It being such an important topic — especially with the boom of remote work making Slack even more common — this is my version of that Rands article, with a few years of more Slacking under the belt.
For programmers, standard Slack policy should pretty simple, flowing out of the principle of guarding “the zone” fiercely:
- Turn off all notifications, except for when you’re being specifically @ mentioned
- Specific mentions aside, only read Slack during your downtime — between meetings or while your VM is rebooting or whatever.
- Don’t feel like you have to read everything in all the channels. Start with your favorite channels, and go as far as your downtime will let you.
For engineering leaders though, especially manager- and architect-types, it’s not so simple. The broader your scope is in the organization, the more pertinent info you will learn via Slack discussions, and the more value there is in being in a lot of different channels, so you can glean stuff like team Aardvark being in trouble because they’ve been complaining about their infrastructure daily for a week; or you can quickly unblock Bob who can’t remember where the functional spec is for the login screen, or focus a search API design discussion between Carol and Dave, and then build rapport with the other foodies in
At the bottom of it all, underneath all of the turtles, programming is about communication between people. The source code isn’t for the processor, but for other programmers. And every successful team is a well-oiled communication machine. The best teams are the ones that have shorthand and can finish each others sentences. You just know that a team like that — and full of smart people — is going to be off the charts with productivity.
So as an engineering leader, possibly the single most important job we have is to do everything in our power to facilitate effective communication. Which these days, includes being a Slack Jedi. But, we also need to get some actual tasks done, so we can’t let it take over the whole day (at least not every day), which means there’s a balance to be found. Below, is how I found that balance.
I’ll caveat these 10 weird tricks with the fact that this is what works for me, in my situations so far, and while your mileage will probably vary, at least some of this might be helpful. So:
- Turn off all notification types except for the badge icon. This is specific to the MacOS desktop app, but I have it set to never make a sound, to never pop anything up, to never bounce anything, to never do anything at all, for any reason, other than make the badge counter appear over the app icon. That way, I can get in the zone when I need to, and won’t get distracted by Slack, but can still glance at it, once in a while, at opportune moments to make sure it doesn’t have 57 urgent messages for me.
- Low barrier to enter channels. I’ll enter most channels as I come across them, because in the bad case, I don’t read them and in the worst case, I leave.
- Slackbot helpfully reminds you about channels you might wanna leave, also.
- Low barrier to create channels. Whenever a topic starts getting enough airtime, or when there’s any other reason for it to have a dedicated channel, I create that channel. The more the merrier.
- You can go overboard, but as long as the reason for the channel is clear, go ahead and create it. You can always archive it later if it was a mistake.
- Channels are free and an organized Slack is a happy Slack, because it is way easier to find that important conversation about search API design if you know it happened in
- If you actively want to foster conversation in a channel, consider making it private. People feel safer talking in them, and the Slack stats I’ve seen bear out the fact that the large majority of messages happen in private channels or DMs.
- Organize the channels in groups and make them disappear. This is a fairly new feature, I think from late 2020, but you can create channel groups in the sidebar, order the groups however you want and for each group, show all the channels or just the unread ones. You can also order the channels within the group in different ways.
- I order them by priority within each group and show just the unread ones.
- My groups are about related topics, ordered by how important they are to my role: my team’s channels and DMs in the first group, various dev channels in the second, then management channels, field support, water cooler, etc
- Embrace speed reading. The human brain is great at patterns, and you can quickly pick up the importance of a conversation from some key signals like what channel it’s in, who the participants are, how long the conversation goes for, key words being repeated, emojis being used, etc.
- In some channels, like ones about nascent projects or downtimes, I read every word carefully — but that’s very much the minority.
- For the majority, I scroll through at a good speed, slowing down only when my spidey sense tells me I’m speeding through something worthwhile. It works well — false negatives are rare.
- Embrace emojis. Not only do they make conversations fun, but they also convey tone (which is super important) and, as reactions to messages, they serve as pithy replies that add value to the conversation without also adding volume to it.
- e.g., using a check mark to indicate that you read something without indicating judgement, or a dart that their message was right on the money, or an up arrow as an upvote — they’re small, very helpful gestures that significantly improve the conversation.
- Use reminders. When I do go into Slack, I like to at least clear all my mentions that turn channels red. But sometimes I can’t actually service a message. Maybe that’s because it’s asking a question I have to research, and I’m in the middle of something. Or I want to make sure that I follow up on a conversation after my current meeting. Or I got an action item in that meeting that I need to do tomorrow morning. I use reminders for all of that.
- Most of my reminders are set on existing messages that I need to do something about
- Some of them, I create with the
- All of them, I snooze extensively until the time is right to work on them
- Don’t use threads. It’s quite possibly the worst feature in Slack. Some people love them, but don’t be those people. Terrible UX aside, all threads are is a way to hide conversations for no good reason. If you want to read every word in a channel, and you’ve read them all, but then Ethan decides to start a thread off of someone’s message 50 messages up, guess what? You’ll never even know.
- Some people use threads because they came too late upon a conversation that’s scrolled away, and want to continue it; there is a better way: share the message into the same channel, and that posts it at the bottom, with your comment attached.
- “But I don’t want to bother everyone in the channel with my thread”. The conversation either belongs in the channel, or it doesn’t. If it doesn’t, create another channel or group DM. But there’s no reason to hide it.
- Nudge people toward the proper channels. Most people are trying to get their job done and aren’t so worried about keeping Slack organized, so when they start a conversation about lunch in
#dev-breakfast, it’s probably because they didn’t even know
#dev-lunchexisted, or because they had been talking about brunch and it morphed into lunch.
- The point being that, as is generally the case, people don’t intend to break the rules and usually just make mistakes.
- I, as Slack Jedi, have to minimize the chance of mistakes by establishing good channel-naming conventions and keeping topics narrow, but when mistakes do happen, it’s not the end of the world, and an innocent mention that the lunch channel exists is normally the only thing that needs to be done.
- Be super nice and soft about it, because creating anxiety about the proper channels is kind of antithetical, since it then stifles communication.
- Try to mark everything read by the end of the day. I don’t always clear my email inbox every day (or longer), but I almost always clear my channels, to give me peace of mind.
- On days filled with meetings, it’s harder, but I keep up with the @ mentions and high priority channels as I can, and then quickly scroll through the less important ones, just to make sure I’m not missing anything important.
- Yes, the Slack FOMO is strong with me, but the clearing doesn’t take long. I’m in dozens if not hundreds of channels, in a Slack with hundreds of people and — active conversations aside — I can clear a day’s worth of chatter in about a half hour, knowing then that I’m on top of things and won’t be surprised the next morning by Fiona with a “so what are we gonna do about that nasty database locking issue?”
So that’s how I stopped worrying and learned to love the Slack: by putting it in its corner and giving it attention on my terms — no more and no less attention than is beneficial.