At the University we work at we have been hearing rumblings in the twittersphere about academics and organisations who have been using Slack to “revolutionise their communication” and reduce their emails. Never a bad thing you might say? We all get lots of emails, some of them even necessary, on a daily, even hourly basis. Wouldn’t it be great if some of this traffic could be reduced and the volume of email ‘noise’ turned down? This is where Slack, “the email killer” steps up and is the latest tool to be trialled in our team.
I first signed up for Slack at its launch in August 2013 and immediately got a team up and running at my organisation. Since then I have seen Slack go from strength to strength and is now worth over $1 billion.
There are quite a few comparison posts out there looking at why slack is an email killer, but I wanted to so a personalised blog post about it here; based on our experiences; using our examples; for our team.
I am a member of 4 slack teams, owner of two of them and an admin on one of them, so I get to see Slack at all different levels. I will take examples from each of them and change the names of people so they are not identifiable but the context will remain relevant to education.
Slack creates teams. Or more to the point, we invite people to our team who may have an interest in what we have to do/manage/achieve. Teams can be set up to be invite only or we can just allow anyone to join and see/collaborate/participate.
Our team was set up to be by invite, so that we could control where our conversations were visible and what was “above the line” communications and what was “just for our team”.
Additional levels of privacy are possible with private #channels. And 1-to-1 coms can happen with Direct Messages (DM). More on that later.
So our TEL team comprised of the normal, recognised members of TEL: Head of TEL, TEL Advisors, Learning Technologists and Admin staff. In addition to this we invited in people from Marketing, ICT, Academics, and even people from outside of our organisation. This meant ALL of the people who may need to know about PART of the project have access to the necessary information. They can also join conversations that they may not be working on but is USEFUL for them to have an overview of.
For example, A member of ICT, “Ian”, joins the team to look at #integrations with our systems. Ian can also see channels about #communications #marketing #faqs and other public channels. Ian decides to take a look at #faqs, just out of interest and can see that there are questions in there that relate to ICT that he can answer. He joins the channel and replies to the questions he can answer.
Ian is also @mentioned in the #marketing channel. Ian gets a Slack notification that he was mentioned in that channel and can then see the context he was mentioned in and whether he should reply/join the channel/DM respond. @mentions are a great way to draw team members attention in to a channel.
In the above example, if email was used for the initial communication, Ian was invited to contribute his knowledge on a thread about integrations. Emails back and forth on the subject of integrations. Ian would not have known or been aware of any questions that were raised in faqs. Ian was not CC’ed in to the email that went round about faqs and no one knew or thought Ian might be able to answer any of the questions in the faqs, so he was never able to contribute to that. Ian was out of the loop. No one considered Ian should be IN the loop.
Ian was also drawn to the #marketing channel through an @mention. He got a notification on his desktop and his phone. He saw that someone had thought that he was the go to person for ICT. He could then see other communications about marketing from the archive posts. Ian could then decide if he had something to contribute or was just being mentioned in passing.
If that had happened in an email;
“Dear Jonny Appleseed,
I bumped in to Ian from ICT in the cafe and we got talking about their comms strategy. Could we please have a meeting with Ian as we believe he could help us with our own comms problem from a technology point of view?
Ian would have never known that Jenny had mentioned him. He is totally reliant on Jonny Appleseed to either a) Forward on the email, b) copy him in to a reply, c) Set up an appointment with Ian. Each one of these solutions requires an additional email, a user input, or someone to “join Ian up” with the conversation.
Slack does this via a simple @mention.
One @mention, and Ian is alerted to conversation that could be of interest to him. And he can CHOOSE to opt in to that channel or not. He is in control.
Slack creates Channels. #general #random are default, public channels. Channels are places where conversations happen, based on a theme. It is easy to find the threads of the conversation as they are all contained in one place rather than being spread over emails from different people. When email is threaded, it is supposed to gather all of the replies and inputs from the ‘conversation’. However, it uses the subject line as the common thread to bring the communications together. This has problems when someone in a completely different conversation uses the same subject line in their email.
For example, a conversation is happening about a problem. The subject line is “Issues” and all subsequent replies are titled “RE: Issues”. Now a third party from a different company also sends you an email about “Issues”; they are joined to the original thread, yet they are nothing to do with that conversation…
Using Slack channels to identify particular concerns, it becomes easy to separate out issues with a particular project. Each project team can have their own #issues channel and therefore issues relating to that particular project are gathered in that team. For teams with multiple projects you can prefix issues with a project abbreviation such as #proj1_issues, #proj2_issues etc… Using prefixes in this way conveniently gathers up channels to do with each project in the same place in the menu bar.
Of course, there is the possibility for people to put the wrong information into the channel which is why it helps to have a good channel description written outlining the appropriate content for that channel. What can’t happen with Slack channels is that issue with threaded emails. There is no way someone outside of the team can post in to a channel with their issue that does not relate to your project.
Only team members can post to channels, and with the use of Private channels, only invited channel members can post, thus ensuring certain comms remain ring-fenced to selected people only.
Channel structure is something the team need to decide on as it has to work for the team in order for it to be effective. Channels have the potential to become convoluted, over-granular and confusing. A strong team will control channels and archive old channels as they become redundant. Good channel management is therefore essential.
Tuning in to communicaitons
Email forces things in to my inbox whether I like it or not. Someone sends me an email, or worse, CC’s me in to an email, it pops up in my inbox and demands my attention. I know I can filter it, I can create a rule that puts it in to a project folder or as some people do, a people folder… or even send it to Junk. But I still get the message and I have to DO something with it.
Slack allows me to ‘tune in’ to communications. With the desktop app and mobile apps, I get notifications which I can control easily enough using the operating system notification settings. I get notified if I am mentioned directly, via @channel or @everyone. So people can pull me in to slack if I am needed, much like an email however, the big difference is that I don’t receive ALL traffic. If I want to see conversations around a particular topic, I have to go to the app where I can see which channels have unread content and I can ‘tune in’ and catch up.
Even better, if someone joins a channel, they can see the entire back conversation. They can trace the history of the conversation easily and see what input they can contribute. This simply isn’t possible in an emailed conversation. You cannot retrospectively CC in people to an email conversation. The only way I can think of doing something similar in email would be to:
- Make sure the entire email conversation was in a single reply-respond-reply email with all of the history in the email. To do this you would have to make sure everyone clicked the ‘reply’ button and didn’t send a new email.
- Find all of the relevant emails and forward them to the new person for them to read and make sense of. You would also have to do this each and every time there was a new person who needed to be added to the discussion.
In the above example, #1 is just completely unlikely to happen. People will always create a new email instead of replying.. I don’t know why, but they just do… Or worse, they use a different email from you to reply to on the original topic thus completely screwing up the thread and mixing up the conversations…
#2 is much too time consuming and impractical.
Of course, like any tool, Slack will only work if people take part. People can be invited to join a team, but you can’t make them take part. They can even join a team, but if they don’t open Slack, or install the app on their device, they will not receive any notifications or see any conversations. Email is far more embedded in our culture than Slack; it has been around for much longer and is more ubiquitous. Email is often the goto tool for people to reach out to others. They are familiar, with the process and protocols of email, and challengers to the crown of ‘communication king or queen’ have a hard task to shift the status quo.
Other tools have come and gone, burned brightly as the next ‘big thing’ and then faded… Why should Slack be any different?
We have already discussed the potential for convoluted channels and communications in the wrong channel. These are real and require a tight and organised team.
I am sure there are other downsides to Slack which will become apparent in due course. But for now, versus email, it is winning!