Why I Broke Up with Slack—And Went Back

The 3 Changes that Made It Work for Me and My Team Again

My team and I have been using Slack as our primary communication platform since June 2014. As we grew, email became unmanageable and other solutions like Basecamp weren’t a fit. After a full-immersion trial, we were sold!

But then we unsold ourselves. It took three years. But, just as email didn’t scale with our growth, neither did Slack.

Why Slack Didn’t Work for Us

We ran into three main limitations with the app, and I’ve heard the same from other users:

1. Slack made it difficult to track conversations. Slack wasn’t built with threads (topics) as an integral part of the model, so conversations wander from one topic to the next and often back to a previous topic.

2. Slack made it difficult to find what you’re looking for. I spend an inordinate amount of time trying to find stuff in Slack. The search is robust enough, but, because of a lack of threads, it is very difficult to piece together a conversation. Topics A, B, C, and D might interlace as items are brought up and discussed in the relevant channel. All that needs to get mentally untangled to follow the conversation on just topic A after the fact.

3. Slack is built on the wrong communication model. Slack works synchronously, like texting or instant messaging. If you’re not careful, you’re always on. That means constant interruption, and time for deep work vanishes. We also have team members in three time zones so the real-time conversation tends to stretch out the day and steal our margin.

These three problems were compounded as the team grew. When there were ten or twelve of us, Slack was manageable. At thirty and growing, we needed something better.

The Switch to Twist

After reading several positive reviews of Twist, I decided it was time for another full-immersion trial. Twist was created by the team that developed ToDoist. It felt very beta when we switched, but the developers were responsive and helpful.

Most of the team was excited about the test. Twist seemed to address our core problems with Slack.

For instance, threaded conversations were baked into the design from the start. Instead of messages going unmediated into channels, as in Slack, in Twist messages fit inside threads that live inside channels. That extra layer of organization keeps the conversations untangled and makes it easy to review them later on.

But it wasn’t enough.

After ten days of using Twist, we decided to go back to Slack.

The vision for Twist was right, but the implementation fell short. The threads, for example, were less visible than they should have been—which defeated the purpose. Also, the notifications were a mess. I found the labels confusing and constantly felt like I was missing something important.

Worst of all, it wasn’t fun to use. Our team culture is core to our business. One of the hidden benefits of Slack that Twist couldn’t deliver was the way it facilitated fun, social interaction with an all-virtual team. Slack did more to shape our culture than we initially realized. Using Twist, I actually felt less connected to my team—and most of them said the same thing.

As disappointing as they were, however, I wouldn’t trade those ten days with Twist. They were invaluable.

Making Slack Work for Us Again

The more we worked with Twist the more we realized how we could improve our experience with Slack. In fact, I’d say we had to go on this journey with Twist to figure out what we really needed from Slack.

It became apparent we could make Slack work for us by making three primary changes. If you’ve struggled with the three main problems I mentioned earlier, I bet these changes could help you as well.

1. Clarify Project Structure

Based on the way we work, we have the following organizational entities:

• Teams or Brands
• Projects
• Sub-projects

Then, of course, we have conversations about these. As our team grew, the complexity of these conversations evolved faster than our channel structure. To return to Slack, we reorganized all of our channels with these three tiers in mind.

How? I’ll use one of our brands, Free to Focus™, to illustrate:

• #f2f. We use a three letter channel designation that refers to a top-level brand or team. By itself, this never appears as a channel name. It always has a project designation that follows.

• #f2f-general. We created a general channel for every brand or team. If there’s no specific project, the team posts messages in this channel.

• #f2f-activation-workshops. For specific projects, we use a channel with a brief description within the top-level brand.

Then, inside the project channels, we use Slack’s aftermarket thread feature to indicate sub-projects. Because threads are easy to miss in Slack, we begin the initial post in a thread with a subject in bold. Sticking with the Free to Focus™ example, inside the #f2f-activation-workshops channel a thread might start as Workshop notebooks. All the conversation about that sub-project now happens in that thread.

The benefit of this approach is that we don’t have to click on the channel to see or access projects. It results in more channels, but so far has kept us organized and efficient.

2. Protect the Structure with Clear Rules

Clarifying project structure only helps if you can keep it clear. For us, that meant establishing new ground rules on channel structure:

1. Only a few of us are empowered to add a top-level channel (e.g., #f2f).
2. Anyone else can add a project channel to an existing top-level brand. These channels should be preceded with the appropriate three-letter designator (e.g., #f2f-activation-workshops).
3. Inside a channel, we default to threaded replies. When we’re about to post, we first check to see if there’s an existing thread. If not, we start a new thread with a topic set off in bold.

3. Set Expectations on Availability

One thing I loved about Twist was how it articulated its philosophy of asynchronous communication. We all need time for deep work. But synchronous communication interrupts our focus. I get this in principle. But it’s a distinction without a difference in practice.

Twist is no more asynchronous than Slack. It all comes down to how you use it. Every member of the team is responsible for managing their own margin and focus time. And that looks different depending on the department or project schedule.

We communicate our availability directly to our teammates as needed, and also use Slack’s status update feature to let others know when we’re out for lunch, going Off Stage, or digging in for some deep work.

There was a lot to love with Twist. It just didn’t work for us as we had hoped. But the test was worth it because it gave us a point of comparison for Slack, created a new sense of what was possible with Slack, and taught us how to better use Slack.

Sometimes an initial solution won't fix our problems. But it might point us to a better solution if we’re open.

[uam_ad id=”46487″]