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
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:
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’.
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.
