Slack: Where work happens
Something is happening at companies that use Slack. Slack, the company, may claim it’s work, but it’s less and less productive work, and it’s having a destructive affect upon my own field of software development.
I like really Slack, Flowdock, Hipchat and their ilk — I’ve written about it before. I couldn’t do my job without them. But it’s time to confront the damage these tools are causing.
Bad communication drives out good
The manner which groups work on Slack is the antithesis of effective software development teams — I’ve written about this before:
It’s become clear to me over the last few years that Slack — and I use Slack to represent all of its kind — is displacing all other forms of software engineering communication, to the detriment of our work and the quality of our designs. And like bad money driving out good, no one person is responsible — it’s an outcome of many small behaviours with everyone arriving at the same place. It means no phone and no e-mails, and fewer design documents. And it’s making it culturally unacceptable within teams to communicate any other way.
Instead of thoughtful, considered dialog, a premium is now being placed on a fast response — and that almost any response is better than a delayed one.
It’s not knowledge, it’s noise
One of the most important goals of a software-oriented product development team is to acquire skills and knowledge quickly and efficiently, and yet do this deeply. And it must make this information available to rest of the team — and the new hires to come.
Imagine a software development team that is attempting to master a new technology — and master it sufficiently to build a product on it, and deploy it in production. Then ask the question “where is the knowledge, experience, and skill you’re gaining being stored? Where is it that we can build on it, refine it, share it?”
Tragically the answer to this question at more and more companies is “….we’ve got a Slack channel, everyone is on it, and you learn what you need there.”
A Slack channel is worse than useless as a knowledge store. It’s worse because it gives the impression that a development team is gaining knowledge, organizing it, and really understanding it. It drives out all other forms of building a knowledge base like good documentation, wikis, and, yes, even e-mail.
It’s public when it should be private
This problem with Slack is particularly pernicious, and can cause significant cultural damage within an organization. I’ve seen this occur, to varying degrees, in many companies over the years.
Everyone knows that engineers — particularly within my field of computers — love to argue. The problem with a tool like Slack is that an opinion, an assertion, a discussion thread, can too easily become too argumentative, even hostile — but in an ultra-public manner when on Slack. And because it’s happening in real-time, for all to see, the stakes are high. Frustrations set in, and combined with the inherent ambiguity of text-based communication, discussions can become misinterpreted, tiresome, and a waste of time.
So be careful with your people on Slack. With Slack so much takes place in public, that should actually take place in private — and take place by phone or a video call.
Costing you the ability to focus
I recently finished Deep Work by Cal Newport. I highly recommend it. Like many good books, it tells you what you (in some sense) already knew.
If you spend most of time thinking for a living, like I do, Slack is corroding your most valuable skill — the ability to focus intensely on a single task. It’s changing the nature of knowledge work from long periods of uninterrupted design, implementation, and debugging, to countless short periods of frantic, shallow activity. And it’s seriously weakening your ability to produce really high-quality work — the kind of work that requires deep study.
Slack might not be too bad if it just changed the dominant nature of communication at work, but it’s doing something worse. It’s changing people’s cognition.
So what to do?
Newport’s book left a big impression on me, and made me evaluate my usage of Slack (and e-mail too). I’ve now changed how I work with the tool:
- Delete the Slack application from your phone. This has turned out to be surprisingly low-impact, and has removed one source of focus-destroying distraction. At Percolate we have a strong culture of not bringing phones to meetings which helps. If I need to work I use my laptop, not my phone. And if something really goes wrong, well I’m on PagerDuty.
- Turn down notifications for Slack to the lowest possible level — only get notified if your handle is actually mentioned. Configure the application so that the icon doesn’t change unless you’re specifically mentioned. This is not about disengaging, but it’s about engaging on your own terms.
- Avoid having detailed conversations — especially about detailed or controversial design or technical topics — on Slack. Don’t argue with Operations on how systems should be deployed. Pick up the phone, have a video call, or even write a document summarizing the situation.
All this is a gamble, but one you should take. The gamble is this: that you’ll produce so much better work than you did previously that it won’t matter, you’ll actually excel, and that you’ll become someone who really gets stuff done.
Call it the Cal Newport Gambit.
5 thoughts on “Why Slack isn’t working”
There are some things that you can use to make Slack more productive. My team had downloaded this plugin called “@Must-Read” so we know what to read when we get in, instead of having to scroll through 8 or 9 hours of conversations that happened before my shift everyday, and it is especially crazy when you have multiple channels.
I’m not and never was a fan of Slack, but I don’t deny that it is a far better solution than Skype was or even email. We turned to Slack because people were getting mad in the office? Why? Skype wasn’t delivering messages. Email would be delayed. Slack is instant.
So it is the better solution for most companies right now until “the next best thing” comes along. Who knows what that is. My worst problem with Slack is that, unfortunately, even like email, I have to be paying attention. Sometimes my team will be having an entire conversation, while I am focused on my work, not paying attention to the Slack channel, and my team may get upset with me for having not paid attention to what was going on until later. There are notifications, but either they work, they don’t, or they end up being annoying.
While it doesn’t cost me my ability to focus, the fact that I sit in a room with co-workers and we’re all using Slack to “communicate” is just a bit awkward. I could literally stand up, walk over to a person’s desk, and communicate with them. But half of our team is on the other side of the United States, which does make it somewhat handy for communication.
Slack might not be working for everyone, but for the majority of people, it does. Unless companies are using an in-house developed chat. Many companies don’t want to spend that type of money, though I’m sure Google and Facebook probably have their own things going on, but for smaller businesses… Slack remains the main investment.
Matt — thanks. Much of what you say is correct. To quote you:
“Sometimes my team will be having an entire conversation, while I am focused on my work, not paying attention to the Slack channel, and my team may get upset with me for having not paid attention to what was going on until later.”
That’s one of main points. What you say is true — but no-one has stopped to think about whether this is right and sensible. In my opinion this is one the main problems with systems like Slack.
Where I used to work, Slack had virtually replaced email. It had gotten to the point where many people would ignore their email for days, making it very difficult to contact them for non-urgent communication. Yet management was hesitant to impose a policy for email vs. Slack because they thought that doing so would be seen as too harsh and disruptive.
You are mentioning important points.
But imo nearly all points that you mention are not related to slack.
Just two points of them as an example ( to keep things short)
Having discussions in slack can cost time. yes. but:
Having discussions in Emails or in real, isn’t cheap either .
You will most proably have long response times with emails, also you have to setup tools to seperate internal from external mails(doing this manually is just wasting ressources)
Also Emails can have changings recepients (only one problem),… And therefore you can get got dozens of redundand emails, some of them only including a private response that others dont have. And there is the same thing like in slack when you come to a meeting “Didn you read email nr 322 with the 4th reply of X where he included his private mail from y ? it was so important…”
This just doesn’t make things better.
Also having every ten minutes someone in your office doesn’t help. Event they question “can I ask you something” is disrupting.
2.) Looking at public discussions
This is also a very important topic but also not related to slack. There are are lot of companies mailing or skyping directly to persons sitting in front of you. If or when this is a good thing is a longer discussion by itself. But so no change here. its just a more complex topic regardless the tool you use.
It is more a company cultural thing.
Is there a culture where people are aware of what they should discuss in public and what in private. (Btw if they don’t write something in a public doesn’t mean they don’t rant in other peoples office.)
The question is more: Is there someone who can stop a discussion without making other developers angry? Do people interact respectful and constructive with each other or not.
Slack isn’t the solution for everything and it doesn’t solve underlying problems but it is also not causing them. ,
It is just a tool and like every tool you can use it in a way that helps you or in a way that harms you. But this is just up to you and the way you manage your team. What kind of channels are there, what can you mute? What should be posted to slack ? Who is moderating? When should I mute slack and so on…
Just as one possibility: Using slack with techniques like pomodoro may help (you can snozze notifications and focus for 25 minutes and see then afterwards all missed messages in the new message tab). You are not disrupted and not missing anyhting. In the meanwhile some problem maybe already solve and don’t require any interaction now.
But in general this is a problem which every company wants to get better. And thats not that easy like using slack or not…
As with everything, I think the value of a tool very much depends upon how you use it.
We’ve gone from not using Slack at all to some fairly deep integration within less than 12 months. We have >20 channels from essential comms (‘general’, ‘announcements’, etc.) to department-specific discussions, to social channels. We’ve integrated our JIRA issue tracking into slack, targeted into the right channels, so we can be alerted and respond when workflows transition. We’ve integrated our C.I. build system so that we’re across failing builds and new deployments. And the same with our monitoring and alerting for API failures etc. We’ve even reverse-integrated our office dashboard, so Slack has effectively become an internal publishing channel for us.
For us, Slack has meant better productivity and easier communications.
There are definitely some potential drawbacks. In particular, issues about ‘lost knowledge’ that can creep in from Slack usage. For example – “What did we agree about that app behaviour we discussed?” “Oh, it’s on Slack somewhere”. Not much use for maintaining an enduring, up-to-date software spec. in a single place. But, as with everything like this, the problem isn’t the tool, it’s the business procedures you enforce relating to its use. Don’t blame Slack for that failing, just ensure that your engineers understand the spec must be kept up-to-date. And use JIRA/Confluence/whatever integrations with Slack to remove the friction from that.
Same goes for file transfer. It can be tempting to ping files to each other via Slack. We need to stop that – files should go on a centralised server, for reasons of both security and organisation. Or, at the very least, if you send somebody an important new file, remember to also put it on the company server.
I’m not sure I agree with the comments in this piece about the public nature of Slack and its perceived negative impact on discussions. I think you could say the same for group emails, Intranet forums, etc. It doesn’t really seem fair to blame Slack for what is effectively a facet of any public discussion. The solution is that your senior team need to be across all group discussions in a structured way, and ensure that the conversation is respectful and inclusive. If you’re not doing that, it’s a management issue, not a problem with Slack. (which, by the way, also allows for private channels)
My final thought would be to ensure a careful delineation between ‘social’ channels and ‘work’ channels. Make sure it’s understood what constitutes acceptable language and behaviour in each of these. For example, we keep our chit chat and mucking around to the `alt-random` channel and wouldn’t, in general, say something in `sprint-planning` that you wouldn’t say in an actual, face-to-face, sprint planning meeting.
In summary, I’m 100% in favour of Slack. Just make sure you explain clearly to your team how you expect it to be used.