---
title: Don’t Talk to (Just) Me
teaser:
tags: playbook
author: Caleb Hearth
published_on: 2013-11-11
---

Having chatrooms for your company is great. They aid communication, especially
across multiple locations; they provide an archive for past conversations for
those who were not around; and they can serve to refresh the memory of those who
were. As your team grows, you may need to create multiple rooms with more
specific topics, but discourage one-on-one chats as they do not provide the same
benefits.

## Our Setup

![Campfire Lobby](http://f.cl.ly/items/182Y2N0v1W2U2m2k312b/Lobby.png)

At thoughtbot, we have Everyone, Code, Design, and a couple of Meeting rooms
that can be used for one-off conversations that take longer and might not be
interesting to everyone in the company. The entire company have access to these
rooms. We also have rooms specific to projects to which only developers and
designers working on those projects have access.

We have arrived at this layout after a lot of experimentation, and it is
certainly a living thing—we are always interested in trying something new out in
case it works better.

One thing that we have determined is not a good idea is one-on-one chats. These
types of conversation tend to contain information which would be valuable to the
entire team, such as “hey, do you remember why you made this decision” or which
could benefit from the insight of others: “do you know why this test is
failing?” From our [Playbook]:

[Playbook]: http://playbook.thoughtbot.com

> When things are only said on the phone, in person, in emails that don’t
> include the whole group, or in one-on-one chats, information gets lost,
> forgotten, or misinterpreted. The problems expand when someone joins or leaves
> the project.

## Benefits

Having these discussions in a more public location encourages others to
participate in the conversation and allows them to make the decision themselves
to contribute, read and possibly learn from, or ignore if it doesn't apply to
them. Here is an example of where both happen:

> Ben: So this is odd. When I moved to ruby 2.0 I had to add "host: localhost"
> to my database.yml or it couldn't find the server.
>
> Caleb: I used to need that. It turned out to be a problem with the pg gem, and
> I had to reinstall postgres and pg to fix it.
>
> Joe: Works best while listening to Tool and Radiohead simultaneously
>
> Joel: thoughts on this as an alternative to Postgres view homebrew -
> http://postgresapp.com
>
> Sean: I use it, and love it.
>
> Joe: That's what Heroku recommends:
> https://devcenter.heroku.com/articles/heroku-postgresql#set-up-postgres-on-mac

## Best Practices

Things like mentioning a person’s name and setting up notifications for things
that interest you can help keep up with several chat rooms. Mine are: my first
name, my GitHub and Twitter usernames, ‘coffee’, ‘alaska’, /game ?night/, and
‘[griddler]’.

[griddler]: https://github.com/thoughtbot/griddler

It is also important to remember that when company wide transient communication
is happening in shared rooms, you need not worry about keeping up with
everything. The most important information should be shared in more permanent
ways, such as through Basecamp or email.

Keep conversations public. It encourages participation, builds culture, and
reduces the cognitive overhead of keeping up with one-on-one conversations that
you feel more obligated to budget attention to. Many chat programs provide a
searchable archive, which is useful when looking up specific conversations or
looking for topics which have been discussed. With good discipline in putting
communications in the right room or in a more asynchronous place,
inter-organization communication can improve greatly.