Tag Archives: collaboration

After Moving to Slack: Inbox Zero (at least twice per week)

TL,DR Version: Moving my entire Engineering organization to Slack and adopting a ChatOps collaboration mindset has reduced email volume over 95% and now enables us to resolve issues in 1/4th of the time.

I have always been a fan of using automation, web hooks, and chat-assisted operations to streamline work and enable collaboration across different locations. However, this traditionally required some Engineering and Operations (i.e., DevOps) investment in setting up collaboration servers, programming bots, etc. Slack has changed this, virtually eliminating all technical friction of moving to a ChatOps model. Here is our of how Slack enabled us to move to a ChatOps environment with far less email, faster response times, and greater overall productivity.

In late 2013, I joined a new company that—at the time—had no one on staff at the time with a DevOps-style background. After coming from several years of Chat-integrated operations, it felt like hitting the brakes. One night a few weeks later, I saw a Tweet by @mparca on February 9 about this new great service called Slack. I took a quick look and realized I could achieve everything that HipChat and Hubot did—with a simple push-button SaaS service. My initial set up (our organization, some channels, and hooks to Github) took less than 10 minutes. As it was free (for many features), I did not even need to process a Purchase Order (even better). I was off to setting ChatOps at a new place.

Initially, things went pretty slow. At the time, most of our tech stack and tools were hosted on-premise. Our chat tool of choice as a Skype (not a hook-friendly app). I got a few people to move to Slack, but not many.

Over time, as we implemented a full continuous integration and deployment chain, we added more and more hooks into Slack. First came a move to Atlassian (Cloud). Next Jenkins. Next Sentry. Then Ansible. Then Icinga. Then came custom RTM scripts for more complex things, such as letting our Data Scientists know they have left an idle PySpark context running for more than eight hours. What made this so easy was that everything but the custom RTM scripts could be done in less than five mouse-clicks (it is very helpful that so many collaboration and monitoring tools have enabled web hooks).

As we added more hooks, and started to bring more people onboard, I noticed an interesting shift. People joining our team began to just use Slack to communicate. One developer would come across an interesting new open source repo or article and share it with the rest in #general. Developers with DevOps privileges would jump on issues as soon as they saw a Sentry alert in #prod (saving the need to even text or phone the on-call engineer). Some people even answering questions in code review while they were doing things like waiting at the airport to depart on vacation.

Today our Engineering Teams (Product, Hardware, Software, Data, and Ops) all now primarily use Slack for communications. Most even use it in favor of texting. We Slack each other tickets that are ready for work, UAT, or release). We use group chats to have conversations to answer questions about stories, designs, bugs, and more. We use Slack channels integrated with Github for better code reviews. We use Slack to facilitate pair programming (and pair testing). Slack is now our default tool  for issue diagnosis, as sharing log messages, code snippets, and JSON is much clearer thanks to native markdown.

We achieve this with the following channel model:

  • One channel for each environment (so we can let people know if we are about to add nodes, run a load test, etc.). We have our respective Jenkins, Ansible, Icinga and Sentry hooks tied into each environment channel as well.
  • One channel for each code repository (to see PRs and conduct code reviews). We have aligned our JIRA projects with these to integrate tickets as well.
  • We have some basic team channels for more focused group conversations
  • We also have a #rm channel for simple-to-read log of what was released, when

As our organization moved to this model, life and work got easier in some rather visceral ways:

First, I have been able to dial down my notifications to only ping me when four things happen: I get a call, I get a text, I get a direct Slack message, or there is public Slack in a mission-critical channel. I no longer get endless interruptions, making me more productive at work (and more attentive in meetings and at home). If my phone does ping, it means there is something very important—which actually lets me react to these issues faster.

Second, my email volume is down over 95%. The bulk of the emails I now get are related to true business questions (vs. endless status messages and FYIs). As a result, I can answer email faster and now regularly hit “Inbox Zero” at least twice a week—while managing a 24x7xForever SaaS Engineering organization with follow-the-sun development and operations spanning California, Washington, Europe, and Asia.

Our full embrace of Slack did not happen overnight. It organically evolved over a period of about 18 months–a natural rate of adoption for organizational change. Because it was organic, we did have to institute policies  that forced usage. Instead we allowed our teams to naturally adopt Slack in ways that made work easier. I hope more organizations can make this transition as everyone could benefit from less email and fewer interruptions.

Natural adoption of Slack over other forms of communication would have happened if the usability was not as good as it is. One of my favorite features is how well Slack detects when I am no longer at my desk: if I walk down the hall, my phone chirps on key Slack messages; when I sit back down my phone stops and my laptop takes over.  This happens within seconds.

Oh BTW, we do all of this with the baseline free Slack account. That’s one less excuse to not give it a try.

PS – Want to work in an environment like this? Check us out.

Seven must-have attributes for collaboration tech

Over the past 20 years, “collaboration” has been used to categorise a wide variety of products: instant messaging, email, chat, calendaring, document management, content management, learning management, publishing, discovery, crowdsourcing, and many others.

Even with a range of products this broad, I have repeatedly found seven attributes that separate winning collaboration products (i.e., products people choose – or even demand – to use) from also-rans:

1. Intuitive: Pass the “no instructions needed” test

To foster collaboration a product needs to be truly intuitive. The best way to measure this is with the “no instructions needed” test: if you can put the product in front of any intended user (i.e., your target market) and they can understand enough to explore and use it on your own, you have passed. If not, you have failed: over time people will say your product is too hard to use (and will use it only when forced to do so).

2. Easy: Complete key activities in three clicks or fewer

Collaboration and convenience go “hand in hand.” If your product takes too much effort to use, people will not use it to collaborate. Based on lots of user feedback the hurdle for convenience is three clicks. If something takes more than three clicks to do, it is too complicated. If you can get to what you need in three clicks or less, you have a winner. If your product cannot, one of your competitors will find a way to do and take your market.

3. Convenient: Eliminate work; do not add to it

This is one I am seeing many people forget lately. To make work easier, and drive organic demand, your product needs to eliminate work. It needs to align with the work activities people do as part of their everyday job and remove time, activities and/or systems. If it just “adds another system people have to use (and cut-and-paste from)” it is adding work and will (at best) be a passing fad that will fall out of use.

4. Fast: Pass the “Two x 95-p” test

One of the things that the Internet and broadband have done is raise expectations for speed and response. Watch a person click a button (a browser, a smart phone, a TV electronic programming guide, etc): if response does not take less than two seconds (95% of the time or more), the product will be considered slow and exasperating. This is even truer for enterprise systems that people are required to use to perform their job. You need to be fast—and consistently fast.

5. Ubiquitous: Operate everywhere and anywhere

The whole reason to use a collaboration product is to let people who are not sitting right next to each other collaborate with ease. This means your product must work everywhere and anywhere—passing both the “no instructions needed” and “two by 95p” tests. This is not a trivial demand. However, it is essential. If you do not believe me go to one your international offices or mobile team members and try to collaborate using main office-oriented products.

6. Timely: Collaborate from the same data, at the same point in time

There is an old joke about asking six blindfolded people to touch different parts of an elephant and tell you what it is: one thinks it is a tree trunk, one a fire hose, etc. The same is true for collaboration products: if you are working from out-of-date data you are wasting your time. (If you don’t believe me, think about the last time you responded to an email in a chain only to find out minutes later that your response was out-of-date or irrelevant). Winning collaboration products let everyone work from the same data, at the same point in time.

7. Trusted: Provide utility-class reliability

Collaboration occurs all the time (often at unpredictable times). Collaboration is not “down for maintenance.” If people cannot count on a collaboration product to be there, they will not use it (because they cannot trust it). They will find other tools: saving documents to local disk, writing things down on paper to enter them later, sending them via email, etc. Winning collaboration products are “always-on.” Always-on does not equal 99% reliability; it requires 99.99% reliability or more (Would you use your credit card in public if it failed one percent of the time?)

Why did I pick seven attributes (and not ten)? Ten would be artificial. These truly are the attributes I have seen over and over trip up otherwise good collaboration products and set the winners apart from others (regardless of market or industry).