scribble

Ben Brostoff

About Posts Book Recos Privacy Email GitHub

30 Jan 2021
Chat Can Be The Mind Killer

Web chat platforms like Slack are the core of remote work and determine how good your remote experience is.

When chat is good, it’s serving the following functions:

  • Async communication where people are getting useful responses in a timely fashion
  • Responders do not feel pressure to respond instantly and understand expectations around response times
  • Chat happens in public channels and searching keywords reveals useful conversations (ex. what an acronym stands for, context for running specific bash commands, why a decision was made the way it was, etc.)

When chat is bad, my experience is it’s failing in the following ways:

  • Chat participants feel pressure to be always available and significant portions of time are spent reading messages and writing responses
  • Communication occurs in private channels and DMs, meaning information is duplicated and worse yet is not searchable

Chat has a higher likelihood of becoming bad when you wear multiple hats in a community. The more things you do, the wider your circle is, and the more conversations you’re going to be involved in. That ups the probability of other chatters not having the same expectations as you and you being part of more DMs and private channels.

To an extent, these problems are unavoidable, and I’ve yet to not encounter them at any company I’ve worked at. Companies are complicated and when they hire more people, chat culture standards change. If you’ve been at a company long enough, you probably know hundreds of people and are in dozens or possibly 100+ channels and DMs. I think on certain days I’m receiving north of 1 message per minute during work hours. While this may seem semi-reasonable, remember that is 60+ messages per hour and on a 9-5 work day amounts to nearly 500 messages per day.

Getting 500 emails per day would never be acceptable to anyone. But because we live in a culture where chat is a staple of remote work and supposed to replace human conversation, people are expected to manage this volume.

Managing this volume takes time and detracts from other activities which many times are higher value add than consuming or producing chat messages. From a software engineer perspective, writing code or documentation is almost always higher value than writing into chat. Similarly, reading code or docs is almost always higher value than reading chat. Code and docs (could be docs for code or business requirements or anything someone took a few hours to prepare that contains valuable info) change far less frequently than conversations. You can invest time in them with a strong probability of returns in the future.

As an extreme example, a core piece of business logic that lives at the center of a codebase is going to be mission critical for engineers to understand no matter the day of the week (or even year). Understanding this code will make it easier to change if and when the time comes the business goes in a new direction. Here, time trying to understand the code could lead to years of returns in productivity.

In contrast, most people can probably safely be uninvolved in a realtime conversation about whether a button should be moved 4px or 8px downwards. Additionally, when decision-makers agree on the spacing, the decision will be in code for everyone to see forever. In this case, any time involved in the pixel conversation - especially if you’re a passive consumer of the conversation and not involved in the decision - has no return. CSS changes and everyone moves on. As an aside, prior to Slack, passive consumers would not even exist, because the designer, PM and responsible engineer would work together in a meeting room where uninvolved parties wouldn’t be invited.

I’ve been trying to remind myself that an hour spent on code / docs is possible 2x - 100x+ the value of time in chat. Yes, I made these numbers up, but I don’t think they’re too far off. Return on time spent in chat if I’m being honest is zero if the conversations don’t have useful information or work to reach an action item.

Even if it’s not possible to get a strong ratio of deeper work hours to chat hours, I think there is real value to reading chat in batches instead of following real-time. If I’m reading X is typing and I don’t need to see a response immediately, it’s a sign I am wasting my own time. My opinion is conversations read better after they have happened and not while they’re happening.

Following a back and forth live is like watching a TV series with frequent commercials and week gaps in releases. You spend more time on the activity and probably have worse understanding of the plot because of the frequent commercials and gaps in episode releases. Async reading of conversations in this analogy is binging a show on Netflix - overall a more enjoyable experience and one that leaves you with a better understanding of the content.

I know I’ve largely failed trying to make some of my observations in this article actionable. Even knowing how unproductive chat can be, it’s hard to step away from conversations that seem mission critical at the time.

That’s why I want to try to have a system I follow so I don’t have to try - I can just follow the system. I think it would look something like this:

  • Have a minimum requirement each day for deep work hours (4+). Signal to others I will be delayed in responding during these hours.
  • Allocate time (maybe to start 30 minutes?) to batching reading of chat messages from different channels. Read first and then determine how to respond. If possible, avoid responding instantly, as that will take time away from reading other channels and consuming the information because responding starts another conversation.
  • Chat in public channels and try to move DMs and private channel conversation to public where possible. This action will improve transparency and make future issues more solvable since answers can now be searched

Going forward, I’m going to try to do these three things and see if they make me more productive.


scribble

About Posts Book Recos Privacy Email GitHub