
How do you have deep, written discussions with your teams? - jgbond
What is the best way to have careful, deep, written discussions among distributed teams? Are there tools meant for this? Would something like a BBS work. If so, are there good modern options?<p>We use distributed teams. We communicate using a mix of email, Slack, and Zoom. Our work involves lengthy discussions and deep dives into complex issues. This type of &#x27;deep discussion&#x27; benefits from carefully written arguments and counterarguments.<p>Emails often start fine. Someone sends a well structured, well written argument. The first few replies will be strong. But then it diverges into a mess of threads that are hard to follow. People resort to color-coding their responses in-line, etc.<p>Slack is too chatty. Other chat-based solutions are the same. I&#x27;ve never seen it work for this type of &#x27;deep discussion.&#x27; Conversations get scattered across channels and threads within channels. Maybe we&#x27;re using it wrong. To me it&#x27;s the worst way to encourage deep discussion.<p>Zoom, calls, and in-person meetings are hit or miss. The advantage is they seem to cut to the chase on simple issues. But for deep discussion, they often go nowhere. They favor speaking ability. No one prepares enough. Instead of careful thought and discussion, you get hot takes. A lot of our discussion benefits from going away to gather evidence or think more. Rarely is there a need for synced discussion. And there&#x27;s never enough time.<p>I&#x27;ve tried to find off-the-shelf solutions. A simple, old-fashioned BBS seems best. It breaks things into the right unit of discussion. It works for short- or long-form discussion. It creates a coherent timeline of discussion, etc.<p>I worry that without the bells and whistles of a modern app, getting the team to use it will be a challenge. It&#x27;ll be viewed as a stale company discussion board. A lot of options I&#x27;ve looked at have clunky interfaces and tough learning curves for what should be super simple and intuitive.
======
ska
The real problem here is that you have things you want to capture from
ephemeral conversations, and you have structured information you want to build
up over time.

Technology can't solve this for you, but using the wrong one will make things
worse.

You need to

a) pick a medium for the longer lived stuff

b) come up with some rules for how it will be used and, probably more
important, maintained, and

c) put the time in, ongoing.

Lot's of people spend time on (a), don't spend time on (b) and try and avoid
thinking about (c). This means for example if a later conversation shifts the
table a bit, some one needs to go over earlier material and adjust or annotate
it.

I think a lot of approaches can work, but they have to be flexible - you need
to be able to structure things, and also add different media (links, embedded
images/scribbles, whatever). By nature any system that allows this will let
you make a terrible mess of things.

Consider for example Wiki's. I'm sure most of us have seen useful wiki based
documents, and completely useless messes where you can't find anything. The
difference isn't the technology.

Trying to be practical, I would start with either a file system structure on a
shared platform (google docs, dropbox, whatever) with some simple structure
and rules. Or a wiki or wiki like system with good attachment support and
hopefully search.

------
Kialo
(Obviously biased.)

So, instead of using tools primarily designed for chatting and commenting, you
could use a tool specifically designed for the facilitation, capturing and
representation of complex arguments.

We have spent the past 8 years building just such a tool, it’s called Kialo
([https://kialo.com](https://kialo.com)). It’s nowhere near as perfect as we
would want it to be, but it gets the job done nicely.

In a nutshell, Kialo is an argument tree on steroids, with claim/comment
separation, voting, claim multi-linking and switching of user perspectives,
for single and multi thesis arguments.

Discussions can be real-time or async, private or public and worked on via
desktop or mobile browser.

Here is a discussion Ethereum did whether they should use Kialo:
[https://kialo.com/28996](https://kialo.com/28996) (103 claims)

And as an example of a multi thesis debate, have a look at this US politics
one: [https://www.kialo.com/24431](https://www.kialo.com/24431) (>1k claims)

Two months ago we launched Kialo Edu ([https://kialo-edu.com](https://kialo-
edu.com)), our dedicated site for educators, as we wanted to build some extra
functionality for them, additionally to giving them a more controlled
environment without the public discussions.

We plan on releasing a custom site with additional decision-making features
for teams and organizations soon (drop us a mail if you want to be notified
support@kialoXXcom), until then, feel free to experiment/use kialo.com.

All feedback is welcome.

~~~
dot1x
Just wanted to say thanks for mentioning this website. Really interesting
concept. Registered!

------
cjbprime
I would try Zulip: [https://zulipchat.com/](https://zulipchat.com/)

Where Slack encourages line-level chats in mostly static channels, Zulip
encourages paragraph-level chats in lightweight and findable threads.

------
medhir
At LightStep, we use "lab notebooks", which are essentially living documents
for ongoing engineering projects. They are pretty nice for having deeper
technical discussions in a distributed-friendly manner.
[https://go.lightstep.com/rs/260-KGM-472/images/lab-
notebook-...](https://go.lightstep.com/rs/260-KGM-472/images/lab-notebook-
template.pdf)

------
codingdave
We have just started trying to answer this question on my team, and our first
take at it is pulling out specific questions from various emails and
conversation, and documenting them (in our wiki) as a decision to be made. We
write up the question, various answers on the table, pros/cons for each, and
then have a call to talk through them and decide. That decision is recorded on
the wiki page, and we have a running log of the team's discussions and
decisions.

There may be better ways, but it has done a number of things for us:

1) Improved our documentation of decisions.

2) Helped us pull focused, answerable questions our of free-ranging
discussions.

3) Allowed everyone to have a voice, not just the people with vocal, strong
personalities, as any one of us call just write up a page to discuss, and then
set up a call to do so.

------
rogerkirkness
Google Docs with a structured approach and handle it async.

------
contingencies
As an R&D focused company operating across a wide range of areas we have tried
a few things. We are not explicitly focused on written discussions but do want
results to be documented. We have tried many things from wikis to clipboards,
Github issues to formal verbose documents, and settled on markdown files on
Github. Usually we have a group meeting, discuss things, take notes either
directly to a markdown file or transfer them quickly to a markdown file, then
expand thinking there including approaches tested, findings, test results,
conclusions. We like the format because it allows linking to other internal
systems (accounting, other repos, etc.) plus integrating media. Edit history
and access control comes free.

------
muzani
I don't think it's a tool problem. It's a communication skills problem.

Everyone has different communication skills. If you chat with me on Skype,
I'll be mostly passive saying "yes" "uh huh".

I've had the deepest discussions through Slack, but you have to embrace it as
a chat medium - late night Slack, first thing in the morning, ignore your kids
at dinner kind of discussions.

BBS/forums are the same. We've had great discussions, but only with the people
with the skills for it. On an actual board, everyone chatting there does havw
the skills, whereas there are 80% of 'lurkers' who are not very comfortable
yet.

So it depends a lot on your team itself. Agree on something and give them 6
months to learn it.

------
RaceWon
> I worry that without the bells and whistles of a modern app, getting the
> team to use it will be a challenge

You need to tell them that this what we are using. Period.

If you feel the need to elaborate on why you decided to use that medium then
do so... but somebody has to be in charge. No?

------
gtirloni
[https://twist.com/](https://twist.com/)

------
mjrbrennan
Disclaimer: I work here.

Discourse [http://discourse.org/](http://discourse.org/) really is fantastic
for this. We do all our internal communication and longform discussions using
the software as a form of dogfooding. We have lots of plugins that make
working together as a team easier, and it’s so wonderful to be able to write a
longform discussion that everyone reads and contributes to! We have more team
tools on the way as well.

I worked on a remote team before primarily using slack and zoom and that was
awful and full of distraction. Discourse is a breath of fresh air here.

------
jpxw
We use an old-school BBS-style bug tracker. Each project has its own page on
the tracker, in which longer-form discussion can be had. Slack replies are not
ideal, they get swamped easily.

------
myrloc
Do you use GitHub? If so, Discussions are useful for this. Closest in
proximity to your codebase, simple markdown formatting, trusted platform. I've
had some success lately using it as a remote member of my team, primarily to
document my thoughts and request feedback, which is to say it hasn't been very
successful with most of the rest of the team together in an office. However, I
would recommend it as a simple platform for discussion.

------
austinkhale
Our team recently started using Notion for similar reasons. We all heavily use
Google Doc’s but sending a link to a read-only or comment enabled doc gets
messy for discussion very quickly.

Notion enables you to embed any number of Google docs along with other media:
screen captures, screenshots, etc.

The trick is creating a documented process to moderate the discussion.

Jury is still out on long term viability as a tool, but we’re super happy with
it so far.

------
joegahona
> Emails often start fine. Someone sends a well structured, well written
> argument. The first few replies will be strong. But then it diverges into a
> mess of threads that are hard to follow. People resort to color-coding their
> responses in-line, etc.

This is the worst. "Answers in bold" \-- then they forget to bold one. Or
"Answers in ALL CAPS." Too easy to leave people off or some jackass gets
added.

------
hamzafaouzi
I use [https://simpleboard.io](https://simpleboard.io) to keep everyone on the
team updates on projects we're working on, you can submit mini reports on a
realtime dashboard that everyone get updated at the same time, it helps a lot
especially on remote teams and also you can manage project linked to any
platform like jira, asana ...

------
filipcte
We use Discourse for all complex conversations that can happen asynchronously
(meaning not urgent) and we want to capture/document decisions for. Discourse
is also great as internal knowledge base. Moving this sort of comms out of
Slack has also made Slack better for us, as there is less FOMO and thus more
deep work.

------
jgsteven
Agree with all your points here. I find the old-fashioned BBS-style system at
my company extremely useful. Needs email notifications (we have the option for
immediate or batched). Being able to reply by email is a plus (ours does not
have this)--helpful with getting people to use the forum instead of just
email.

------
dyeje
Slack threads seem to work just fine in my experience. Not uncommon for a
meaty subject to reach 80+ replies from 10 different people. Usually finish it
off with a Zoom call once everything has been laid out and it's time to decide
on actions items, if they haven't been decided already.

------
_chrischae
Basecamp. Their product is designed to make long-form written communications
enjoyable/easy. I even wrote a blog post about what they have to say:
[https://blog.pixelic.io/jason-fried/](https://blog.pixelic.io/jason-fried/)

~~~
_chrischae
But I hear you - I founded a remote startup as well and at times we have
lengthy discussions and it's difficult to do them remotely. BTW, are you
building a digital product? If so, I'd love to talk to you, we're building a
tool for software development teams. Let me know if you're interested in doing
a 10-15 min call to exchange notes. chris at pixelic.io. Thanks!

------
davidkim
I'm working on this. Remote-first, writing/async/decisions culture, deep work,
and moving towards a post-chat, modern forum solution. Email is in profile if
interested.

------
thepra
collanon.app Feel free to try it out as much as you want, it's a communication
tool based on timely anonymous topics with limited deep dives(3 levels deep),
a star system on solutions and only after the time ends you'll be able to see
who was behind the messages and who had the most liked solutions.

------
antb123
Confluence? wiki? Google docs? Github Markdown files? - all of these can work.

------
buboard
would a subreddit work?

