How we stopped using email at IOpipe

This post was originally published on Medium.

At IOpipe, we use three main modes of communication: GitHub, Slack, and Zoom. You’ll notice that email isn’t in there. I’ll talk about why we use this strategy, how we came about to this decision as a team, and what benefits we see from it.

What we use & why

We leverage GitHub, Slack, and Zoom for the mainline of our communications. Other tools are used (for example, LucidChart for architecture diagrams and information flows, Witeboard for online whiteboards, InVision for UI), but if you asked any team member how we communicate, or reference our internal documentation, those three (GitHub, Slack, and Zoom) are the main answer.

GitHub: GitHub is our system of record, and for asynchronous and non-immediate communications. Good examples are: filing an issue for a bug, large feature, smaller issues that make up a feature; then putting those issues on a Project board in GitHub; meeting notes are also written down in GitHub for longevity. If things aren’t filed perfectly, that’s okay, we heavily use search, and GitHub keeps throwing useful features at us, like “related issues” that help people see more quickly if they’re about to file a duplicate.

Slack: Slack is used for real-time, office-like collaboration. Our team is completely distributed (no office) but we do keep core hours generally in the North American timezones. Because of this, we use Slack to bring up ideas, point things out, or get feedback on something quickly to keep things moving.

Zoom: Zoom is for real-time/synchronous collaboration. A good sign something should be on Zoom is if “many people are typing” in Slack, if there’s a scheduled time to jam on a particular feature to make a plan for it, or if there’s an open incident being investigated and multiple people are looking at it. One way to move a conversation from Slack to Zoom is to say “Should this be a Zoom?” in the chat. A 10 minute synchronous chat can often avoid a 60 minute text chat session.
How we got here

Last year, we held a working agreements session to make some team-wide agreements on how we work together. I used some materials from LucidMeetings and this guide from Redbooth to inform what we did. We held the meeting remotely and used Trello (one of our tools at the time) to answer the questions in that agreement, but for the topic today, one of the questions we answered was:

How will we communicate with one another?

The outcome of a working agreement (there’s lots of reading on how to run one if you haven’t, starting with the previous links) was a set of five agreements that we held to, one of which was:

Fewer communication channels the better

Our working agreement became/remains our guiding star on how we manage communications. We realized that when we answered the question “How will we …” email wasn’t on our preferred list of communications. So if we were to abide by our agreement, the fewer communication channels the better, what are we to do?

In practice, it means we have main “trunk” of communications that doesn’t change, even though things around it do. For example, we were doing project management in Trello and realized we were duplicating too much work, so even though GitHub Projects were not as mature when we moved to them, we went all-in on the move. Trello was cut from our company workflow, because doing so upheld our working agreement.

Why it works

The first and principle reason that this works for us is that our team agreed that it would work. No one barged in and yelled “I hate email! We aren’t doing it anymore!” No, that didn’t happen. We’re a team of adults who had a conversation and agreed on how we prefer to do things and, as a team of reasonable adults, we made agreements on how we work together.

There are of course additional benefits: this system has reduced cognitive overhead — the main trunk has clear decision points: does it need to last a long time? Put it in GitHub. Do you need to talk to someone “real quick” about something? Probably Slack, but if it gets to a point where any decision is made, make sure that information is reflected in GitHub, and write out as much context as you can stand (while being clear). Here’s a (by no means complete) example flow:

Communication flow, source available on LucidChart

“Slack-creep,” where groups relay information on Slack to their detriment, does happen in organizations, and there are some treatises written on why people hate Slack. But I can’t say it better than one of our IOpipe alumni (who inspired this post): “don’t put any artifact in Slack that needs iteration, review, or process.” That simple guideline will serve you very well.

How we could improve

There are a few things we could improve that stand out the most: one, while “GitHub as system of record” is generally working, and there is a robust search, having many repositories (including ones for marketing, content, etc.) means the “where’s the right place for this issue?” question is taking up cognitive space, and there’s likely something we can do about that.

Secondly, while the descriptions of each tool in words feel fairly concrete (Slack for … and so on), drawing out a whole flow for how information moves through the organization, depending on the kind of information (perhaps with personas?), would be an interesting exercise and might raise some interesting observations about inefficiencies we’ve internalized.

How to do it

If you’re very intrigued by this and want to do something like this in your organization, I can’t emphasize enough how much implementing this as a result of a working agreement, and not as a top-down decision, felt really positive. When everyone on the team is committed to the agreement, no one person/group is the “enforcer” of “rules” in how we communicate — we talk about how we do things.

The decision was not “let’s kill email,” it was “we should have as few communication channels as possible [the what] so that we can reduce our cognitive overhead and it’s easier to find things [the why].” At that point, removing email from the equation was an action that fulfilled that agreement, or, a tactic to implement a strategy, if you will.

Has your team made a working agreement? How does your remote team practice communication? Curious about working with a remote team that cares a lot about how we work? Try out IOpipe and join our #jobs channel in our community Slack.