Skip to content

Instantly share code, notes, and snippets.

@jrubenoff

jrubenoff/1_channels.md Secret

Created May 8, 2017
Embed
What would you like to do?
Chapter 1: Where we communicate

Chapter 1: Where we communicate

We don't all work in the same office, so we don't have the luxury of tapping our colleagues on the shoulder when we want to chat. Sometimes, it can even be difficult for people in different time zones to schedule a short meeting. So, our norms of communication are slightly different than what you might be used to if you're coming from an office job.

Below is a brief overview of our different communication channels, when each should be used, and when to switch between them.

Daily conversations

  • At DOBT, Github issues are where work happens. Any given issue can contain long asynchronous discussions, individual tasks, and bug reports. We also manage projects in Github through its Projects and Milestones features. You'll spend most of the day either writing in Github or working on tasks logged in Github.

  • We're also in Slack every day, our general, all-purpose chatroom. It's great for staying in the loop with colleagues, asking quick questions, and keeping up with what everyone's doing. But Slack is terrible at assigning work to others or writing down anything you'll need to reference later. That's what Github is for.

    Generally, we default to discussing everything in an open Slack channel, rather than in direct messages (DMs). The reasoning is twofold. We want to encourage a transparent and inclusive culture where everyone is part of the conversation, while also building a record of our work, which is only possible if the conversation takes place in the open with broad participation.

  • If a discussion is getting too unwieldy or devolving into quick back-and-forths, we might try to resolve it with a brief audio or video call. (Currently, we're using Zoom and Slack calls for this.) Calls can be a great way to quickly coordinate or make a decision that would take much longer to hash out in writing. If you find yourself collaborating with a team member frequently, think about scheduling a weekly 1-on-1 video call with them.

    We can also screenshare over video calls, which makes it a lot easier to troubleshoot technical issues or demonstrate bugs.

Less frequent channels

  • Your work email is good for reading spam, communicating with those outside the team, and not much else. Email isn't centralized and can easily be altered, and “reply all” threads can be extremely hard to follow.

    If you're emailing back and forth with a colleague, try to move to Slack or video chat as soon as possible. It helps resolve discussions faster and prevents the possibility that you'll lose something in your inbox and forget to reply.

  • Google Docs is great for editing long prose pieces or hosting documents we plan to update frequently. (We usually revise other types of writing, like blog posts, within Github pull requests.)

    We also use GDocs to work on spreadsheets together.

  • Slack posts are pretty useful for sharing company memos, throwing out ideas, and explaining your thought processes with the team. We've just started using them, and we're still experimenting with the best tool to use for this type of writing in the future.

  • Front is our shared inbox for support. We use Front comments to discuss how to answer specific support requests.

  • Pipedrive is our sales CRM, where we manage prospects and leads. We BCC Pipedrive on client-facing emails to place them in a central system of record. We also use Pipedrive's notes feature to document meeting notes.

Team-wide meetings

  • We hold semiweekly check-ins to update each other on our progress for the week and check in on our quarterly goals. We try to keep these short. For anything that needs extended discussion, we schedule follow-up meetings or write up a Github issue.

  • Every quarter or so, we also fly somewhere for a retreat to set the company's direction. Retreats are one of the few times we're able to see each other in person, so we try to make them count.

    We've found that our retreats have been most effective when everyone agrees that the topics on the agenda are worth discussing. If there's a major internal disagreement on the company direction or whether a business problem exists, it's not going to be resolved after a few hours of team discussion.

    This is another reason why it's so important to communicate regularly when working remotely: So that we have the space and time to resolve disagreements independently of retreats.

When to switch between channels

Communication at DOBT follows two general rules:

  1. Discussions should happen wherever it's easiest for everyone to participate. We generally prefer Github for any conversation that isn't urgent or blocking someone else's progress. A/V calls and Slack require everyone to be available and ready to focus on the same thing at the same time, which is uncommon within a distributed team.

    But participants should also feel free to switch to another channel as the nature of the conversation changes. If a Slack conversation is getting too hard to follow, switch to a video call or immortalize it in a Github issue (as appropriate). If a Github discussion is devolving into quick back-and-forths, move it into Slack.

    This also means that discussions should take place wherever all required participants are most comfortable. For example, if there's a decision to be made in a Front conversation that involves non-support personnel, or a Pipedrive thread that involves non-sales personnel, move the discussion into a Github issue.

  2. Every decision should be documented wherever it's easiest to find. You and your colleagues should not only be able to easily find a written record of any decision you made in the conversation, but also why you made it.

    This means that all important information should be recorded in a permanent place that everyone is comfortable with. Decisions made in Slack or over meetings should be posted in a Github comment or Google Doc. If the decision concerns a company policy that's unlikely to change in the short term, it should go into a guide like this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.