mirror of https://github.com/zulip/zulip.git
157 lines
7.2 KiB
Markdown
157 lines
7.2 KiB
Markdown
There are a lot of team chat apps. So why did we build Zulip?
|
||
|
||
We talk about Slack in the discussion below, but the problems apply equally
|
||
to other apps with Slack’s conversation model, including IRC,
|
||
Mattermost, Discord, Spark, and others.
|
||
|
||
## Reading busy Slack channels is extremely inefficient.
|
||
|
||
Anyone who wakes up to this frequently can tell you it is not fun.
|
||
|
||
<img src="/static/images/why-zulip/slack-unreads.png" class="slack-image" alt="Slack unreads" />
|
||
|
||
The lack of organization and context in Slack channels means that anyone
|
||
using Slack heavily has to manually scan through hundreds of messages a day
|
||
to find the content that is relevant to them.
|
||
|
||
## Senior people rarely use large Slack channels.
|
||
|
||
Slack channels are even worse for managers and other people involved in
|
||
multiple projects. Even modest usage of Slack leads to more channel messages
|
||
a day than most managers have time to handle.
|
||
|
||
In practice, in organizations that use Slack, many senior personnel
|
||
(sensibly) don’t read their channel messages at all, or only read a handful
|
||
of smaller channels. This means you now have a company communication
|
||
platform…with everyone but the decision makers.
|
||
|
||
## Channels rapidly devolve into GIF posts.
|
||
|
||
Once a channel reaches dozens of messages a day, substantive conversations
|
||
become increasingly difficult or even impossible. If you send a thoughtful
|
||
question at 10am, anyone who checks in after lunch is too late to reply,
|
||
since someone else will have already started another conversation in that
|
||
channel. This means that even moderately busy channels can’t be used for
|
||
serious discussion, and they devolve into a mix of quick questions and
|
||
random spam.
|
||
|
||
## Remote workers can’t participate.
|
||
|
||
This means that workers in different timezones can only effectively
|
||
collaborate during the narrow windows when everyone is at their
|
||
keyboards. As a result, Slack isn’t an effective communication
|
||
platform for remote work.
|
||
|
||
As a pointed illustration: The company that makes Slack has over 1000
|
||
employees and yet advertises no remote job positions (positions where
|
||
you could work from anywhere).
|
||
|
||
In contrast, the Zulip team has over 30 core team members distributed
|
||
across a dozen time zones, and uses only Zulip and GitHub issues for
|
||
communication (no email lists, video meetings, etc).
|
||
|
||
## Teams that love Slack are often mostly using DMs and small channels.
|
||
|
||
Slack is great for private messages (“DMs”), integrations, and quick
|
||
questions when everyone’s online. Most glowing reviews of Slack are
|
||
actually of these aspects of Slack. We find that even people that
|
||
love Slack typically send the vast majority of their messages in DMs,
|
||
and avoid using public Slack channels.
|
||
|
||
## So where is the communication happening?
|
||
|
||
In organizations that have adopted Slack, mostly the same place it happened
|
||
before they adopted Slack: email, meetings, and small group chat.
|
||
|
||
Email is great for asynchronous work; that’s a big part of why
|
||
everyone uses it. Email’s simple subject line model, used properly,
|
||
can solve all of the issues above. However, it is too clunky for
|
||
conversations; even a 10-message thread is unwieldy. And it lacks many
|
||
of the conversational features of modern chat apps, like instant
|
||
delivery of messages, typing notifications, emoji reactions,
|
||
at-mentions, and more.
|
||
|
||
Meetings are the current state-of-the-art for conversations where busy
|
||
people like managers, PMs, or other senior people
|
||
participate. However, meetings are often extremely
|
||
inefficient. Participants may need to be present for an hour-long
|
||
meeting when their input is only needed for five minutes portion of
|
||
the discussion. If someone is unable to attend the meeting, their
|
||
input is lost. Someone has to take notes for there to be any record of
|
||
what happened or any follow-ups. And meetings add delay and scheduling
|
||
overhead to decisions.
|
||
|
||
Finally, small group chat works for the short term, but it doesn’t build
|
||
knowledge within the team, and leads to only managers having the full
|
||
picture on projects. Having discussions accessible to larger lists allows
|
||
more stakeholders to stay in the loop.
|
||
|
||
## Asynchronous communication is fundamental to productive work.
|
||
|
||
These problems are all symptoms of the underlying fact that the channel
|
||
model used by Slack and similar tools is a really bad way to structure
|
||
asynchronous communication.
|
||
|
||
However, asynchronous communication is fundamental to how work happens today:
|
||
|
||
* Managers, PMs, and others in meetings all day need to reply to things in
|
||
batch, either in the few minutes they have between meetings, or at the end
|
||
of the day.
|
||
* Anyone in a different timezone or on a different work schedule than the
|
||
rest of the team has parts of their day where they are working
|
||
asynchronously.
|
||
* Individual contributors cannot do focused work if they need to check their
|
||
communication tool every 5 minutes to use it. Asynchronous communication
|
||
is essential to being able to focus for an hour or more, which has been
|
||
shown to have a huge impact on developer productivity and happiness.
|
||
|
||
The fact that you can’t do asynchronous work in Slack channels puts a
|
||
ceiling on how useful Slack can be to an organization.
|
||
|
||
## Ok. What does Zulip do differently?
|
||
|
||
> Zulip’s unique threading saves me well over an hour a day in working with
|
||
> our distributed team of engineers and PMs across 7+ time zones. We tried
|
||
> Slack, Mattermost, and other team chat products that claim to support
|
||
> threading, and nothing handles synchronous and asynchronous communication
|
||
> so intuitively.
|
||
>
|
||
> —Jacinda Shelly, CTO, Doctor On Demand
|
||
|
||
Zulip provides the benefits of real-time chat, while also being great
|
||
at asynchronous communication. Zulip is inspired by email’s highly
|
||
effective threading model: Every channel message has a topic, just
|
||
like every message in email has a subject line. (Channels are called
|
||
streams in Zulip.)
|
||
|
||
<img src="/static/images/why-zulip/zulip-topics.png" class="zulip-topics-image" alt="Zulip topics" />
|
||
|
||
Topics hold Zulip conversations together, just like subject lines hold email
|
||
conversations together. They allow you to efficiently catch up on messages
|
||
and reply in context, even to conversations that started hours or days ago.
|
||
|
||
<img src="/static/images/why-zulip/zulip-reply-later.png" class="zulip-reply-later-image" alt="Zulip reply later" />
|
||
|
||
## Zulip changes how you can operate.
|
||
|
||
It’s simple in concept, but switching from Slack to Zulip can
|
||
transform how your organization communicates:
|
||
|
||
* Leaders can prioritize their time and batch-reply to messages, and
|
||
thus effectively participate in the chat community.
|
||
* More discussions can be moved from meetings and email to chat.
|
||
* Individual contributors can do focused work instead of paging
|
||
through GIFs making sure they don’t miss anything important.
|
||
* Remote workers can participate in an equal way to people present in
|
||
person.
|
||
* Employees don’t need to be glued to their keyboard or phone in order
|
||
to avoid missing out on important conversations.
|
||
* Everyone saves a huge amount of wasted time and attention.
|
||
|
||
> Zulip’s topic-based threading helps us manage discussions with clarity,
|
||
> ensuring the right people can pay attention to the right messages. This
|
||
> makes our large-group discussion far more manageable than what we’ve
|
||
> experienced with Skype and Slack.
|
||
>
|
||
> —Grahame Grieve, founder, FHIR health care standards body
|