Hacker News Reader

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.

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.

>> 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.)

Oh totally in team slacks, I'm talking more about the "do this as soon as you wake up" DM you types, usually the "Hey.."'ers.

Async is the way to go here. The only time an engineer should have to care what time zone somebody is in is when it's an actual emergency.

Yeah. The engineering team I am on uses the [async] tag to make async Slack communications explicit.

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'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.

You aren't disagreeing, you misread

Parent wrote

>> You'd send out an e-mail update to others who need to know.

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.

Slack is good for chat and quick discussion.

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.

Or just don't use Slack. Use something like Zulip that is deliberately designed to convert synchronous chat streams into asynchronous communications:

https://zulip.com/#tour-carousel

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).

Well said.

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.

Right. Dispatching work with slack is like trying to command an army via town crier. Not a great experience.