Becoming Async-First in a Team That Runs on Slack

Teams that want to work async usually start by discussing tools and end up discussing Slack. That conversation is a detour. Slack supports async perfectly well; what it also supports, and what most teams have accidentally adopted, is an expectation that a message will be read within minutes. The expectation is the thing to change.

"Every async attempt dies in the first crunch week."

The tool is not the problem

Consider what the same message means on two teams. On one, a direct message at 16:00 is read at 16:02 and answered at 16:03. On the other it is read the next morning and answered before lunch, and nobody finds that strange. Same application, same feature set, completely different working lives.

The difference is a norm, and norms are set by behaviour, not by announcements. If the fastest responders on the team are also the most visibly rewarded, everyone learns the actual policy within a fortnight regardless of what the handbook says.

Three changes, in order

One, publish a response-time promise. One working day for channels and direct messages, in the recipient's own zone. Publish it, then have senior people demonstrably use the full day. A promise nobody exercises is not believed.

Two, threads by default. Threads convert a channel from a stream into a set of separable conversations, which is what makes it readable eight hours later. A person coming online in another zone can read four threads and skip nineteen. In a flat channel they have to read everything or nothing.

Three, give people somewhere to look that is faster than asking. This is the one that decides the outcome, and it is covered below.

Deliberately not on the list: migrating to a different tool, banning direct messages, or adding a status-update bot. The first two move the behaviour rather than changing it, and the third adds a daily interruption in the name of reducing interruptions, which is the trap in replacing the daily standup.

The green dot and what it teaches

Presence indicators are the most underrated force in a team's working culture. A green dot next to your name is a claim that you are available, made continuously, to everyone, without your consent. It is why people feel caught when they do not answer, and why some keep the application open in the evening so as not to look absent.

You cannot remove the feature, and you can remove its meaning. State plainly that green means the application is open, not that the person is available, and that working hours are the only source of truth about availability. Then make sure working hours are actually published, per person, in local time, as set out in working-hours agreements that hold up.

Surviving the first crunch week

Async initiatives die in crunch week for a reason that is easy to state and easy to design around: most of them add work at the exact moment people have none to spare. Writing a thorough update takes longer than saying it aloud. Under pressure, longer loses.

So choose changes that reduce work the same day. Threads reduce reading. A published response time reduces the anxiety of not replying. A place to look reduces interruptions for the person being asked. All three are cheaper on day one than the behaviour they replace, which is why they survive a bad week and a written-culture initiative does not.

Making looking faster than asking

Here is the honest constraint. Asking a colleague in Slack takes eleven seconds and has a high success rate. Any alternative that takes longer than eleven seconds will lose, every time, no matter how much better it is in principle. This is why wikis, handbooks, and internal FAQs fail to displace the direct message.

What beats asking a person is asking their StandIn. Each person spends ninety seconds at the end of the day confirming a brief, mostly drafted from the work they already did. While they are off, their StandIn answers questions from it in their words, with a source under every answer, clearly labelled, and never guessing: if the answer is not there, it says so and names who to ask. It takes about as long as sending the message, and the answer arrives immediately instead of tomorrow morning.

That is the change that makes the rest of async stick, because it removes the only reason people had to break it. See how StandIn works.

Common Questions

Can a team be async-first while using Slack?

Yes. Async is determined by response-time expectations, not by the application. A team with a published one-working-day promise and threads by default is async in Slack. A team that has migrated to something else while expecting instant replies has simply moved its synchronous culture.

Should we turn off notifications?

Individually yes, as a default rather than an act of rebellion. But notification settings are a personal defence against a team-level expectation, and personal defences fail when the expectation stays. Change the promise first, then the settings stop feeling risky.

How long does the change take?

Expect four to six weeks for the response-time norm to become believed, and one crunch week as the real test. If the promise survives that week, it will hold. If it does not, look for which specific unanswered question broke it.

What about genuinely urgent things?

Define urgent narrowly and give it its own route, usually the on-call person by phone. The failure mode is not that urgent things exist, it is that without a definition every message becomes potentially urgent and everyone watches everything, which is what async was meant to end.