We Don’t Use Slack
Confession time: I don’t like Slack.
Swept up in the tech community’s effusive flood of positivity for the product, I spent many months thinking I did. Before I explain why I was wrong, I should state that I believe much of the praise showered on Slack is deserved. For some team workflows, Slack provides a powerful and charming solution to the problem of collaborative communication.
Unfortunately, with great power comes great distraction, and I’ve become convinced that a poorly managed Slack is a more devastating blow to a team’s productivity than almost any other occurrence.
Resistance is Futile
It’s everywhere though, isn’t it?
As a product reviewer, I spend a lot of time dealing with Slack and can only sigh when I enter another beta only to be presented with the inevitable Slack invite. I may be done with Slack, but Slack certainly isn’t done with me.
What Slack wants us to believe, and what their marketing department has been very good at disseminating, is the notion that their product is productivity playdough that can be moulded into whatever shape you need for your team. The part about playdough, at least, is accurate: Slack is an amorphous blob that subsumes other services and presents a unified interface for accessing their information.
Slack is the Borg cube of productivity software.
Fundamentally, the product is built on the belief that most productivity problems can be solved by reducing communication to a series of identically formatted channels, and populating those channels with the ongoing thoughts of its human population and their subservient machines. The dreams of man and software fused into a single stream of consciousness; a cyborg hallucination.
From this primordial ooze we are expected to forge productive workflows.
You can access your file sharing destinations, your Github commits, your social mentions, your website metrics…but all this power and integration seems spectacularly out of touch with the problems that teams actually encounter.
Being able to have channels for all those things is certainly cool, but is it actually useful?
Finding (or inventing) a useable workflow is where things tend to fall apart for me. Try as I might, I find that for all its features and connectivity, Slack seems determined to offer solutions to problems I don’t have. It’s not working with me, I’m working around what it wants to do—it’s all elbows.
To be fair, Slack could be considered a communication service rather than a project management solution, but since so many of its users find ways use it as the latter I have to consider it on those terms.
Product testing is one example of a situation where I find Slack is least effective, so it’s particularly maddening that many developers are adopting it for the task. Just this week I entered yet another beta Slack where I saw that Bug Reports and Feature Suggestions had been given a channel. In each, there was little more than a random flood of discourse, which isn’t useful either to the developers or to the testers.
The Slack hive-mind is thinking:
- It provides a unified place where suggestions can be discussed!
- It lowers the barrier to entry!
- Have you seen our seamless integration with Stahp.ly (“The Uber for Regrettable Product Analogies”)??
Meanwhile, the poor testers are trying to address more fundamental issues:
- Has this bug been reported already?
- Has this feature already been suggested?
- Is this idea on the roadmap? Is there a roadmap?
- I searched and it was discussed two weeks ago, but I have more to say on the subject…should I interrupt the current discussions?
- Speaking of which: what idea, suggestion, or bug is everyone even talking about now? I went to get a sandwich and now everything is cat GIFs.
At any given time there are several parallel threads of conversation happening within each of these channels as people attempt to chat about these things. It takes serious attention to follow the conversation when you’re actively watching it, and if you leave and come back the intervening data and insight is essentially gone. On an active Slack, by the time you’ve caught up you’re already behind again.
I don’t know about you, but that’s exactly the feeling that I expect project management solutions to alleviate, not generate. That is literally one of the primary reasons to use this category of software to begin with.
If it isn’t solving such a fundamental problem—making workloads manageable, accessible, and organized—then what is it good for?
Imagine, if you will, a water cooler in an office space.
This water cooler has been installed for two purposes: one practical, one philosophical. Its functional mandate is to keep employees hydrated by dispensing pure water into recyclable cups. But it also serves as a nexus for casual discussion.
The manager who installed it knows that the water cooler acts as a miniature oasis, a context shift of sufficient magnitude to temporarily erase the tedium of an office space. In the brief moments employees encounter each other at the water cooler, a different and very valuable sort of thinking may occur, even in the context of a casual conversation. It’s a mental palate cleanser. The manager feels wise.
Over time, employees realize that these water cooler discussions are a lot more satisfying than work, so they spend more time there. They don’t want things to break while they’re distracted though, so one of the engineers decides to install a screen above the water cooler that displays a stream of analytics. Now they can all keep an eye on things while they chat.
Soon, more and more office workers have started to frequent the water cooler. Chairs have been pulled up. It’s getting loud. In an effort to keep things organized, these enterprising fellows install a second water cooler, then a third. Each has a sign affixed, indicating which team or division it’s intended for. Naturally these are side by side, so people tend to flow freely from one to the next, but in theory the situation is now “organized”.
Meanwhile, the engineer who installed the screen is getting annoyed by having to walk all the way back to her desk to acknowledge certain insignificant details of actual work, so she installs a keyboard into the increasingly tricked-out water coolers. Now employees can respond to the data on the screen if they have to.
The discussions, of course, have become supremely creative. Unfettered by the burden of actual work, employees have spent time developing a system of communication using their cups: by doodling small graphics onto the sides and holding them up whenever appropriate, they can signal their reaction to someone’s statements without having to respond out loud. With so many people talking simultaneously, the din can get distracting.
Visiting employees from another firm wander through the deserted cubicles to join the conversation. When they leave, they take the plans for these miraculous water coolers with them, and within a few short months this new system of productivity has spread across the tech community.
It’s easy to understand why this water cooler has become so popular; it appeals to our desire for instant gratification, it allows for everyone to be heard on equal footing, and its ability to pull information from numerous sources into this sprawling conversation gives the impression of togetherness, of awareness, of productivity. Plus, everyone’s getting their recommended daily intake of water!
But it isn’t really productive, is it? Those people aren’t working, they’re talking about work. They’re…slacking.
Solving Actual Problems
What this tends to come down to is skillful management.
Wielded correctly, Slack can serve as an effective communication layer that ties together various other services without replacing them. Participating in a well-managed Slack is a wonderful experience, there just aren’t enough of them.
Slack’s biggest struggle isn’t onboarding people, it’s teaching them what the strengths and weaknesses of its service are so that adopters don’t paint themselves into a frustrating corner trying to take advantage of all the fancy features in a thoughtless manner.
To return to my app testing example, bug reports and feature suggestions live much more productively on something like Github or Trello, for example, and activity on Trello can be displayed in Slack. Slack isn’t an ideal point of interaction for this data, but it’s tremendously effective as a unified triage point—an information inbox that serves as a notification tray for all your team’s services.
Nevertheless, it just doesn’t work for me, and more importantly it didn’t work for my team. But it wasn’t for lack of trying.
We Tried Slack
With the caveat that each team’s needs will be unique to their situation and goals, I wanted to unpack my own team’s dissatislacktion a bit to reveal what went wrong.
We’re a small, extremely tight-knit team, and most of our work is with large clients and the various people we collaborate with to deliver our services. On a daily basis, we have a few recurring needs:
- The ability to assign, view, and discuss tasks
- The ability to schedule meetings and shoots, share those calendar items, and view our upcoming work at a glance
- The ability to work on shared documents together, and access a shared repository of files
- The ability to communicate, both privately and in a group, in a work context (which is an important distinction—we have personal messaging options coming out our noses)
- The ability to quickly surface key information and know that it’s safe forever
Slack is effective at tackling some of these, but each team member has their own preferences for handling personal task management, calendars, and documents, and each person’s willingness to adopt new workflows varies with their technology comfort level.
As we settled into our core workflow, we attempted a lot of project management solutions…Asana, Flow, Trello, and of course Slack. Price was (and remains) no object—a system that successfully makes an entire team work together happily and productively is tremendously valuable and well worth paying for.
Setting aside my own reservations about the service, Slack was (somewhat surprisingly) the least popular among my team. By far.
We bumped into a lot of issues:
- As a small team, does it make sense to have channels for specific topics to make finding conversations easier or does that just lead to mostly deserted channels that discourage conversation?
- Should discussion of shared files happen in Slack when an integration surfaces them or on the service itself?
- How do we handle scheduling when everyone has different preferences for calendar software?
- How do we assign and discuss tasks? If on another service that Slack surfaces using an integration, should we discuss the task on Slack or on the service?
In most of these cases, it was easy for me to find a different solution for the problem, and inevitably Slack had an integration for that other service.
But the more we tried to adopt it, the less we used it. We were getting frustrated by the constant catch-up required. It was like an entire product built to exacerbate FOMO (Fear Of Missing Out). I still believed I loved Slack at the time, so I pushed for us to keep trying, to find a way, and the best way to test something is trial by fire.
Our attempt to adopt Slack coincided with a stressful, large-scale project. Where we needed clarity, Slack gave us confusion. Where we needed a view of the forest, Slack gave us trees. It wasn’t long before our Slack became a sad ghost town filled with the integrated pings of other services, all talking to each other.
Plugging holes in Slack’s core functionality in an effort to make it useful for our needs led us to other options that actually were.
One day I asked myself the obvious question: if all these other services are actually solving our problems, what exactly is Slack doing?
A Better Solution
The realization was swift and decisive.
We’ve since found our ideal project management solution, but the ongoing and somewhat strident support of Slack compelled me to offer a dissenting, cautionary perspective that demonstrates one size does not necessarily fit all.
For those of us working in the tech space, resistance may be futile, but it is possible and I’ve always found that true productivity comes not from adopting what’s cool, but what’s effective. The latter is a more difficult task though, because it requires an awareness of your needs, of your team’s needs, and of the options available to you.
It may be an unpopular opinion, but the more I have to use Slack the less I want to. The few times I’ve encountered it as the perfect fit for a situation are grossly outweighed by the number of times it’s been the square peg being beaten petulantly into a round hole while everyone pretends they’re happily getting work done.
As its developers slowly establish it as a platform (that’s the new goal, isn’t it, everything must become a “platform”) I’m hoping to see users make better sense of its strengths and weaknesses.