How to Make Remote Work (part two -- management goals) - HedgeDoc
<center> # How to Make Remote Work: Zulip <big> **Company chat as a self-organizing Knowledge Management platform.** </big> *Written by Max. Originally published 2020-03-26 on the [Monadical blog](* *This article is part of a series on lessons we've learned and processes we've put into place for managing a remote team at Monadical.* </center> Among our core pricinples is transparency. In our ideal world, everyone in our organization has access to all of the organizational knowledge that exists, and is free to filter out whatever is irrelevant to them. This is the "pull" model of knowledge distribution, as opposed to a system where it's someone's responsibility to "push" the right knowledge to the right person. Unless you're the CIA, "pull" is probably a better model for you[^secrets]. [^secrets]: Did you know that [Google]( and [Tesla]( both provide open access to organizational knowledge to their employees? Of course, this is an impossible ideal. Some information is private, sensitive, or distracting, and a lot of knowledge lives inside the minds of other team members. Every organization I've worked for in the past has had a problem with knowledge management; I've seen multiple failed attempts to create company wikis (they get out of date fast; people don't go out of their way to update them unless they're told to). People naturally want to communicate with one another verbally, and verbal communication is ephemeral. **This is why [Zulip]( is the most important tool at Monadical.** If you're not familiar, Zulip is an open-source chat platform, similar to Slack or IRC. But Zulip is much better than either, and not just for privacy/security[^security] reasons: Zulip has a two-level conversation heirarchy, and that heirarchy is core to the UX. Here's what it looks like: [^security]: I've always been perplexed by the lack of concern about storing data with external providers in industry. [Every few days there's a new data leak]( at a huge company. Not to mention that storing your private conversations on some big corp's servers means there are an unkonwn number of system administrators with direct access to everything you say and do. It doesn't take a tinfoil hat to see that this is a threat vector. ![]( This is the general conversation feed. Note that conversations are broken up by "stream," the equivalent of a channel in IRC or Slack. But they are also broken up into smaller divisions, `topics`, and it's simple to browse the conversation topics going on within a stream and to narrow your view down to just that topic: ![]( This makes it easy to follow the thread of a single conversation. It also makes it easy to filter out information that's irrelevant to you: ![]( Coupled with a culture of using Zulip in an organized way, **it's difficult to overstate the impact it has on knowledge management.** The core reason for this is that using Zulip in a way that feels natural creates an organized repository of knowledge *as a side effect*. Knowledge management naturally emerges from good use of the tool. It is the essenence of good UX design. There are a few rules we follow as an organization to amplify the knowledge-management potential of Zulip: * We are careful about curating our stream/topic heirarchy: if we find ourselves having conversations that don't feel like they fit the stream description, we'll move it or create a new one. If a conversation within a `topic` goes on a tangent, we move it to a new `topic`. * We take care to make Zulip the central communication channel for *everything*. That means that any external document or resource (spreadsheets, documents, repositories, videos, contracts, etc) is always linked to in some `topic` where they were used or discussed. * We avoid calls out of habit. Video calls are reserved for situations where the added nonverbal communication is explicitly helpful (social interactions, difficult conversations, team checkins). Anything that's communicated in a call that could be relevant to someone else should be summarized in the topic (where the call will have been linked to in the first place). It's hard to remember to do this (it's hard to remember to step out of natural patterns!), which is why we avoid high-content calls in general. * If we want a reply from a specific person, we always @-mention them. If someone wants a reply sooner, we can PM them again saying so. If it's urgent, we can send an SMS or call the person, saying "please check Zulip". This makes it possible to safely tune out of most company communication in moments of concentrated work. * We avoid PMs out of habit. For personal conversations or sensitive information, it's fine. But whenever a new employee sends me a private message asking about some project, I find or create the relevant `topic` in the relevant `stream` and answer them there, and @-mention them. * We try to fit Zulip directly into our workstreams. For example, in a recent brainstorm session for new ideas for articles to write for our blog, we created a `stream` called `ideas`, and a new `topic` for each one. We could have used something like google docs, but this removes the barrier of having to find a link to a document and change workstreams. Plus the stream's existence in the list is a permanent reminder that that information exists. It lowers the inertia for reentering that creative workflow. This produces some really nice advantages over other communication mediums: * By putting conversations in the right place on Zulip, anyone in the company who wants to be aware of the conversation can be. Nobody gets left out (and nobody needs to sit in a meeting they don't care about either). * Ramping up on or reviewing a project is simple and easy. * It becomes a [content-addressable storage]( system. Want to re-watch the video of that talk your coworker linked to, but can't remember who it was or what conference it was from? Just search the stream for some word you can remember from the conversation about and it'll come up. * It lowers communication barriers. Getting the attention of the founder of an organization can be hard and intimidating. And information can get lost or distorted in the game of information dissemination telephone. With mostly publicly-accessible streams on Zulip, everyone can get an unfiltered version of what anyone else said about any `topic`. * It encourages asynchronous workflows. When conversations are organized, context doesn't degrade nearly as much over time. In Zulip, the context for my specific issue is confined to a `topic`, and so it doesn't get washed out by every other conversation. By contrast, I find that active Slack or IRC channels usually lose most of the context of what I want within minutes. * Work chat becomes much less distracting: the escalation ladder of msg -> @-mention -> PM -> phone makes it possible to tune out all messages below some tier, depending on the situation. * Having a culture of organized conversation puts an organizational emphasis on effective communication, which has tons of positive side-effects on information flow and also peoples' professional relationships. Of course, we're not always perfect. Sometimes I find myself talking about the status of a server that's hosting a project in a stream that's about that project's development, even though we have a stream specifically dedicated to server status. Sometimes I find myself asking people about their weekend in a topic that's supposed to be about an outreach initiative. But in general we're pretty good about it, and pretty good is enough that I find accessing organizational knowledge at Monadical is better than any company I've worked before, even though I can't tap anyone on the shoulder to ask. --- <center> <img src="" style="height: 80px"/><br/> | Full-Stack Consultancy *We build software that outlasts us* </center> --- > Bonus: One of our favorite bloggers and programming educators, [Julia Evans](, is also a Zulip user! She made a succinct, sharable comic outlining some of its strengths [here]( <img src="" alt="Comic about Zulip from Julia Evans" style="max-width: 500px; display: block; margin: auto; float: none">

Recent posts:

Back to top