Slack: Where work happens

Something is happening at companies that use Slack. Slack, the company, may claim it’s work, but it’s less and less productive work, and it’s having a destructive affect upon my own field of software development.

I like really Slack, Flowdock, Hipchat and their ilk — I’ve written about it before. I couldn’t do my job without them. But it’s time to confront the damage these tools are causing.

Bad communication drives out good

The manner which groups work on Slack is the antithesis of effective software development teams — I’ve written about this before:

It’s become clear to me over the last few years that Slack — and I use Slack to represent all of its kind — is displacing all other forms of software engineering communication, to the detriment of our work and the quality of our designs. And like bad money driving out good, no one person is responsible — it’s an outcome of many small behaviours with everyone arriving at the same place. It means no phone and no e-mails, and fewer design documents. And it’s making it culturally unacceptable within teams to communicate any other way.

Instead of thoughtful, considered dialog, a premium is now being placed on a fast response — and that almost any response is better than a delayed one.

It’s not knowledge, it’s noise

One of the most important goals of a software-oriented product development team is to acquire skills and knowledge quickly and efficiently, and yet do this deeply. And it must make this information available to rest of the team — and the new hires to come.

Imagine a software development team that is attempting to master a new technology — and master it sufficiently to build a product on it, and deploy it in production. Then ask the question “where is the knowledge, experience, and skill you’re gaining being stored? Where is it that we can build on it, refine it, share it?”

Tragically the answer to this question at more and more companies is “….we’ve got a Slack channel, everyone is on it, and you learn what you need there.”

A Slack channel is worse than useless as a knowledge store. It’s worse because it gives the impression that a development team is gaining knowledge, organizing it, and really understanding it. It drives out all other forms of building a knowledge base like good documentation, wikis, and, yes, even e-mail.

It’s public when it should be private

This problem with Slack is particularly pernicious, and can cause significant cultural damage within an organization. I’ve seen this occur, to varying degrees, in many companies over the years.

Everyone knows that engineers — particularly within my field of computers — love to argue. The problem with a tool like Slack is that an opinion, an assertion, a discussion thread, can too easily become too argumentative, even hostile — but in an ultra-public manner when on Slack. And because it’s happening in real-time, for all to see, the stakes are high. Frustrations set in, and combined with the inherent ambiguity of text-based communication, discussions can become misinterpreted, tiresome, and a waste of time.

So be careful with your people on Slack. With Slack so much takes place in public, that should actually take place in private — and take place by phone or a video call.

Costing you the ability to focus

I recently finished Deep Work by Cal Newport. I highly recommend it. Like many good books, it tells you what you (in some sense) already knew.

If you spend most of time thinking for a living, like I do, Slack is corroding your most valuable skill — the ability to focus intensely on a single task. It’s changing the nature of knowledge work from long periods of uninterrupted design, implementation, and debugging, to countless short periods of frantic, shallow activity. And it’s seriously weakening your ability to produce really high-quality work — the kind of work that requires deep study.

Slack might not be too bad if it just changed the dominant nature of communication at work, but it’s doing something worse. It’s changing people’s cognition.

So what to do?

Newport’s book left a big impression on me, and made me evaluate my usage of Slack (and e-mail too). I’ve now changed how I work with the tool:

Delete the Slack application from your phone. This has turned out to be surprisingly low-impact, and has removed one source of focus-destroying distraction. At Percolate we have a strong culture of not bringing phones to meetings which helps. If I need to work I use my laptop, not my phone. And if something really goes wrong, well I’m on PagerDuty.

Turn down notifications for Slack to the lowest possible level — only get notified if your handle is actually mentioned. Configure the application so that the icon doesn’t change unless you’re specifically mentioned. This is not about disengaging, but it’s about engaging on your own terms.

Avoid having detailed conversations — especially about detailed or controversial design or technical topics — on Slack. Don’t argue with Operations on how systems should be deployed. Pick up the phone, have a video call, or even write a document summarizing the situation.

All this is a gamble, but one you should take. The gamble is this: that you’ll produce so much better work than you did previously that it won’t matter, you’ll actually excel, and that you’ll become someone who really gets stuff done.

Call it the Cal Newport Gambit.