The Slack morning ritual
Javier Acero
on
Every morning starts the same for me: I wake up, I brew myself some coffee ☕️ (V60, with lightly roasted, freshly ground beans), and I catch up on Slack. But it wasn't always like this…
As you may already know DNSimple is a remote company. We are a fully distributed team, which requires us to rely on different tools to communicate with each other: email, GitHub, Google docs, etc. However, our day to day operational headquarters are in Slack. Slack is where we have our helpful assistant Steve McBots (a.k.a. @steve) and where everything, including all the trolling, happens.
This is very enjoyable while you are working because it is easy to see what your co-workers are doing and feel the heartbeat of the company. But you will close your laptop at some point, and that heart won't stop beating: some of your co-workers on the other side of the world will start their day or come back from lunch. That is the nature of teams spread across different continents (and time zones).
For a long time, I refused to read anything that had happened on Slack while I wasn't working. I opened my computer and marked the transcript as read before moving on with my day. I thought reading it would be a very time-consuming activity and I had better, more productive ways, of spending my time.
This may sound contradictory given what I said about how we use Slack, but I was doing it based on a solid premise: Anything that happened that was relevant would end up somewhere else. Make it a GitHub issue, a wiki page, or a simple email. If it is essential it will make its way to my eyes.
Most of the times, it did. Still, occasionally someone would bring something to my attention that I had missed somehow… So I decided to experiment…
The Experiment
I wanted to verify two assumptions:
- Catching up with what happened on Slack while offline took a long time.
- I did not miss much information by skipping over Slack backlogs.
For the first assumption, I was going to merely track how much time I spent every morning catching up. For the second I was going to trust my gut. It may not be the most objective metric, but it is a subjective perception after all.
For three months my morning ritual changed and I scrolled down to read all the things between sips of coffee…
The Results of the Experiment
It didn't take three months for my gut to tell me how helpful it was to read the backlog. I soon realized that I was gaining insight into something that was usually missing in the GitHub issues, emails, and other forms of communication: context. I could see the events and the conversations that triggered those items, and give feedback based on them. Taking a bit of time to read the backlog proved to be immensely valuable.
I also noticed that I could go through my email inbox much faster than before because most of what was in there I already knew about. So, I was spending more time in Slack but less in GMail.
The experiment also proved wrong my other assumption: it doesn't take a lot of time to read the transcript. Here are the number of minutes that I spent, per week, on it.
The fluctuations you see are due to many factors: busy weeks, me being sick, or even team members in different timezone being on vacation.
In average I spent 106 minutes per week catching up on Slack. This means it took me about 20 minutes of my time to read all that had happened while I was offline. This is a toll that I am happy to pay now that I know how helpful the context is, even in asynchronous communication.
On my Slack preferences
I have a question. Have you used the "All Unread" feature and highlights or do you just back-scroll just general?
While proofreading this blog post Amelia asked me how I use Slack for my ritual. She considered the answer worthy of being part of it, so here we are: I do not back-scroll nor do I use the All Unread feature in Slack.
I simply set it up to start where I left off:
Hope that helps you with your own Slack Ritual.
Javier Acero
Programmer. Minimalist. Apple fanboy. Currently having fun at DNSimple. I love coffee and my cat.
We think domain management should be easy.
That's why we continue building DNSimple.
