How Slack redefined collaboration in software development

In my junior year of college, a group of us computer science majors decided to take a road trip to Las Vegas from the Bay Area. This was an 8-hour journey but that would not deter a few 20-something year-olds. There was a problem though, we would have to miss a day of lessons and we had an assignment due. Turning in the assignment was not a big deal, it was submitted online after all but this was in the early 2000s, before the proliferation of fast, reliable, mobile internet. The plan was to take our laptops, work on the assignment, then get on the WiFi at the hotel and submit our work.

That was a great plan, except that we read the assignment wrong and as we were getting ready to head out we realized it was due that day, not the next. This meant we either had to delay the trip and turn it in or miss it. That is when we realized that through a combination of someone’s laptop (I did not own one at the time), my Blackberry, and a USB cable, we could make it happen. While on the road and just 40 minutes before the deadline, we managed to submit our assignment and make it to Vegas as planned.

Untethered Engineers

So what does this story have to do with Slack and engineers? Just like a few college students turned to the convergence of new technologies and trends to solve a problem better, so too did Slack and the army of engineers that adopted it. Slack was able to pick up on a growing engineering pain point, the rise of new technological trends, and a newer generation of users looking for better tools. How did Slack untether engineers where previous tools failed and how can it be even better?

Engineering Pain

I should make it clear that when I talk about engineers here, I am including software architects, developers, solutions engineers, QA, support engineers, and all those titles that fall under the umbrella of engineers in charge of creating, supporting, and running software. The fact that if we were to write out every title, we would add dozens of lines to this article, is exactly a manifestation of the primary pain point Slack addresses; who do I talk to about this? As software development was becoming more complex with many more languages, specialized roles, distributed architectures, and remote teams, the reliance on communication had grown without good tooling to support it.
While developing a game, Stewart Butterfield and his team picked up on this pain point and abandoned the game to develop what would become Slack. Let’s look at how Slack solved this problem while existing tools and competitors failed.

Slack is easy

First and foremost, Slack is easy. Slack is not just easy to use, it is easy on various fronts. The onboarding process is simple, they offer a free tier (who does not love free?) and day-to-day, as well as purpose-oriented activities, are frictionless and intuitive.

The beauty of easy is not that it allows you to do something new, it is that it allows you to do it better or not do it at all. Just like VCS replaced the tedious process of developers emailing tarballs of source code to each other, so too has Slack replaced old mediums. In doing so, Slack has almost completely replaced engineer-to-engineer conversations that previously lived in emails, internal chatting tools, ticketing systems, and water-cooler conversations.

The Slack channel provides enough context for conversations, be they a team or a function, that the search feature makes finding “who do I talk to about this?” much easier than navigating email groups or internal wikis. Even the administrative process of creating a channel and adding people is easy and not bottlenecked by an overworked administrator.
Slack is available everywhere and to everyone

Just like college students, engineers often lead the pack when it comes to working on and in new mediums. Slack makes this possible by running as a desktop app, in the browser, and on mobile. The different mediums are not just checkboxes either, they are equally easy to use and quite powerful. What is more important, however, is that it allows non-engineers to use the same tools. After all, the answer to “who do I talk to about this?” is often someone outside the technical arena. This, combined with the ease of use, ensures that Slack is not a siloed tool. After all, there are already good tools for certain types of communication, think of GitHub or JIRA but those tools are siloed from the rest of the organization and even between different engineering roles.

Slack integrates with everything

The ease of use and wide availability of Slack helped it gain popularity and a legion of users but it is the integrations that have made it sticky. Engineers use tons of tools and various processes to build, run and support software. The introduction of the Slack Marketplace and its cornucopia of apps lets engineers embed Slack in their day-to-day processes.

This means that it does not matter if you want to use Slack to support customers, integrate it into your CI/CD pipeline, or use it as part of your incident management process, there is very likely already an integration with the tools you are using.

Beating out the competition

When you combine the ease of use, its wide availability, and interoperability, it’s not hard to see how Slack trumped the competition. Email was available everywhere and easy to use but without channels, it is easy to lose context and it is completely disconnected from the rest of your tooling. Tools like HipChat existed before Slack but failed to capture a large following, in part due to a late introduction of a free tier, clunky UX, and limited integrations.

DevRev and Slack

Just like Slack, DevRev sees an unsolved engineering pain point. The DevSecOps movement has streamlined and connected the software development cycle from coding to deployment but that connection has not been made from the developer (Dev) to the customer (Rev). The developer today works in the dark, relying on sales, customer support, and PMs to interact with customers and relay back information. The disparate tools these parties use means the information is often lost, siloed in tools unavailable to developers, or unrelated to the developers’ day-to-day activity.

At DevRev, we want to empower developers with this information, in the tools they use every day to enable better decision making. A developer that understands the impact of their work and how it truly affects the customer will be a better developer, focusing on what matters and delivering software that delights.

Product not channel focused

While Slack makes it incredibly simple to find the right people to talk to and of integrating with various tools to provide many communication funnels, it fails to answer the question “what should I be working on now?” At DevRev, we help answer this by making the product the center of the universe. We build a connection from the code devs produce, to the services the code powers, to the features and capabilities provided by those services, and to the products that contain them.

All (rev) interactions, whether it is a support ticket opened by a customer via Slack, usage metrics, a feature request filed by an internal team, or an RCA of a system down, are then tied back to the product and ultimately code. This allows developers to easily look at a work item and see the whole picture, how it affects revs and what work matters the most.

Luckily, you don’t need to choose one or the other. Empower your engineers, integrate Slack, DevRev, and the rest of your tooling and let the engineering love continue.