I suspect that the ideal primary role of a leader in a remote setting is to serve as a communication channel.
In person, it's somehow easier to tune the office chatter in and out as needed to keep track of what your colleagues are up to. I have yet to find an electronic replacement for this phenomenon. Email, if nobody thought to CC you, you simply won't find out. If people deal with this by defensively CCing everyone, you drown in email. Slack's value is inversely proportional to its uptake: The more people talk on it, the more it resembles a sort of workplace Twitter where it's simply impossible to try and keep track of what everyone is saying, so you give up and resort to only looking at it when you're trying to slack off. Threads attempt to work around this by replicating the problems of email in a chat app.
I suspect that an old-school web forum like phpBB could work well, but any technical merits won't overcome the social perception. There's just no getting around the nerd factor there.
The only technique I've seen work well is the manager-as-dispatcher approach. This poor soul becomes the designated firehose-drinker. They get CC'd on every email, and they subscribe to every Slack thread. They keep an eye out for anything that Sam or Pat might want to know about, and check in to make sure that Sam or Pat is keeping an eye on it.
> They keep an eye out for anything that Sam or Pat might want to know about, and check in to make sure that Sam or Pat is keeping an eye on it.
This is miserable for everyone. Don't make Slack the center of your workflow. Don't let spontaneous Slack chats dictate your process.
The manager's job shouldn't be to scour Slack for information and then ping every person who might need to participate in or read each conversation. That just amplifies the noise. It's terrible to be deliberately ignoring Slack for 30 minutes to focus on work, only to have your manager ping you back into Slack to make sure you don't miss something.
Instead, the manager should be forcing important conversations to happen outside of spontaneous Slack conversations. If something important is decided in Slack, the decision needs to be recorded in the tracking ticket, Wiki, or other important location. If it changes anyone's active work, they should be interrupted. Otherwise, they can pick up the information from the single source of record (ticket, wiki, etc.) rather than being expected to follow every detail of Slack all day.
Small groups working on tasks together should have private PMs or channels to discuss implementation details, not giant Slack channels with 10s or 100s of members.
A good manager will avoid design by committee and will stay ahead of the spontaneous Slack firehose by arranging planning sessions and scheduled meetings where necessary.
Don't let the Slack chaos drive your workflow. Don't try to make managing Slack someone's job. Manage the workflow first, deliberately rather than reactively. If important conversations are happening spontaneously in Slack too often, that's a sign that you need to fix your workflow.
Sorry, allow me to rephrase. I didn't meant that the manager's job is to dogpile everyone onto every issue. It was to make sure that work is being judiciously assigned to the right people, and everyone else is getting progress updates as needed.
My working hypothesis here is that, when there is someone that the team trusts to do that, it will ultimately reduce the level of overcommunication and design-by-committee. Everyone feels more comfortable focusing on their immediate work, and limiting their active participation in things that don't require their active participation, because they know they'll get the memo.
It doesn't matter much if the manager dispatches the pings ASAP or buffers them up for later. You're still letting Slack chaos drive your process instead of leading with process and using Slack as a tool.
In some ways, having the manager buffer up the pings is even worse, because then each person has to revive the topic again if they want to have a voice. People don't want to be left out of important conversations, so the only solution is to watch Slack like a hawk all day. The people who spend all day in Slack instead of doing work end up dominating the decision making while the people who focus on work suffer.
Instead, don't hesitate to gather people for a scheduled call after lunch, at the end of the day, or first thing tomorrow morning to clear it up. Record important decisions in a single source of truth that isn't Slack, like your Wiki or ticket tracker.
Treat Slack almost like you would in-office conversations: If you have a spontaneous watercooler conversation about an important topic in-person, you wouldn't go gather everyone involved to come to the watercooler to continue the conversation. You'd send out an e-mail update to others who need to know. Or you'd scheduled a follow-up call or meeting to discuss it.
The in-person rules of communication and avoiding interruption are a good template for how to behave in Slack.
>> scheduled call after lunch, at the end of the day, or first thing tomorrow morning
This sounds great in theory, but one of the key issues with managing remote teams is there is no common time in the day that is "after lunch, end of day or first thing in the morning".
The reality is most remote scenarios require you adopt at least some async process; fighting this is a losing battle.
Some good news: your manager's job was always facilitate internally and protect externally; how this is accomplished has certainly changed but the core essence of management, if anything, is even more crystallized now.
I feel like I need to mention this in case some eyes see it that need to hear it. If you're running global teams and you have a side of that team that has to show up at the ass-crack of dawn every morning while you get to show up at 4PM with the entire context of a full work day behind you - ROTATE THE TIMES or ASK the engineers on both ends of the spectrum how they feel about it and be understanding if some of them don't want to show up at 8am anymore. Not to mention it puts us into a super weird conversation where we're half asleep and trying to sound like we know what's going on to someone grilling us with full cognition.
Also, async is one thing. Respecting your peoples time is another thing. Slack, etc can show you what time it is in that employees time zone. How do you feel when the first thing you do is open Slack while sipping coffee and eating your bagel and your boss has 10 messages to you from 6am-9am your time?
Probably not the best start to your day. Let people log in, socialize, be humans and colleagues for a little bit before you hammer them, especially now when work is the only real human interaction some people are getting.
> How do you feel when the first thing you do is open Slack while sipping coffee and eating your bagel and your boss has 10 messages to you from 6am-9am your time?
Feels like it’s a day that ends in ‘y’. (My boss and our team get along famously and are all in the same time zone, yet have loads of traffic on our channel(s) between 6 and 9 most days.)
Slack is really poorly built for async workflows though. That's why in my product I have all communication be async, and figure out who needs to get notifications (also async) from their role in the interaction.
For example, if you're the owner of a story and someone asks a question you get notified, and the asker gets notified when you reply, but everyone else gets to keep their sanity.
I also structure comments and require you tag them with the purpose of the comments so people know what it is up front (question, sugestion, todo, etc). That really keeps the stress levels down.
async is not a losing battle. Trying to handle async communication processes manually is.
Right now, most async communication processes (like status updates or daily standups) involve a ton of manual effort to make sure that people share this information.
I strongly recommend creating systems and using automation as much as possible here.
This thread basically enumerates why I started my company. Manual control of workflow and keeping up to speed is at best a waste of time. I want my _Computer_ to do the boring repetitive crap.
You keep assuming that the manager is only delegating via Slack pings, which is not my experience at all and also not what mumblemumble specified.
The best managers know what the appropriate communication channel is for their employees and the issue at hand, and I don't think any strong managers are going to point to Slack pings at their preferred method.
> You'd send out an e-mail update to others who need to know. Or you'd scheduled a follow-up call or meeting to discuss it.
Just my anecdata; this is the polar opposite of what I want. I do not ever, ever want a meeting or a follow up call over an async slack message unless it must be a meeting.
Some managers really need to talk to their engineers and see what the engineers need to perform best and not make every assumption based on what they, the manager, are used to from the last 10 years of their career at 1-2 places.
Forcing a square into a round hole makes engs leave and I've worked for a lot of managers who feel like they stopped growing a decade ago or are using outdated ideologies because the people who promoted them are so far away from the real people creating the sauce now.
This comment makes me realize that I've experienced both sides of this coin now. I've had the manager that asked for daily email updates. And I've worked in a grind silo until I was finished.
There is a balance between them. I think where you draw that line largely depends on the team. An effective manager navigates a team by helping to unblock and de-risk efforts. It's hard for a manager to do that with zero information.
Yeah I've finally gotten enough experience to feel like I've run the gamut of management styles and the best advice I can give is that managers need to explicitly ask questions to some people and genuinely work to improve their performance. Some people (especially new or those who think they're under-performing) won't want to rock the boat at all and will hold their frustrations with things like I mentioned in forever.
I used to be very bad at that. Now I'm pretty firebrand for employees to be treated right as I've finally been to companies that I felt did so (then back to companies that don't) so I recognize what I consider abusive places/mgmt pretty quickly.
I'm vehemently disagreeing about using email as a communications means in 2020 when omnichannels, slack, ticket-systems, etc exist. I don't want a mail client pinging me with mostly trash throughout the day between All Hand emails, tech emails, out of band sales people, etc.
That's really my point, some of us work completely differently. Ask your engineers how they can perform best..
Mail is better then slack in that it is non interrupting. It is good for usual stuff that can wait hours or few days and is neither bug not feature request. Which is quite common thing.
Both suck when you actually want any structure or have to go back later to figure out what happened. You need to structure your communication more than free form text. For example, is that email a question? A suggestion? Maybe it's a reason this is all pointless. Search doesn't really fit the bill because it only really works if you know the proper words.
Process should follow people, not vice versa.
If you only allow collaboration at 10am on Tuesdays for project X and 2 pm Friday for Project Y, you are missing a lot of collaboration.
Most workplace communication tools are focused on improving the efficiency of communication. I think of this as laying "pipes". It's never been easier to jump on a video call or ping someone in Slack or email. What happens is that the information/communication doesn't flow on a repeatable or predictable basis.
What people really need when remote is a way to help create and automate a series of communication habits/workflows, so instead of hunting around or perusing Slack to understand what's going on, the information flows to you. Like a series of communication pumps.
Right now, most managers manually collect this, which is an epic waste of time.
Self plug, but after 8 years working remotely and constantly running into the workplace chat firehose, I've built software to help automate any routine update at work (https://www.friday.app).
It comes down to structuring some type of process for facilitating communication rather than being reactionary.
Spontaneous conversations are going to happen and should be encouraged, but Slack is not a platform for documenting a decision or conversation. If for no other reason than it’s not concise. Coming back and trying to parse an hour long slack convo is a waste of time when it can likely be boiled down to a one paragraph summary.
If something interesting happens I find it helpful to take that opportunity to get the gist or decision documented in a ticket or wiki page somewhere for easier dissemination and for centralizing further communication and decisions related to the topic.
>A good manager will avoid design by committee and will stay ahead of the spontaneous Slack firehose by arranging planning sessions and scheduled meetings where necessary
A great point. They will ideally also have enough context, experience and intuition to 'individualize' comms - providing detail from an earlier briefing to the ux person while omitting the unnecessary technical details that are more relevant to the other team mate who is working on a security feature.
As a team lead, I do subject myself to a bit of a firehose outside my immediate team in the hopes of stumbling across little nuggets of useful info and context, but if I orchestrate communications within my org well enough, that's the only time it occurs.
> I suspect that an old-school web forum like phpBB could work well
It’s funny that you say this, but at Automattic (where I work), we use a tool called p2 [0] which is built on WordPress blogs. So it’s basically a blog with real-time comments, and each team/division has their own p2. As our saying goes, “p2 or it didn’t happen” — and it’s probably the main thing that keeps communication healthy. It’s easy to follow the set of blogs applicable to your work, easy to cross-post to other blogs, it’s globally searchable, and easily sharable. Thus it avoids the problems you mention with email and slack. We use slack a lot as well, but few use email at all.
Like you say, it works because everyone buys into it and uses it.
I largely share your opinion and conclusions; good managers were always a combination of filters and selective connectors and I don't think this has changed. If anything it's far more important these days. What I fear (and hate) as a manager is that you're right - I need to be privy to every conversation, topic, initiative, etc and then pull in only the absolutely minimally required resources. This consumes all my time and is extremely tiring.
I hear you; that is exactly why I noped out of management and decided I'm perfectly happy to continue living at the bottom of the org chart.
It seems like one of the great tragedies of tech is that the kind of personality and temperament that would predispose a person to being able to genuinely enjoy this kind of work probably also tends to greatly diminish that person's chances of ever being promoted into a position where they'd be asked to do that kind of work.
We've been building https://plummail.co to tackle the problems with CC and BCC. As well as other problems with remote communication.
Slack was a disaster for us when we last tried using it. Several people muted it for hours at a time, the only way to get someones attention was to call. By which point it was probably important enough to warrant a call.
Our theory is that for people to be able to focus on work for reasonable periods of time you need good async communication. And for that need good sync communication for where it's appropriate.
We've been using whereby.com for video calls, much better than zoom. This is where we all checkin and Sam/Pat find out what the need to keep an eye on, and then they can start a thread on plum mail for the content they need to keep track of over time. One of the favourite features we have build from a manager side of things is the following.
A manager can join a conversation, but then set the notification level to be only notified when a conversation is resolved, i.e. they find out the conclusion and can see the history if they want, but the aren't distracted by the discussion towards the conclusion
What's worked for me is 1-on-1 meetings with each team member each week. We set strategy for high level goals (e.g. a quarterly software release), measure progress, and I let them know about work other folks are doing that is related. I trust them to use slack/email/phone to get the work the done, and I don't closely monitor those channels.
Doing 1-on-1s is a lot of meetings, but I don't think as a manager you can avoid that work and still move effectively towards a larger common goal. Eventually though, a lot of people learn to execute more complex and valuable work, they get promoted, and then we meet less. But then there's hiring. The cycle continues.
I'd be interested to know how folks who have 2 layers of reports learned to work effectively with that size setup.
The problem with only talking once a week is that you miss things that aren't volunteered in the moment.
You should be collecting agenda items all week by listening, and then discussing them during the meeting.
Also, waiting for the meeting and sharing information live is both laggy and a waste of face time. Share the info in advance, and ask for follow-up in meeting if needed.
> I suspect that an old-school web forum like phpBB could work well, but any technical merits won't overcome the social perception. There's just no getting around the nerd factor there.
So, how do we "sell" forums to our friends and colleagues without them knowing they're using one? :)
If forums are inherently useful and the issue is just perception, then this sounds to me like a design question.
Don't get me wrong, I miss the style of conversation predating social media, but I think that if the reason was purely perception based, we'd find a solution. Think of any annoying, seemingly useless, or just impractical rituals we follow every day.
Forums provide a much better signal vs. noise ratio due to its async nature and increased effort required to submit content. And, that's great.
But, it's also terrible, because most people just won't bother putting more effort into written communication. This is too much friction. This isn't how we talk any more. And, I think that's the main reason why forums are not mainstream.
Forums aren't really more inherently "old-school" than instant messages.
A flashy new version of AIM is popular, a flashy new forum could be too.
I think the difference here is that forums were popular for communities where people were active at different times, while chat was real-time. For in-person offices, things then trended after the physical real-time nature.
If people stay more remote after this, though, and time zones are less uniforms, I think that's ripe for a change.
The most immediate way Slack is more "flashy AIM" than "flashy forum" is that threads don't bump back to the top when they get recent activity.
If someone replies to someone else's message in a thread and it scrolls off my view, they could have a 50+ message conversation in there that I would never see.
In a "traditional" forum, if a topic is that hot, it'll stay on top of the topic list. Even in a more threaded forum like HN, where ordering is done separately, when I refresh, I'd see there were more replies on a hot sub-thread, in a way that can disappear entirely in Slack.
I wouldnt be surprised if there are startups out there working via discord and just passively mentioning what they are up to as if they are playing a game.
In person, it's somehow easier to tune the office chatter in and out as needed to keep track of what your colleagues are up to. I have yet to find an electronic replacement for this phenomenon. Email, if nobody thought to CC you, you simply won't find out. If people deal with this by defensively CCing everyone, you drown in email. Slack's value is inversely proportional to its uptake: The more people talk on it, the more it resembles a sort of workplace Twitter where it's simply impossible to try and keep track of what everyone is saying, so you give up and resort to only looking at it when you're trying to slack off. Threads attempt to work around this by replicating the problems of email in a chat app.
I suspect that an old-school web forum like phpBB could work well, but any technical merits won't overcome the social perception. There's just no getting around the nerd factor there.
The only technique I've seen work well is the manager-as-dispatcher approach. This poor soul becomes the designated firehose-drinker. They get CC'd on every email, and they subscribe to every Slack thread. They keep an eye out for anything that Sam or Pat might want to know about, and check in to make sure that Sam or Pat is keeping an eye on it.