Replacing Slack with Twist’s async: what improved, what got worse

We didn’t replace Slack because we hated it.

We replaced it because it worked too well.

Slack is amazing at one thing, which is making it effortless for everyone to talk, all the time. In a small team, that can quietly become the default operating system. Quick questions become mini threads. Threads become decisions. Decisions become “wait, where did we agree on that?”

So we moved to a Twist-style async approach: fewer interruptions, more written context, and conversations that age better than a scroll-back log.

Here’s what improved, what got worse, and what I’d do differently if I was doing it again.

Why we made the change

A few things were starting to show up consistently:

• People were getting interrupted constantly, even when nothing was urgent.
• The same questions were asked repeatedly because past answers were hard to find.
• Decisions happened “in motion” and weren’t always written down properly.
• Context got lost, especially across time zones, deep work blocks, or weekends.
• It was too easy to “feel busy” without moving anything meaningful forward.

We wanted communication to be a tool, not a default state.

What we changed (in practical terms)

We didn’t just swap apps. We changed habits:

• We moved to thread-first communication: one topic, one thread, one place.
• We created clear channels by function, not by vibe.
• We defined what belongs in chat vs what belongs in documentation.
• We set expectations, because most things aren’t urgent and don’t need an immediate response.

And we made one rule that mattered more than all the rest:

If it’s important, it must survive outside the chat tool. Meaning that decisions go into a doc/task/system, not “somewhere in a thread.”

What improved

1) Deep work became more normal

This was the biggest win.

When the default is async, people stop feeling like they have to be “available.” You get longer stretches of uninterrupted work without guilt.

It also reduced that low-level anxiety of constantly checking messages “just in case.”

2) Conversations got clearer

Slack rewards speed. Async rewards clarity.

When you know your message might be read hours later, you naturally include more context:

• what the problem is
• what you tried
• what you’re proposing
• what decision you need

That single shift reduces back-and-forth massively.

3) Decisions became easier to follow

Threads make it easier to see:

• what started the discussion
• what options were considered
• what was decided
• what’s next

This is underrated until you’re hiring, onboarding, or revisiting something three months later.

4) Less noise, fewer “drive-by” messages

Slack encourages micro-messages:

“Quick one…”
“Got a sec?”
“Any update?”

Async makes those feel heavier, in a good way. People batch questions, think a bit more, and ask better.

5) Onboarding got easier

New people don’t just inherit a firehose. They can read through threads and understand how the team thinks and works.

That’s a culture win.

What got worse

1) Some things really are faster in live chat

There are moments where real-time beats async:

• active incident support
• a confusing bug with multiple moving pieces
• emotionally sensitive conversations
• high-ambiguity alignment moments

Async can make these feel slow or fragmented if you force it too hard.

2) It’s easier for “small uncertainty” to linger

In Slack, you can throw a quick question into the void and get reassurance.

In async, people hesitate more. That’s good for focus, but it can mean a small doubt hangs around longer than it should.

We had to encourage a new habit: Ask the question anyway, just ask it well.

3) The social layer gets thinner if you don’t replace it intentionally

Slack has a built-in “office hum.” Removing it can make a team feel more quiet. Sometimes, too quiet.

Async tools don’t create social energy by default. If you want that, you have to design it:

• a lightweight check-in thread
• a weekly wins thread
• a “random” space that doesn’t become a distraction

Without something like this, communication can become purely transactional.

4) People interpret silence differently

In real-time tools, silence feels like “they’re busy.”

In async tools, silence can feel like:

• “did they see it?”
• “are they ignoring it?”
• “did I write it badly?”

This isn’t a tool problem; it’s a human problem.

We reduced this by agreeing on expectations:

• typical response windows
• explicit “I’ll reply later”
• using reactions intentionally (a simple 👀 or ✅ goes a long way)

5) You need better writing habits, or the tool becomes painful

Async is unforgiving if your team writes unclear messages.

If someone posts:

“This isn’t working. Any ideas?”

…you’ll get a long, slow thread of guesswork.

Async demands slightly higher effort upfront. That effort pays back, but it’s still effort.

The biggest lesson: tool change is easy, behavior change is the work

If you move from Slack to an async tool but keep Slack habits, you’ll hate it.

What made the shift work for us wasn’t the platform, it was a handful of norms:

• One topic per thread
• Context included by default
• A clear “ask” at the end
• Decisions written somewhere durable
• Response windows agreed upfront
• Live calls reserved for the right moments

What I’d do differently next time

1) Create an “urgent lane” from day one

Async doesn’t replace urgency. It just hides it unless you design for it.

Have a clear path for:

• incidents
• time-sensitive approvals
• blockers that are actually blocking

Otherwise people will recreate Slack behavior in the async tool.

2) Train the team on writing (seriously)

Not a corporate training. Just simple internal examples:

Bad:

• vague
• missing context
• no clear ask

Good:

• what’s happening
• what you tried
• what you think is next
• what you need from others

A few examples can change behavior quickly.

3) Protect social connection intentionally

You don’t need constant chatter, but you do need some human signal.

A team that only communicates in tasks eventually feels like a machine.

Who I think this works best for

This approach works best when:

• your team values focus
• you have specialists doing deep work
• you don’t want “availability” to be a performance metric
• you’re willing to write a bit more clearly

It works worse when:

• your work is heavily reactive
• your team relies on constant rapid coordination
• you haven’t built the habit of documenting decisions

Where we landed

We still do real-time when it makes sense. We just don’t let real-time become the default.

Overall, the trade was worth it:

• less noise
• more clarity
• better focus
• stronger written context
• fewer “how did we decide that?” moments

And honestly, my favorite outcome is simple: Work feels calmer.

Not necessarily slower. Just calmer.

That’s a rare upgrade.

If you’re considering the same switch, my advice is: don’t start by choosing a tool. Start by choosing the behaviors you want, then pick the tool that supports them.