I grew up in Muscat, Oman, and it was an exciting time when we got Internet at home in 1996. By 1998, all of my friends who had Internet at home were first on ICQ and then on AOL IM. AOL IM was huge when I went to college in the early 2000’s and was the primary way to connect friends together to chat. Back then, it was rare to have chat rooms, and the rooms that existed were usually long-running things set up to talk about general topics.

The first time I saw value in a chat room in a professional setting was when I got invited to a Basecamp “deploy room” by fellow Agile Admin Peco (or was it Ernest?) at NI when our quarterly release cycle was going super poorly, and all of us (100 other people) were waiting around at hour #34 trying to figure out why some random enterprise application was holding up the rest of the release process. Post invitation to the room, I was able to look at the past messages between the ops team about application failures, and then realized pretty quickly that our databases weren’t actually responding like they should. It took all of 10 minutes to ask someone on the ops side with credentials to run a database query, and figure out that the db creds were all wrong. 2 hours later, the release was all done…

That moment made me realize that 1×1 chats were great, but having a persistent chat rooms with teams of people added value to an organization.

Recently, a colleague asked me a simple question that made me reflect. He asked, “What’s the big deal about Slack?”. At work, there’s been a big push to move towards Slack, when we’ve had 1×1 chat forever. Here are my 5 most compelling reasons for doing so:

1) Collaboration++: 15 years ago, software was a simpler, and there was no cloud/microservices. You’d have 1 large binary to deploy for a platform, and typically have a few folks who understood the overall workings of platform. Today, with microservices, you require a bunch of applications to deploy, and each of these have specific owners who understand specifics. Thus, you’re going to have to have conversations with multiple folks to figure out any issues. Having this in a room setting versus a 1×1 setting gets you to a resolution faster.

2) Chat metadata: Chat is less about words, and more about conversations that include images, links, slash commands, workflows etc. Chatops tools make pasting these much easier than before, and looking at formatted code in Slack is so much easier to read than looking at the same in pidgin.

3) Chat History: Chat apps now give you history – even from when you were not online or in the chat room. This is valuable from the perspective that you can see everything from when you weren’t around, and don’t have to ask someone to keep repeating the problem over and over again. You can just scroll up, read the context, and be ready to help if you can. This is my one knock against IRC (or at least the implementation of IRC at a company I worked at); it was nice to have everyone in a spot, but it only worked when we were VPN’ed in, and had no history.

4) Pipelining with chatbots: Continuous Integration/Delivery is all the rage these days! Having a chat system that allows for your devops systems to push data is a primary requirement in order to build a pipeline of this sort. Responses to broken builds, tests, alerts are quicker when the data associated with these are transmitted to a chatroom that you’re looking at, than having to look at Jenkins all the time. Chatbots are invaluable in this scenario, and help you with information flow.

5) The new normal: A new generation of engineers already do this. It’s already part of the culture for the next generation of engineers who work on open source (for example, kubernetes slack) and there’s even chatter about slack at Universities now. The world is evolving towards broader conversation, and not having chatops tools will hurt your company in terms of hiring and retention.

Agree/Disagree, or have a different perspective? Let me know by commenting below!

Related

4 responses to “Long live ChatOps, RIP AOL IM!”

I fully agree! I’ve worked with an all-remote team for almost four years now, and I can’t imagine working any other way. Chat-based ops (by any name) is a great way to go.

You didn’t mention mobile support. That’s what turned me on to Slack over IRC. “Mobile killed the IRC star…” It’s pretty nice to be able to check in on how things are going from my phone while on a train or boat.

I agree that chat can be great for some focused tasks, like war rooms or build chats. But I’m actually not a huge fan of it for unfocused general operational stuff, because it implicitly gives everyone carte blanche to interrupt anyone else at any moment. You don’t have to compose an email that they might only see later, or look up their phone number and pick up the phone and call them (and what if they’re not at their desk?), or get up and walk across the room – just start typing and you’ll know that they get your message right away!

This reduces friction a lot for the _sender_ of the message, but it’s terrible for the flow of the _receiver_, who gets interrupted in whatever they were doing. And I think we can agree that a culture in which everyone feels empowered to interrupt anyone else at any moment isn’t great for productivity or satisfaction. (Joel Spolsky wrote about this way back in 2000: see https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ and look for “Jeff and Mutt”.)

You can, of course, just sign out of chat, or minimize it and turn off notifications, but this is so blatantly unsocial in chat-centric companies that there’s a pretty high cost to doing it. The answer I usually hear is “Well, you need to have a good culture around chat”, which is definitely true, but giving people an “interrupt anybody anytime” tool and then telling them not to use it works about as well as you would expect…