It’s Not All Unicorns and Rainbows: Managing Slack for Productivity

But Slack is not all unicorns and rainbows. Like many other organizations, we’ve discovered that replacing email (for the most part) with Slack has brought some challenges. As the company grew, the volume of discourse on Slack became unwieldy. Channels propagated and we were faced with Slack bloat. The problem was not just one of noise, it was one of uncertainty as well.

What Kind of Uncertainty?

You see, important conversations were happening on Slack—conversations about critical technical issues and policy decisions. On the surface, that’s awesome. Having those discussions in the open where anyone can pitch in is exactly the sort of thing that makes Slack so interesting. But they were happening everywhere on Slack, and that revealed the anti-pattern. Because there was no predictability, developers felt they had to watch everything, all the time. And, when they failed to do that (because they’re only human), there ended up being miscommunication and wasted cycles as people discovered that decisions affecting them were made in their absence or that the same discussion had happened more than once.

Any experienced project manager can tell you, there are few things as corrosive as uncertainty. As we grew and these problems recurred, Slack was becoming less and less of a trusted system. Its benefits were starting to be outweighed by this uncertainty. We faced the question of scaling back our Slack use versus changing how we used it, so we took the question to our users—i.e., to ourselves, our teams across the board near and far.

We considered feedback cautiously, judiciously. Our loudest concerns about Slack were reported by our users at our largest office. That makes sense; they are also the ones who have the easiest time just reaching out and grabbing someone when they need to talk. For them, Slack is handy but not crucial. If we hadn’t adjusted for that, then we may well have relegated Slack to secondary resource status. But we also listened to the users who aren’t at the center of things. For them, the connection that Slack provides is invaluable, and it was critical to account for this.

So, we decided to fix it. We had two big problems to solve: (1) we needed to improve the overall experience, and (2) to resolve that toxic uncertainty.

The Fix

The first problem was straightforward enough. Being better disciplined about when to close channels (such as closing any channel that had seen no activity for a month) cleared out a lot of clutter, and educating users that they could change sidebar behavior to hide the majority of channels made the experience feel less noisy. But these steps did not solve the underlying problem.

To resolve the uncertainty, we set out to reorganize the channels, to make their purposes more obvious. On the simplest level, this was a function of applying a consistent and meaningful naming convention. We kept two “top level” channels: #general (the Slack default) and #wfx (our “work from X” channel, where everyone checks in at the start of their day to announce where they’ll be working). All other channels now start with an identifier:

• #team - prefixes channels for a specific team, like #team-ux
• #proj - prefixes channels created for a specific project, like #proj-event-chicago
• #auto - prefixes channels that are hooked into remote systems for notification; #auto-jira, for example, receives alerts when a Jira issue is opened or closed
• #org - prefixes channels with organization-wide impact, like #org-helpdesk and #org-hr
• #office - prefixes the channel for each of our physical offices (this is crucial for things like planning lunch!)
• #temp - prefixes temporary channels; we created #temp-slackchange for answering questions during the transition
• #misc - prefixes everything else

This was a good first step, but was not enough by itself. The real trick was establishing clear rules about how the channels would behave. Our rules boil down to:

1. You are expected to be on #general, #wfx, #office- for your office, #team- for your team, and #proj- for any projects you’re on. New users are subscribed to these and are also subscribed to #org-helpdesk.
2. You are welcome on any other channel, but you are a guest. Listen, ask questions when appropriate, but do not disrupt other people’s work.
3. Every #team- and #proj- channel has an explicit owner. Owners are responsible for articulating their team’s Slack policies and pinning those to the channel. They are free to create sub-channels if they are so inclined.
4. #temp- channels can be created by anyone for any reason, but they must have a clear purpose and end point. The default assumption is that these channels will be closed at the end of a sprint.
5. Private channels should be created with care and should follow the general guidelines. It’s important to remember that conversations in private channels (and direct messages) can’t be searched by everyone, so they are more easily lost.
6. Conversations of (almost) every stripe are encouraged everywhere, but no binding decisions will be made outside of the context of the team or project in question.

That last one is the real secret sauce. Our developers love to talk, often at length, about development challenges and potential solutions, as do our designers, writers, and other professionals. But, there was no clear way to differentiate between spitballing and actual decision-making. Now, that’s easy to judge based upon where the conversation happens. Deep nerdery can be happening in #misc-development, and when it evolves into something actionable, it can be taken to the appropriate channel (or, gasp, face to face).

So far these changes have worked really well for us. Slack is less noisy and more productive. Work has been flowing smoothly. It’ll take thoughtful attention to keep it maintained, but it’s been worth it.