The difference between chat and email
I use chat tools regularly in my job to communicate with other developers, designers, marketing folks, sales people, ninjas, rockstars, and the like. HipChat and Slack are excellent ways to get quick feedback from others, but with great power comes great responsibility.
It's far too easy to fall into the trap of allowing chat to overtake your day. I've found myself in a black hole of messages, which taken as a whole, could probably fit into a few quick emails back and forth.
When someone sends me a chat message, I make a few assumptions:
- this is a blocker for them, and they cannot move forward with the task at hand until the issue is resolved
- they believe that I can help them with this in a reasonable amount of time (minutes, not hours)
- they've already tried to resolve the issue on their own and weren't able to
- it's not a cat gif
To me, chat is synchronous. If I post something that is directed to one person, I expect that person to have a look! I assume a notification is flashing/beeping on their desktop. Being able to fire warning bells on someone else's computer is a big deal, so I don't send a chat message for just anything.
When something comes up that I believe I need help on, here's the decision process I use to route my call:
Can I figure this out on my own? This is the biggest question you need to ask yourself before sending. You should not be disrupting someone else's workflow and break their concentration if you could spend a few extra minutes and find the answer yourself. Of course, if something that would take you an hour to figure out can be answered by someone in 1 minute on Slack, then by all means, ask that person! But if you're asking questions that you didn't spend any time on yourself, then that's just rude.
Is this a priority for right now? If I ask someone for help, do I need their answer right now, or is later today fine? If I can wait, I'll throw it into their email queue for them to prioritize.
- How complicated is this issue? Paragraphs of explanation aren't ideal for chat. Honestly, they're not even necessarily well suited for an email, some face to face time may be in order. If you cannot ask your question clearly and succinctly, it might not make a great chat convo.
Some messages are really never meant for chat in my opinion. A few examples:
Requests for something to happen at a later time. "Hey, can you pull that TPS report and have it to me by Thursday?" is a definite email for me. Not only is this not a priority right now, but a message like this can easily be lost in the shuffle. A key feature of email is that every message needs to be acted upon in some way (unless you're really bad at email). A lot of people treat their inbox as a running todo list of sorts as well, with reminders, tagging, and searching. Hard to do the same with chat.
Info that will definitely be referenced again. I get a lot of people sending me brain dumps of technical specifications, URLs to design comps, etc. that I feel would be better in email. Sharing a few links on chat is fine, but if this is a project handoff to me, I recommend putting it in an email. In 6 months when I'm trying to find the kickoff notes for the Pensky project, it will be a lot easier to sort through my archived emails.
To be 100% clear, I absolutely love using chat on a day to day basis, and having the collective knowledge of a team at your disposal is huge. I send hundreds of messages everyday, and can't believe there was a day when chat was not a central tool in my workflow. Since it is such an indispensable tool, following a few rules helps ensure everyone is being as effective as possible.
A note about ChatOps.
I was just as surprised as you were to learn that they're still making "For Dummies" books, and even more surprised to learn there is one dedicated to ChatOps.
All of the big chat tools have wonderful APIs that give developers the ability to build some really cool integrations and tools. Deploy from chat, anyone? How about build status reports to chat?
There is a huge potential for information overload here as well. Not every member of the team necessarily needs a notification with every Git commit, integration test failure, Rollbar notification, or Pingdom alert.
I think a lot of ChatOps tools fall into the mentality of treating chat as a shared command line, which I think is overkill. I'm not sold on the advantage of
/deploy production in chat, when that could just as easily be run on an actual command line.
Where ChatOps shines in my opinion is enabling non-technical stakeholders to have a window into some technical aspect of the project. For example, the ability for a project manager to be able to disseminate JIRA issues/epics in chat, and have related metadata on those issues automagically displayed in that same chat saves everyone a lot of time and adds clarity that wasn't there before.