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:

1. Creating "Issues" to host discussions
2. Entering communication threads in a database
3. Organizing Slack threads

Creating "Issues" to host discussions

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:

• Framing the topic as an "issue" adds urgency to the conversation.
• The text editor has a lot of advanced features, and even has the handy option to record a Loom instead
• All communication threads can be found in one place. Any contributor can browse these tags, see their status, and even display only the relevant ones (like only the open issue from team-design).

Disadvantages:

• Issue management systems have been first built for engineers, and it's reflected to the experience. Some of these systems only accept markdown editing – which makes it less pleasant to use for non-markdown enthusiasts.
• And while some others have real text editors, their extreme flexibility makes them difficult to organize and maintain. In our interviews, we observed teams setting rules in Readme files to ensure consistency in opening, contributing and resolving issues (how to frame an issue, who to ping, resolution process).

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.

Communication threads as database entries

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:

• Information isn't siloed - it's all linked
• Wikis often have great text editors, and docs are clear to read
• With custom views and embeds, teams can also summarize all the main threads created / closed in their weekly or monthly updates. No extra work required.

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:

• Lack of urgency: Because the discussion happens in a doc, people aren't automatically notified. Contributors need to ping people explicitly.
• You have to "design" your discussions yourself, by adding visual structure to replies (just like I did with line separator).

Overall, hosting discussions in a database of documents is great for organization and centralization, but not a convenient or practical way to communicate.

Organizing Slack threads

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:

• Discussions and decisions are transparent, and info is accessible through search – with the right tagging system.
• Users can choose to subscribe or to silence updates on a thread
• Emoji reactions help a lot to curate the answers that were most important to the decision that was ultimately made

But of course, there are some downsides to Slacking the day away:

• Depending on how your team is using Slack, it can quickly become overwhelming. Critical discussions are at the same levelas jokes posted in your #memes channel.

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.

Final thoughts

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:

• Naming explicit owners
• Assigning due dates
• Putting action steps and goals in the subject line
• Making discussions transparent to the whole team by default.

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.

‍

‍

Want to see what we're building? Sign up for Slite Discussions updates here.