Valuing Ephemerality
I like Slack a lot. I loved and still love IRC, and chatrooms in general, because they are an excellent form of synchronous communication to a group of people. The nature of Slack, and IRC bouncers before it, enables the service to become a useful asynchronous communication form, as well.
However, I am concerned that many Slack-using teams have mismatched values and misaligned expectations for the novelty and conveniences that Slack provides. Although it may be searchable, chat logs do not live forever in a meaningful way. They should be treated as ephemeral, even if they technically are not.
My biggest criticism of Slack is that it essentially adds yet another source of truth: its accumulated persistent history may burden users with an obligation to read the pages of history in order to get caught up. It’s one thing when that task takes 2–3 minutes, but it’s a whole other thing when it regularly gets up to 10–20 minutes, as I’ve noticed with some extended conversations that take place over the course of a work day. Slack’s recent ALL UNREAD feature facilitates quicker scanning, but it is not a silver bullet solution: it merely centralizes the attention queue, reducing the clicks and swipes necessary to consume all of the missed conversation.
Moreover, sending files through Slack, etc. moves the responsibility for safekeeping of that file to Slack administrators, whether cloud or private. If the file is a one-off thing, that’s probably OK: it’ll eventually get cleaned up, right? Every upload dialog says that the file will be deleted after 30 days or some other limit. If it’ll be referenced in the future, well, good luck searching for in Slack when it should probably be in a more effective system for long-term file storage, like Dropbox, OneDrive, Box, Google Drive, Sharepoint, Connections, a Github Enterprise repository, or some other internal storage system.
I’ve already persuaded one group within one of my many Slack organizations outside of work that Slack should not be used for communicating decisions. We tried it for a time, and in doing so validated my assertion that people would miss things. The solution was to use Slack for discussion and “just throwing this out” there proposals. We would submit polished ideas to the group via email to ensure that everyone sees it. It’s too easy to declare Backscroll Bankruptcy or miss something important. Unfortunately, this group’s resolve to email polished ideas and decisions wavered towards the end of the project and people started missing things again.
To me, chat is ephemeral, but logged. If I saw it live, I want it recorded. If I didn’t see it, and I should have, then it is incumbent upon others to loop me in. The primary value of Slack and other systems that enable persistent presence is notification via mentions/highlights, not a social contract to get caught up, with potential ostracization for those who didn’t read the backscroll.
Slack is largely an admittedly gorgeous chat client, when compared to most IRC client user experiences. Its omnipotent bot and bot-like systems enable webhooks without the burden of maintaining the bot. It offers a fantastic mobile experience. These points are where the value really is and are major reasons why many companies pay for Slack. As someone who used to maintain IRC bots and my own bouncer to stay connected, Slack can #ShutUpAndTakeMyMoney
as long as my fellow users can agree that chat remains ephemeral.
I certainly welcome and actively search for innovations easing remote, inter-timezone collaboration. However, I question the wisdom of burdening team members with an expectation to read through potentially hours of active conversation. This act is not a wise use of time: very few people spend their limited time reading through hundreds or thousands of lines of scrollback. It compounds cyclically: this isn’t a wise use of time because very few people do it.
For the smaller Slack teams in which I participate, it’s much easier to keep up. However, when people get chatty, the volume of backscroll quickly gets too long for me to catch up. In the interests of maximizing my own productivity within the little time I have available to contribute, I have little choice but to declare bankruptcy and inquire, What did I miss?
So, I establish this workflow: Given Slack, email, and meetings as communication methods,
- use Slack for discussion, then
- email or otherwise record invasively the discussion outcomes like they are status updates,
- reserve meetings for making decisions that cannot be quickly reached via text communication. That is, don’t have a day-long text argument over something. Hold a meeting, perhaps using a Slack or Zoom or 8x8 call, to reach that decision.
Here are the rules I try to follow when using Slack:
- It’s OK to miss something said in Slack.
- It’s not OK to make a decision via Slack discussion and not record that decision elsewhere. A GitHub issue or JIRA ticket is a sufficient record if code was the topic.
- Use
@here
or@channel
only to gain the attention of everyone when a decision is proposed or made. - Use
@here
or@channel
sparingly, lest such become the boy crying wolf. - When discussion gets going in a busy room, move it to a different room or to a private group conversation. If you’re following the rule of external recording, then the outcome should not be lost. Use threads to keep discussion isolated.
- Minimize usage of Giphy and other integrations that create a lot of backscroll. Remember that some people in a room might be on slow or mobile connections, and while a single GIF might be 2 MB, a dozen really add up fast.
- It’s OK not to check work Slack on the weekends, even if it’s on your mobile device. This is key to maintaining good work-life balance.
I keep these in mind and hope that you do, too. These points aim to keep communication flowing by placing a value on ephemerality and encouraging us all to separate the wheat from the chaff.
The key takeaway here is that chat is ephemeral. Consider how other people will see, respond, and be aware or not aware of your conversation and its results.
This post is based on one that originally appeared on my personal blog internal to my employer in the mid 2010s, but especially relevant during the COVID-19 pandemic as more organizations rely on chat systems than ever before. It is informed by conversations I’ve had around the office and posts I’ve made online, including a comment on Please don’t use Slack for FOSS projects. Shouts to my editors for this post Jean, Stan, Zakk, and Kim.