I've been thinking about this a lot lately, and while daily meetings are nice, once you start to go beyond the bounds of "yesterday I was working on ... and today I'm working toward ... could you provide a bit more help and/or context on <such and such> ..." the discussion balloons beyond a reasonable check-in limit with regard to time.
The properties of communication in remote work seem very hard to crack and I'd like to know if this problem is something your team has succeeded at – and, If so, how?
Edit: To be sure, I'm not talking about alerts/system critical stuff. Additionally, I work in a small company, so maybe there are safeguards for this kind of predicament in larger orgs.
Thanks
Slack is great for small insignificant chatter but developers need long uninterrupted periods of quiet to work. That doesn't go well with an IM system that people expect to get big questions answered or key decisions made with.
If the team needs to discuss a key decision everyone should be given time to digest the information at hand and respond. That might be in a synchronous meeting or over an asynchronous email but either way people need to have time to think and contribute. Slack prioritises whoever is first to reply and no one wants to read a 50+ message thread to figure out if they have relevant input.
If someone external to my team wants to ask a question thats of any significance I'll try to jump in and set their expectations. If it requires input from multiple people on my team then it's best done over something slower like email / collaborative docs, or as a last resort a meeting. If it's internal to the team I'll try and push it out to a mechanism that allows people to set time aside to consider the topic and respond.
Most questions in and around the team are small and less opinion based. How does X work? How do I do Y? When did Z change? Anything like that is usually fine to be answered by anyone when they get a moment and doesn't require much input from the whole team, Slack is totally fine. To help out I like using the slack action thing for when someone joins a teams channel to let them know that it could take a bit to get an answer because the team may be focused on something else.
As you say, emergencies are different. Those are raised via alerting of some sort and interrupt people in a different method.
My personal belief is that Slack provides a perverse incentive to reply quickly, rather than thoughtfully. There's a time and place for quick communications, but the majority of discussions I have over Slack feel that they'd be better served by thoughtful requests with equally (if not more) thoughtful responses.
E-mail was great at this: the extra overhead (if it could be called that, but I digress) of writing an e-mail encouraged information density in that e-mail - I want to convey my point in the least number of round trips possible, and likewise, have my question answered in the least number of round trips possible. Slack does away with this; round trips so easy as to be common, and in fact we have sites like nohello.com showing that the trend towards round-trips isn't helpful.
But they want to read a long e-mail thread?
Other tools can work as well like shared documents if the content/context is several pages or something.
Slack is very distracting. I surprise some people saying I am pushing every meaningful convo out of slack and hopefully one day to completely scrap it and throw away.
Emails are way better since it pushes people to think the problem first, and you'll be surprised how many problems have found solution before "Send" button is pressed.
It's easier to just send something like "Hiyo Mark, hihi! Wazzup?". This is where it gets dangerous to performance and focus.
Back in the days of IRC a lot of people thought lack of history was a "missing feature" but now we have it with Slack I think it was probably the best feature of IRC. When the platform has no memory you're often pushed away from it for anything that's deeper. No one can come along later and find your messages so you know you can't put anything that requires wide visibility or input there.
I'm not going to shill for IRC and say everyone should go back to it or anything, it's not really practical. But that said, I do think Slack has a huge flaw in it's design of making it so easy to send messages and pretend everyone's going to see it.
We're facing this problem at the moment, with Slack being heavily used for almost everything.
Main difficulty is changing culture around its use - there are plenty alternatives that we push people towards, but they tend to get ignored in favour of Slack since asking is easier there.
I suppose it's important to say don't be militant about it and allow discussions to happen a bit to really see if they're shallow or deep topics. Shallow topics are fine for slack because you probably only need a couple people's input. Deep topics where you specifically want the whole team are the ones you want to pull into something slower moving.
Trying to change habbit is tricky so it's a case of slow errosion of the old habbit with the new one. Eventually the team started to make those kind of calls themselves, and newer team members picked it up quickly as well.
Throwing up a quick discussion point on a slack room while you are acting on the idea is perfectly fine. Just as it could be perfectly fine to toss the code if the idea doesn't pan out.
Then another slack discussion is posted with a v1 proposal in it, and link to previous discussion. This time, more people can give dissenting opinion. If nothing conflicting, a short sharing session will be held presenting this, and see whether there's dissenting opinion again.
I think a bit of it boils down to each team being different as well, if you need a team to be more agile then using slack more might be the right thing. In OP's case they sound like they need their team to slow down and consider some things more deeply and slowly. In that case pushing those topics out of slack may make sense.
This clearly doesn't scale for large orgs, but any communication method doesn't anyway. One clear advantage of this is the low entry barrier: You don't have to worry about interrupting and shutting down the ongoing conversion unintentionally, or spamming others.
Although this barrier lowering seems to be helping a lot in the highly peer-aware environments like Japan. I'm not sure how effective this is in a different context. So take this as a grain of salt.
I tried sending you an email but it bounced!
But people are afraid of e-mail. Will anyone ever read my e-mail? When will I get a response? What if I mess up my message? It is unknown, immutable, does not provide instant gratification. I want everything NOW. So Slack was created to poorly reinvent e-mail, but with instant gratification and emoji buttons.
I really love open source mailing lists. Every once in a while I'll go skim over some I'm subscribed to and see what's been going on. If I ask a question I usually get an answer within a day or two. The archives provide searchable record/context for everything. I can even review patches and comments on patches, and see the history of all the e-mails before/after it, whereas GitHub PRs are little islands unto themselves. Best of all, it's all stored offline, and I can use any client I want.
It's sad that technological progress means 'things got more advanced', and not 'things got better'.
I disagree. Email is a terrible medium for collaborative editing/creation of a document (whether source code or human language).
In my experience email is best when audience is less than 5 and have a tightly shared context. I've seen innocuous looking proposals getting out of hand just 'coz people jumped in to respond; multiple threads forming and so on. It gets nightmarish very fast.
I've found a combination of shared docs + meeting to arrive at consensus to work well. A small group of people propose a design/solution in a doc. Share it with wider stake holders get their first round of feedback, incorporate it in the doc and then have one or two in-person meeting(s) to get them all sign-off. Slack could be used to have short conversations but not ideal from what I've experienced.
This is with respect to a a for-profit organisation. Can't speak about open source as I don't have any experience collaborating there.
It's a red flag when you're attributing a negative quality to people as the reason why they use or even prefer something. The cure is simple: talk to people and ask them.
The callback is very important IMO because things get lost in email all the time. And yet you don't want 5 people to reply "noted".
Similarly for asynchronous, historical record, threading, and inclusion.
You can add emoji to email as easily.
Instead, we have a company-wide BookStack instance that's the primary store of documentation, split into different sections for project information (per project) and rough notes (per employee). Everyone is expected to contribute to the former, and may also add to the latter if they wish to share something that may be useful to others.
Usually, helping someone else out with the information they need involves pointing them to the right page where it's already documented, or writing something up for them. Perhaps also talking them through it one-on-one if it's complex.
This works for us because we're required to provide reports to our customers every few weeks, in regards to what we've been working on in the each contract - in addition to any actual deliverables. Keeping everything well documented internally makes it much easier to document for our customers.
This is a small company of around 40 employees. Not sure how well this will scale as we grow, but it's been working well so far.
It shouldn't replace tools like BookStack, but nuking it every 2 weeks feels like its losing genuine knowledge too
How do you determine historical truth in a potential conflict scenario, where a manager says "why didn't anybody tell me we'd be running a test at the customer site?" and the engineer says "but I announced it two weeks ago and you even thumbs-upped the post!"?
Or it's being wiped because your leadership team doesn't want anything shady uncovered in discovery or a warrant and "we do it to discourage anyone from using it as a knowledge store" is how it's being sold to everyone else.
My team’s current systems: - Most deep discussions happen on blog posts including project status. We use (and built) https://wordpress.com/p2/. We don’t use email. - Start of week everyone prompted to post what they did last week and what they plan to do this week. Also have a kinda fun ice breaker question that is easy (e.g avoid asking about favorites) and sometimes generates discussion. Last week was “Pick an olympic sport to represent your life.” - Daily Slack prompt to give folks a place to report on yesterday/today. The most important thing is how people feel though. “Pick a red/yellow/green emoji for your status” and “What feels risky or a blocker?”. Create space for feelings. - weekly team meeting is then about discussions and never about status. How do we solve X? How do we feel about Y? - debugging and such does occur in Slack but longer discussions are on blog posts/comments and so can be long. - I do 1-1s weekly for new folks and bi-weekly for longer term folks. Encourage sync 1-1s between the team also.
A lot of the prompts can be automated. I dont consider them mandatory, if you get them right then folks will be happy to do them because they feel the utility of them.
https://ma.tt/2020/04/five-levels-of-autonomy/ Is a good read too.
Iterating is very important though (which you are doing yay!), I’ve tried lots of different cadences/systems but the above is the core of what my team has used for 3-4 years now and I’m pretty happy with it. I still try to make sure we reconsider if we want to experiment with something new every few months. Partly why I wrote this long comment is I’m thinking if there is anything to tweak.
Your proposal is a cool idea, and there are even self-hostable FOSS clones available.
See: https://meta.stackexchange.com/questions/2267/are-there-any-...
Self-answered-FAQs
We typically call that "Documentation!" :-)
1) People should avoid DMing each other when talking about work, use threads instead (see 3) to discuss topics in team channels (see 2).
2) Keep channels to a minimum. Every person shouldn't have more than 2/3 channels they need to pay attention to. A private team communication channel (eg #dream-team) and a private work channel (eg #dream-team-engineering) is enough for most teams. All team members are in the private team communication channel. A work channel is specific to a domain, such as engineering. Example you don't want engineering work banter to distract those working on other stuff.
3) Use threads religiously! This is super important as it helps declutter the Slack experience and keep conversations heavily organized.
Instead, what's done is done, and it can lead to rapid degradation in communal rooms that have a lot of newcomers.
- Daily standups on Zoom. Each person's standup should be short and to the point. Don't be afraid to tell people they're getting into the weeds. If more open-ended discussion needs to happen, interested parties should either 1) stick around after standup or 2) schedule a new meeting to discuss in greater depth 3) start a Slack thread to discuss.
- Weekly code syncs to go more in-depth as a team, make sure we're rowing in roughly the same direction, and knock out decisions in minutes that would take days on Slack. This is especially valuable when building new products or refactoring.
- Weekly office hours held by senior+ level engineers to give more junior engineers an opening to ask questions.
- Weekly architecture meetings to formally discuss sweeping technical changes that impact multiple teams in a meaningful way, e.g. migrating to a language
For me it has been less about "email bad" or "Slack good" and more about asking questions - "What is the right medium for this type of conversation and our culture as a team?" or "What is the right tool for the job?". It's also an answer that evolves as the team/company grows; you have to reassess every few months and make adjustments.
There's also a question of culture and setting expectations that might be at play here.
- For the people answering questions, are they passionate about teaching? Do they feel incentivized/recognized for being active in answering questions? Do they have the bandwidth to help others?
- Are those asking the questions asking good questions? Are they respecting the time and attention of those trying to help them?
But I will say that Zoom integrates nicely with Google Calendar, offers video, and like you said has a higher limit.
We're also experimenting with doing standup three days a week so we can have less time spent in meetings each week.
Many good replies here about what Slack is good for and what it’s not good for, but I wanted to take a moment to reflect on this part of the premise. The properties of in-person communication have always been hard to crack, and having everyone remote makes it that much harder. This is not an easy problem, regardless of the tools. But if people aren’t getting what they need out of Slack, it’s up to the team and the leads especially and the whole org to identify, discuss, and solve communication problems. This might be educating ICs about what to do when they don’t get responses, it might be about providing a system to escalate questions as needed, it might be about picking and choosing different communication tools.
In addition to some of the Slack problems others have listed, in the last two years, I’ve experienced a lot of: 1- new hires being very afraid to speak up in larger groups, they prefer to DM someone who’s friendly and receptive to interruptions, and especially prefer to steer away from asking questions in channels that their boss/manager is in. 2- Slack is pretty terrible for retention and searchability of info after a couple of weeks, it’s just kind of a void when it comes to keeping or tracking important information.
It’s great that you’re thinking about it a lot, because most people have reflexive opinions without a lot of careful thought. Communication is a hard problem, and it’s worth internalizing this and realizing that there aren’t easy answers to this nor single tools that will magically solve it.
It’s natural to answer “I am blocked” with a dive into the solution, but really you should just use the standup forum to figure out who you need to talk to, and circle back to discuss immediately after the meeting.
If you already know who you need to deep dive with, you should proactively sync with them before standup; that meeting is really just there to provide a cap on the amount of time anyone can spend blocked.
If everyone self-organizes to resolve blockers before the next standup then congrats, you have graduated and perhaps you don’t need that meeting daily any more.
It’s worth noting that in the “yesterday, today, blockers” format, the first two aren’t really needed if you just radiate context passively. The main value of the meeting is syncing on current/future blockers/impediments.
Finally I’d say a document-centric workflow can help here, because if you are all collaborating on design in a doc, then it’s easy to follow along async and see the latest state of the discussion, rather than having to read and understand every comment in Slack to keep up with the situation.
This is a hiring problem. In short, the people you work with lack the ability to understand why it's important to respect their colleagues and to write better answers. Teach them to communicate better.
Also, the importance of good communication needs to come from the top. Seniors need to spend the time and effort writing good answers, and making sure replies from others are appropriate, adding a "Could you expand on this?" where they aren't.
If that fails, tell people to schedule more meetings. Face to face and video calls solve the lack of depth incredibly easily. You can't give a shallow answer if someone is literally asking you for a deeper one.
And if people push back on that, the answer is to replace them. People who aren't good communicators ruin team dynamics quickly. Hire for comms.
In a business, building good software is 50% about writing simple, understandable code and 50% communicating with other people so they can write simple, understandable code too.
The real replacement that slack is, is for crappy emails and crappy phone calls and crappy meetings about nothing. Not a replacement for communication as a whole.
Forum posts will frequently include a link to a Slack discussion, but I don't think anyone really clicks to read the chat.
This is not exactly what you asked, but peoples' managers are on the hook for helping them be heard. One-on-ones frequently trigger forum posts. Good one-on-ones are useful for this kind of thing.
But, assuming they are already asking good questions and just not getting good responses, they should instead be asking for a synchronous meeting with the other developer. They should be pairing, or screen sharing, or at the very least looking at each other when they talk. An ad hoc 15-minute meeting is a slight pain in the ass, but better than a Slack conversation spanning 2 days, followed by a 25 minute retrospective discussion on what went wrong.
Try to make it part of your team culture that, when somebody is blocked, anybody who can help them needs to put down what they're doing and unblock them as fast as possible. This was a firm rule on the most successful team I ever worked on, and I have carried it forward ever since then. It's better for everybody if they can expect to get help and are expected to give it.
Within the team, we use daily stand-ups. Start out with the normal “I did X, working on Y” stuff, try to get that done in 10 minutes (for a team of 6 + manager + occasional BA or tech fellow dropping in). The rest of the 30 min block is open to whatever the team needs - stuff that if left to Slack would end up being a multi-day game of telephone.
Outside the team, Slack is ok for starting conversations, but generally anything important or hard needs a live meeting, even if it’s only for a few minutes. We have a few channels that are exceptions, where the team that “owns” the channel is better than average at making well reasoned responses. But, that’s the exception and those teams are always a pleasure to work with. And this is in a reasonably well functioning mid-sized company. I hate to think what it’s like at a large company.
A thread isn't that much different from an email chain, reading any of those that have gone off the rails is deplorable. Instead, encourage more concise proposals and rebuttals
Anything too in the finer details can be taken care of elsewhere, then the findings reported back
I wish my team met less often in a structured way. I don't really benefit from giving status updates or hearing theirs.
I'm not some lone wrecking ball, I just have responsibilities for services I designed before joining this team. We also don't really have much overlap. Maybe paired off on something
I feel that our more involved conference call time would be better spent on specific implementation problems or similar - with a smaller audience
I wonder if anyone has tried using a private subreddit for team collaboration? I feel like it has the opportunity to be a great asset. It's free, persistent, searchable (ish), supports threads, images/links/markdown, and even nice mobile app support.
Probably because as part of spinning back up I have to summarize for myself where I think I was, and the summary frequently contains the hint I missed. It’s not quite rubber ducking without the duck, and with more time to help others.
In my team we do these on Monday/Thursday. If something conflicts, we just bump that checkin forward a day to Tuesday or Friday.
Coming out of hacker IRC culture, I can keep up with anyone, but that puts some very thoughtful people, and therefore the team, at a disadvantage to what makes "good chat." I've seen it become a source of drama precisely because a normal team has a lead who sets the tone, but the equalizing nature of chat has the effect where it can both elevate dumb stuff and diminish important stuff, there's a mean reversion where the medium itself becomes the message. When it's good, it's very efficient, but when it's obligatory, it creates simmering rot in teams. It's amazing to have ideas stand on their own - but when it doesn't present the full person with them, the best ideas are no longer neutral - but rather assigned to our preconceptions about a person behind them, without providing them the tools to set tone in a way of relating.
We have to assume good intentions, but in an org, that's mostly performative, and the necessary altruism to sustain that doesn't scale. The reality of ostensibly flat organizations is that they are constant power struggles to extract value from each other (manage others), based on the ficton that the result is somehow organic leadership that produces authentic buy in and consensus. It's not. The necessary condition for value in a low-information medium like text or chat is shared purpose and aligned incentives. You need trust above all, as without it, text amplifies mistrust. The question of what facilitates that trust is the big hard problem. Anonymity and distance provides some trust in informal networks, as the consequences are limited. Text chats I'm on with friends that are absolutely private have trust that originates in friendship. Trust in on a team or in an organization is the fundamental problem to solve. Who can you trust, and for what? A single hub-spoke leader everyone trusts is the baseline, and the ideal is a complete mesh pattern of trust. Without something on that spectrum, your team is default dead. Low trust chat is lame and harmful. The best companies and teams have a relatively high degree of mutual trust as the result of aligned incentives.
When it goes to shit is when we're forced to pretend to trust each other, and then you get institutional bureaucracy politics, which async and text just amplify. I'm in a place where it seems to do it right, but I've been in places where they don't. Slack's message stats in the admin panel are a pretty good proxy metric for organizational trust, where if you see lower engagement, I'd bet just from that you have a trust deficit on your teams that is going to be a ceiling on the value they create.
If you gave me a company's outlook and slack admin panels, I would be able to tell you in a few minutes where your culture bottlenecks were. What people trust can be easily codified as well, but that's a tangent. Where I have seen Slack succeed is where the team has a basis for trust, and where I have seen it fail and become radioactive is where that trust was undermined because of a power vacuum and people defecting to where they think will prevail. Those are hard conversations becuase a lot of managers and employees personalize and moralize their position as being the effect of their identity, where they have internalized the status without a lot of examination of the practised skills it takes to do it well. Slack and email are neutral, but they are also extremely sensitive to deviations from alignment, where interpersonal conflict happens within the vast imaginations of the participants, and not in the real moment of dealing with another person.
Daily meetings suck. Do them less frequently and allow for more time to talk about things.
"stay on after the meeting and we'll talk about that"
or
"why don't you and x meet up later to discuss y"
Making sure someone gets heard in Slack isn't a top priority for me. It's surfacing information and solutions as fast as possible when they come up. Solidifying them in Notion is something a subject matter expert can do outside of the time constraints of a real-time conversation then the rest of the team can surface those answers as needed and mark where they fall short with comments in or additions to the Notion doc.
It is great for communicating around an event. Getting quick in-flow queries answered. Asking what people want to do for lunch.
It is not for substantial nuanced in depth communication. When used this way it quickly becomes a conveyor belt of distracting trash.
It is also not a knowledge repository or source of truth. Slack overflow is not a good practice.
Pro tip: have slack history clear after 60 days.
Better alternatives: - Shared Google Doc with comments for analyzing an issue - Meetings with a pre-read period and memo and clear purpose/outcome for the meeting - Pair programming - Live code review
TL;DR Dont use slack.
I was on a ski lift last winter with a guy who ran a small company (~20 engineers) who banned Slack and I think he had a strong argument.
Reading through the comments, I see a number of antipatterns emerging from this thread. I'll enumerate some:
* Urgency etiquette: @channel, @here, or just plain message? How about @here with a few personal @ throw in, which is like the gratuitous CC: in email? This depends a lot on your org's topography. I do contract work for a global org, and @channel is almost never appropriate. It's kind of looking at alerts as an SRE: does EVERYONE need to know this?
* Search really is terrible: I know people say "just search Slack". Reminds me of a former colleague who joked about "Google Battleship" (referring to the guessing game of Battleship), where you hunt for the right combination of words. Some questions are just hard to answer via context-free text queries, and this leads to the next point
* Atrophy of other documentation like Wikis and READMEs. The big problem with Wikis is that they have to be gardened - they need dead pages removed, outdated info updated, etc. Slack also needs gardening. The 2 week ban is draconian, but I imagine that in this org, people start moving important information to permanent storage.
* Private channels are unsearchable, as are private conversations. I've personally banned my private conversations. People DM me about comments I've made on a PR, rather than responding in comments or a public channel. I always direct them back to a public comms channel. The idea of Slack is to make communications public and searchable, but people need to enforce that individually. I don't allow DMs except for social BS like lunch plans.
* On the flip side, information-free channels. Some of my channels at work are completely noise - basically all they are is alerts from PagerDuty, or automated build noise, or the #fyi channel for all employees. Anybody who cares about "slack zero" mutes these channels anyway.
* Somewhat related to the last point, the auto-responders. At its simplest, if you have an auto-responder keyed to a single word or phrase, that indicates a problem, not a need for an auto-responder.
* Final point is info fragmentation and overload. You don't know what channel to ask a question in, and you can't keep up with it all. I have a personal keyword filter, but basically in Slack, I've created a personal info silo simply to be able to have a chance to focus on my work.
jk don't :)
^ Arrest this man or woman!
teammates still see it without @everyone, do they really need to be disturbed for this message?
