<< ../posts/Where I'd like to work Back to index... ../posts/Sailing the glass sea >>

Minor Gripe

2020-10-29 -- On Slack and Software Teams

Chris Ertel

Introduction

I’ve worked at several companies that had some remote component for collaboration. Sometimes that meant Slack, sometimes Google Chat, sometimes something else, but the experience has given me some thoughts on what works and what doesn’t work. I’ll focus here on Slack (or similar product) practices.

Some of this stuff is aimed at anybody who uses Slack, some of it is aimed at people who are organizing teams–there is hopefully something here to help everybody.

A note of caution

There’s an entire segment of workers out there, myself included, that cut their teeth in online chatrooms and discussion. The norms we developed in those spaces are usually not congruent with “professional” spaces, and it can be easy to run into trouble when interacting with people outside of that cohort. Don’t assume that the behavior or techniques that work in one setting work elsewhere.

Things that work

Set your color scheme to make workspaces.

Slack lets people share their account across multiple workspaces/groups, and even if they didn’t it’s still possible to be in a non-work Slack in a different window than your work Slack. So, set the color schemes differently so you don’t cross the streams and paste in pictures or sensitive material in the wrong place by accident. Even a subtle difference in the channel sidebar background can be enough to tickle your brain and remind you of who you’re going to be posting with.

Express yourself with lots of emoji.

In text form, we lose a massive amount of non-verbal communication–it can be really hard to tell if something as innocuous as “that’s a great idea” is being supportive or sarcastic. Liberally supply additional context so your coworkers can figure out how you feel about something.

Add company-specific emoji.

At one place we had a collection of little emoji made from pictures of the development team taken at a retreat, including one or two really silly ones. This served to help humanize the developers to the rest of the company, and also provided some much-needed levity at times.

Have purposeful channels and hierarchy.

It’s good to have a channel for all of the engineering folks, all of the sales folks, and so on and so forth. As teams and needs grow, split these into more specific channels that ideally reflect the org chart. You want to make it so that the communications for a given group don’t have to hop through multiple levels. If you want to, keep a couple of channels for company-wide announcements, kudos, and that sort of thing.

The litmus test for this is “Can a topical @channel bother the wrong people?”. If it can, you need to move the people or make a new channel.

I had one gig where enough non-engineering folks had taken to loitering in the engineering team channel that we’d get complaints for normal comms traffic because it was distracting to them–this is absurd, and this sort of things needs to be fixed soonest.

It is also helpful to divide channels into “this is topical discussion but not normal operations traffic” and “this is normal operations traffic”. An example of this is a channel for talking about programming and learning and architecture that is apart from the normal development channel…you don’t want to lose a pager alert because somebody was getting into the groove talking about type systems or whatever.

Prefix channels.

If your company Slack does have non-work channels for pet owners or sharing music or whatever, prefix them with x- or something to make it easy to figure what’s outside work or not. If you have, say, a QA team and a dev team, prefix those channels with qa- and dev-. This makes onboarding and figuring out what channels people need to be interacting with a lot simpler.

Identify the “core” channels for your role and star them.

If you’re a dev, know which channels are critical for doing your job and star/favorite them so they’re always at hand. Do the same for important coworkers. If you need to pay attention to ops stuff, make sure the ops channel is as few clicks away as possible.

Minimize your subscriptions.

Slack has this siren song of bringing the whole company into the same communication space, where every member can see the communications flowing back and forth. This is can be super overwhelming, even if the company is as small as say 30-40 people. Make sure you are subscribed to the core channels above, a few other channels as needed, and nothing else. There is massive fear of missing out on important things, but in my experience you don’t gain anything other than the social-media doomscrolling effect of trying to see what everybody in the company is talking about in every channel you have access to. It may make you feel very connected, but unless your job is specifically about being an information clearinghouse you are distracting yourself.

Manage your notifications.

Ensure that your core channels are the only ones that can notify you, only during business hours or during on-call, and only on your workstation. Don’t setup your mobile to be pinging you every time anybody posts anything anywhere–inevitably somebody will fire off a @channel or a @all and then your office or home will erupt in alerts. It’s just not worth it.

Use ephemeral channels.

Whether it’s for a particular outage, project, collaboration, or working-group, definitely create a dedicated channel (properly marked!) to contain the conversation about it, especially if it has the likelihood to suck the air out of the room for a normal channel. After the time is passed, archive it immediately. You still have the channel around, you can still search it–but it isn’t cluttering up the UI anymore for people.

Embrace bots.

At one gig, a coworker and I implemented a bot to make it super easy for our customer success people to file issues quickly with the on-call internal support queue. /bug <subject> worked great. At another place, our Jira and Confluence integrations had a dedicated dumping ground^W^Wchannel for notifications which actually ended up being pretty helpful for spotting how ticket traffic was moving.

Give your services and bots a voice–it’s pretty easy to write one up to scratch your specific itches. A social channel my friends and I have run for years now has some very neat bot work for things like RSS feeds, reminders, and all kinds of other stuff.

Use screencaps.

It can be incredibly handy to quickly be able to throw a screengrab into chat to demonstrate something. If you don’t already, setup a keyboard shortcut to be able to quickly throw results into chat to show your coworkers things.

Things that don’t work

Don’t type as fast as is normal.

If you’ve been in environments online where you could rapidly type and reply to things, it can be really disconcerting for folks that don’t type as quickly in Slack. You might be articulating a thought and exploring it properly, but the resulting wall of text can overwhelm other teammates. Your teammates may see “X is typing…” and start bracing for something like the navy seal copypasta.

Don’t split messages into many chunks.

In order to avoid a wall of text, you might decide to just set your MTU smaller and send a stream of short chunks. This is perhaps even worse, because it also tends to incrementally slide the discussion up and can disorient people who are trying to respond to chunk 3 when you’re belting out chunk 9. For people that are accustomed to tracking multiple conversations in IRC or whatever this might seem perfectly natural, but it can be really annoying for your colleagues. A possible solution is to use a thread, so at least if you’re exceeding the IO bandwidth of your coworkers you won’t slide the main channel.

Don’t force every channel to be public.

It can be tempting to have everything out in the open but much as open-office plans were a poor substitute for offices public channels are a poor substitute for the private spaces that benefit collaboration. Think of a channel as a shared office–would you appreciate it if your team was having a vigorous discussion and some interloper who decided to take their lunch in there told you to quiet down? Of course not–you’d politely ask them to leave.

First, nobody likes a panopticon. If I wanted to have the entire company watching my conversations with my teammates, we’d be streaming on Twitch (or, more realistically, using a dedicated Zoom room that coworkers can join to say hi).

Public channels also tend to give executives and managers enough rope to trip themselves: they inevitably end up subscribed to everything in order to be or to seem informed. This often leads to them weighing in on discussions when they don’t have proper context yet, and it also tends to mean they’re doomscrolling the company feed instead of managing.

It also screws up the dynamics of interacting with managers and executives. If you are having a disagreement with your direct manager or whatever, that could be a normal and healthy part of your team’s dynamic–but to a lurking exec or manager it may look like insubordination or some early breakdown of the hierarchy that Capital^Wthe business depends on, and so they’ll intervene or get the wrong impression.

Mining this vein further, it’s super easy to end up with a game of telephone even for normal rank-and-file. Say, an engineer sees a support person talking about how a customer is having a problem with a feature that is not deployed yet; that engineer may then run off and start hacking away at a functioning feature flag system under the false impression that it’s busted. Similarly, a support person might see an engineer talking about how payments aren’t working (in staging, but the support person doesn’t have that context) and then they tell the other support people and then it just turns into a whole thing.

In general, context-heavy stuff needs to be isolated to private channels and people that aren’t directly involved need to be politely but firmly told to fuck off.

In one particularly bad case, we ended up implementing a public company-facing engineering channel and then had the private “real engineering” channel where we actually talked shop and did our jobs. At the time it felt subversive but looking back it made sense as a way of demarcating how to talk to us (and we were late to the party, as our customer success people had already done something similar).

Things that are actively harmful

Don’t add problematic emoji.

There are some really delightful and funny emoji that some people I know use on a social server. The humor is a blend of channer, goon, gamer, policy wonk, and historical memes, and as such is quite delightful if you know the culture and quite dreadful and offensive if you don’t. Iconography and memes that fall into one bucket can shift over time and usage into another over time and that shift may or may not be reflected in the community using them.

In a work context, something you and your friends use as a satirical meme (say, Trump with deal with it shades or a screaming Pepe the Frog or a blue anthropomorphic fox or a picture of Stalin or Kissenger) may enrage or antagonize coworkers. Cute Touhou images might bewilder or, again, annoy.

And yes, this makes the place less fun to work at in an era where we cede ever more of our time to Capital. And yes, in a better world people would be more tolerant of something they personally don’t find funny. And yes, in an era of ever-increasing means of self-expression and communication it does seem like we are doomed to settle for the most uniform, milquetoast, non-offensive common denominator. None of that matters.

Use boring, company-approved emoji.

(This also applies to what giphys you use. Honestly, anything you can find on Know Your Meme is probably best left at home.)

Don’t misuse giphy.

It is incredibly easy to get giphy, even when properly configured with content gating, to either fill up the whole screen with animated garbage or to cause distress to coworkers. Use it sparingly, and at least review the images before posting.

Anything said on Slack may come up again.

I have known multiple people that have had screenshots taken of something they’ve said used in ways they hadn’t anticipated. Slack makes this super easy to do. Furthermore, it’s important to note that a sufficiently motivated administrator (or any company paying for the privilege of custom retention or export) can get a copy of any conversations you’ve had, private or not, on the platform.

Even if you’re behaving reasonably and professionally, it can be important to note that certain politically sensitive conversations (say, talking frankly about working through shortcomings in the org chart) may still see the light of day using those tools.

Be careful with backchannels.

It is very tempting, given the nature of the platform, to form groups of friends or even “shadow” units on the org chart. This is something that is best done very carefully, due to the reasons mentioned above and also due to the deleterious effect on company social dynamics. In general, nobody likes secret cabals. If you have to form a private working or support group temporarily, that may be okay–but if the company messaging fabric is riddled with them, there’s something wrong with the org.

In one case, mentioned above, we had a temporary engineering backchannel that was used to help provide a safe space to vent and organize work. It served its purpose, and once a new CTO had taken over we were told to dismantle it and complied. Said CTO returned the favor by providing covering fire and getting us a private engineering space that was sanctioned. This is about as well as that could’ve gone.

There are two further things I’ll say about these backchannels.

First, what starts out as a safe space for venting (think really bad attitude) can often mutate into a vortex of negativity. If members aren’t looking for solutions in addition to their kvetching, then they can end up feeding on each other and just absolutely cratering their morale. When this happens in sanctioned channels, there is a chance that leadership can intervene and break the cycle or at least address grievances…but when it is in a backchannel, there is no moderating force to tone down the depressive spiral of a positive vibe coefficient. That is how an RBMK reactor explodes.

Second, if there is a backchannel that contains multiple levels of management, or provides a skip-level interface, that can be a very powerful thing. Properly used, it can be a way to nudge the organization onto the right path and fix problems before they really get too large. Improperly used, it can seriously undermine the ability of an org to delegate duties to the lowest possible level of leadership by giving people in upper management the information and channels needed to contradict, bypass, or second-guess the people below them who are in charge of organizing the work. This second case can also arise from backchannels for non-work purposes, things organized around politics or hobbies or what have you–Slack just makes it easier.

Conclusion

Slack or clones can be a real productivity boost to your distributed team. They can help with communication, they can foster togetherness, and they can be downright helpful. But, they also run the risk of alienating your employees, distracting your team, and generally raising hell if not handled deliberately.


<< ../posts/Where I'd like to work Back to index... ../posts/Sailing the glass sea >>