Three creative examples from the remote community
Around 6 months ago, we opened a new beta program for a feature called Discussions, and since then, we've interviewed 300 remote teams. For the beta, we selected teams that were already defaulting to asynchronous forms of communication. We did that because we wanted to build a tool for this specific niche - teams like us, who wanted to move forward with decisions without having to schedule meetings.
These 300 companies showed us their many workarounds for making decisions remotely - from Github Issues to Slack threads. We came to the conclusion that the best communication happens as close to work as possible, which is why we think pairing discussions with documentation leads to better decisions. But until Discussions is out, let's analyze current decision-making strategies of our fellow remote startups, to see which are working, and where the process could be improved. After all, we're all in this remote boat together.
Strategies discussed in this post:
Developers are familiar with the process of opening an "issue" to discuss a bug or feature improvement, but some remote companies embrace the Issues tag beyond the software engineering team. Gitlab, GitHub, Jira or Linear issues are used as conversation threads to work together to solve a common problem, just like an online forum.
Here's an example I created to show how Issues-based discussions look when grouped together in Github:
And here's what starting an individual issue thread looks like:
Issues can be used to start a discussion, go deeper into a topic or validate a solution.
Advantages of using issues to make decisions in remote:
Trying out Issues as a communication tool was definitely workable, but it felt a bit in-human, and unnatural at first as a non-engineer.
To move long and important threads away from Slack, we've seen many teams using databases to track discussions around important projects and key decisions.
Most wiki or documentation platforms provide databases, tables or collections that link to individual documents. The documents are thoughtfully laid out and clearly formatted.
You can organize discussions in a database such as Slite tables or Airtable, with all the metadata you want, and even re-embed them the context of another document. This creates a beautiful information loop. If you're a to-do-list type of person (I'm not, I built this doc just to illustrate my point), you can plug your database view right into your daily list.
Some advantages of the wiki-database approach:
These discussions happen directly where work happens. Referencing a document in a discussion makes it convenient to navigate. Referencing a discussion when working on a document gives context to readers.
Some disadvantages to hosting discussions in a database and/or wiki:
Overall, hosting discussions in a database of documents is great for organization and centralization, but not a convenient or practical way to communicate.
With 12+ million daily active users, there's a chance you're already using Slack. And maybe Slack threads are the less workaround-ish approach. While we all agree never-ending threads are about equally as efficient as meeting live or over Zoom, we've seen teams building effective discipline around them.
One remote company we talked to organized all discussions in a #communication-threads channel.
It's easy to see the advantages of this approach for decision-making:
But of course, there are some downsides to Slacking the day away:
What sets it apart from the two other ways of handling asynchronous discussions above, is the organization power – you don't have an overall view with filters, even though you do have tagged channels and people.
And unlike the other examples, Slack is completely separate from work apps. Remote teams we talked to (and our own experience shows) that good communication happens where work happens – which is not really true in Slack's case.
While building Slite Discussions, we've learned a lot by observing how other remote teams handle decision-making. Analyzing their answers to our interviews revealed patterns that overall lead to to better async decision-making, such as:
We've incorporated all these features and more into version 1.0 of the product. But while we think we've cooked up the best remote decision-making process yet - sneak peek below - we know it's not perfect, nor is it perfectly async. So please let us know, via email or on Twitter, what you'd like to see in a discussions tool for remote teams.