BS (Before Slack) and AS (After Slack). Naming time eras after tech darling Slack may be a bit of hyperbole. But its ubiquity as a de facto standard collaboration tool across companies large and small does have many people dividing their corporate history into two eras: BS and AS.
We at Maark turned to Slack back in 2015, and it quickly revolutionized our agency’s collective daily life. Slack's federated structure allowed us to manage and organize dozens of individual projects in real-time like we never were able to achieve before. We had new found transparency across product management, design, and development teams. In fact, when I reflect on the growth that has occurred at Maark over the past four years, it is almost impossible for me to imagine our business managing such rapid change through email and other primitive collaboration solutions that we used in our BS era.
As head of engineering, Slack is invaluable for me in getting a good read on the “state of the Maark dev world” across over a dozen development projects: identifying crisis points, participating in architectural discussions amongst developers, monitoring cross-project chatter, and so on.
Slack is also a highly effective way for Maark to team build in 2019 — bringing together engineers from Boston, Europe, and around the globe into a single space to create a genuine community. In fact, it is far more effective than any other collaboration tool that we have ever used at making a remote developer feel connected to a larger team.
Yet, in spite of these revolutionary benefits, Slack does have a dark side. In fact, some of its drawbacks are significant enough that it almost makes me long for those bygone BS days.
Listed below are six shortcomings that I commonly experience when using Slack. However, no glass houses here - not only do I witness these issues playing out, but I often find myself falling into the same traps when working with the productivity tool.
An ill-equipped source of record
Since project teams are in them all day, Slack channels can become the de facto source of record for a given project. However, the stream-like nature of a Slack channel makes it ill-equipped for this purpose. Requirements can get added in a channel ad hoc and then, as they scroll further up in the conversation history, a classic “out of site, out of mind” scenario occurs. (That is, until a resourceful team member at the 11th hour suddenly remembers Slack’s cross-channel search to retrieve that long forgotten requirement, sticking it to the rest of the team.) In the end, Slack should be used for meta activity, but the real work — the true source of record — should be managed in Jira or some other project management tool.
As a tool specifically designed for online discussions, it is surprising that Slack has never really been able to effectively deal with threaded conversations. Threads took a very long time to get added to Slack in the first place. But even after they were supported, I have yet to hear of anyone who actually likes the way that Slack implemented them. Instead of interacting with threads “in place” in the channel, you are taken to a separate sidebar that has no linkage to the main channel window beside it, making it easy to lose context of the thread. For me, a thread in Slack is the place that a conversation goes to die.
Additionally, I find it common to have private direct message conversations with a smaller group of people to reduce traffic noise in the channel. But then when I just include, for example, Alex and Greg in the discussion instead of the full team, then it is easy for that conversation, decision, or action item to become lost as time goes on. After a few days, the thought arises: Where exactly did we talk about that decision?
Slack supports integrations with a host of web services, such as Jira, GitHub, and Salesforce. Relying for years on GitHub to manage our source code, I remember how excited we were the day we could first integrate GitHub activity into channel streams: now we could monitor what our team is doing on GitHub right inside of our Slack channels! While such integration is a powerful way to bring together notifications from mission-critical services, it comes at the cost of adding significant noise to channels. If you are not careful, integrated notifications can completely overwhelm a channel and effectively neutralize any conversation trying to take place there.
Ruled by the immediate
Once Slack becomes an integral part of your business, your day (and night) can become ruled by the tool. The phrase the tyranny of the urgent came into fashion in the 1960s to describe the common reality of urgent matters winning out over important matters. Fast forward to the AS era, and I think we can update that phrase to real-time tyranny when the culture of the company devolves into an implicit expectation for instant answers. I want our developers to be spending much of their day working through tough, complex problems — ones that require extended periods of concentration to solve. But Slack notifications can cultivate an environment in which people neglect solving the true, hard issues in place of placating the immediate.
Slack doesn’t prioritize
If cross-project prioritization is not firmly established in Jira or other systems, then a team member can end up seeing competing priorities across channels with no clear sense of what is most important. Channel A: Is the bug fix ready? Channel B: Is the feature done for the demo tomorrow? Channel C: Do you have an estimate for the new enhancements? I need them for a 2pm call. This scenario is not an indictment of Slack so much as the lack of a system put in place around it.
Online culture carryovers
By its nature of being an online tool and the curious way in which many people can often take on a more aggressive personality when communicating online, Slack conversations risk having a degree of cynicism, terseness, and misdirection that face-to-face conversations in the office rarely do. Left unchecked, such negativity can cause people on the team to feel beat up and drag everyone down.
The irony is that one can take the same people dealing with the same issues but put them in the same room together, and chances are there will be a camaraderie, team work, and a “can-do” approach towards problem solving — further illustrating how distorted a Slack-only lens of reality can be. To be clear, negativity can be controlled in public channels and we effectively stomped that out years ago at Maark. However, sidebar conversations are unmonitored and will always be, to a large degree, uncontrolled.
So how does one get the benefits of Slack without experiencing its dark side? From my experience, the best recommendation to set proper expectations — both with the tool itself as well as with the people who are using it. First, use Slack for what it’s designed for (real-time collaboration), instead of twisting and stretching it into a monolithic corporate platform that it was not designed to do. Second, foster an active Slack community, but don’t handcuff your team in the process. Thus, with proper expectations in tow, you can optimize Slack collaboration to create the best ideas and solve the toughest problems, not put barriers in place that makes it harder for your team to achieve those objectives.