Async communication is suitable to resolve some kind of issues. But it has two drawbacks: participants need to be competent at writing and reading prose (it’s harder than it sounds) and even with the best of care your ideas can easily be misinterpreted resulting in the loss of an async cycle.
For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out. A remote meeting can work too.
The problem with meetings are those which are not well prepared. There shall be an agenda and proper minutes should be produced.
For most complicated matters actions/investigations are supposed to be followed up. In a way that’s how you mix async with sync communication.
Recently, I was so frustrated with some folks poor reading comprehension that I was thinking about an imaginary communication system that would allow for decision making where there were some rules:
- No responding from mobile devices. The poor response rate is just too high.
- The reader is quizzed on the the contents of the communication before they can respond (randomly generated quizzes might be amusing).
- The reader has to retype the original communication themselves before they can respond....
- Timeout value, if no responses that pass the above tests in a given time frame, whomever asked gets to complete the task with no input and nobody can change the outcome for ... a week or so and everyone has to live with it.
- Anyone who wants to change it after the timeout value better explain why they didn't ask before hand... no idea how this would work, yeah we're getting into the weeds here.
Of course, these are all unworkable in a modern business environment but man ... I can dream that some folks would who make demands or provide input at least put a minimum amount of effort into things before they throw their given wrench into the works.
Bullets 2 and 3 combined are actually recommended for spoken communications as well. As the listener, before responding, it's a good habit to say "This is what I understand about your proposal" and proceed to summarize and give the original speaker an opportunity to correct you.
Probably over half of the communications problems I've seen at work are because people don't follow this basic practice. They respond based on what they understood, not based on what the speaker was saying.
As one book I read put it: You should be able to reflect their world view back to them as if you yourself are advocating for it (even if you completely disagree). When you do this, they'll believe you understand them. For many people, only then will they listen to your critiques.
There's also a subtlety where if you focus too much on what someone said, you might lose why he said it and how it pertains to the situation. I've gotten through some communication problems by focusing on how I understood the person's position, instead of what the arguments he brought forth. When you do that you get this funny situation where it almost seems like each person is participating in different conversations, but at the same time the discussion is progressing effortlessly. I think of it as letting yourself be free to frame and reframe the issue at hand however you like.
> As the listener, before responding, it's a good habit to say "This is what I understand about your proposal" and proceed to summarize and give the original speaker an opportunity to correct you.
I find a practice like this is also helpful for following up after a meeting. For meetings that warrant my taking notes, I like to type them up immediately afterwards, send them out to the other attendees, and solicit corrections or confirmations while the meeting is still fresh on everyone's mind.
It was a bit scary when I first started doing that since I'd fear that I might have misunderstood something and would be revealing my ignorance. But to the contrary, I've found that it tends to encourage others to share their notes for comparison and elicit further discussion. (If there's something I've misunderstood from a meeting, usually someone else was confused too.)
The problem that I found with it, is that a recurring receiver (let's say a client) will eventually start trusting your minutes so much that they don't even bother to read them and just answer with 'Looks good' and basically you lose the power of minutes.
To counter this, recently I've been trying to insert one wrong bullet point from the beginning, making the receiver pay more attention down the line. I don't have yet enough data points to see if this approach works.
I had managers -do-this- (repeat what they understood as the key element) in meetings and thought of it as a very annoying waste of time. With five people in the room, assuming you do, on average, two rounds per agenda item, there are nine repetitions.
You are right, the extreme value where everyone everytime repeats what was said before, to ensure common understanding, is an unlikely example. My point is that repeating information already present lowers information density. The "good habit of repeating what you understood" can quickly become very annoying.
> They respond based on what they understood, not based on what the speaker was saying.
Lets say there are three main steps in responding to communication: 1. Comprehension of the original communication. 2. Mapping that communication onto the reader's priors. 3. Crafting a response that communicates the results of that mapping.
The problem seems to be that the first two steps are typically left implicit indefinitely. As a result, there can be discontinuities lurking hidden in or between any of those three steps and it's a hell of a lot of work to pry those discontinuities up to the surface.
FWIW, it doesn't have to be a "new communication channel", you just documented some best practices for email.
> No responding from mobile devices. The poor response rate is just too high.
If something was left implicit or de facto re-ask for it to be explicit or de jure.
> The reader is quizzed on the the contents of the communication before they can respond (randomly generated quizzes might be amusing).
> The reader has to retype the original communication themselves before they can respond....
A simple "What's you're rationale?" or if you're less confident "Sorry, I understand the action items and can execute them but I didn't follow the motivation. So I can do an even better job (or so I can make this decision without you next time), could you walk me through your thought process?"
> Timeout value, if no responses that pass the above tests in a given time frame, whomever asked gets to complete the task with no input and nobody can change the outcome for ... a week or so and everyone has to live with it.
> Anyone who wants to change it after the timeout value better explain why they didn't ask before hand... no idea how this would work, yeah we're getting into the weeds here.
This is the most important email best practice that trips up junior workers. Make the default of your email your desired outcome.
Instead of: "Does everyone approve?" then if people respond asking "Ok, when should I do it? Thursday?".
Try it like this: "I'll make the change on Thursday. Please let me know if there are any concerns.".
1. Make the default response (i.e. no response) in your benefit.
2. Ensure there is a timeout value attached.
None of this is difficult or theoretical, its just a set of best practices you can get your self and others used to.
Oh man, I hear you. The amount of sad encounters (especially lately) that I've had as a result of people not understanding what I'm saying because they don't actually read what I wrote are enraging. I almost quit one client over it because their IT guy is the worst. He will decide ahead of time what your email probably says, and that's what he reads into it even if I wrote the opposite.
I try to blame myself first for poor communication, but I asked some mostly independent people to help mediate and they basically came back and told him to read better and review past messages if he couldn't properly remember the context.
I'm just starting to dip my toes back into the freelance web development world, after deciding indie game development wasn't for me.
My main problem with clients has always been 1) They don't really know what they want, beyond "a website", and 2) The reading comprehension of pretty much everyone I interact with is surprisingly low. I've mostly dealt with small-business owners, whose personalities seem to veer towards the eccentric.
With my current client, I'll send out emails requesting clarification for certain features that need to be implemented on the site. If I'm lucky, I'll get an email back with at least one of the issues having been addressed. There's been emails where the response was in no way relevant. At one point I even got a photo of someone's backyard sent to me as a response.
I've learned to only send him a single line of text if it requires a response, to increase my chances of getting something I can act on.
I really like making web sites, and programming in general... It's just the frustration of poor communication that makes the job so frustrating. I think if I were more of a salesman/people-person, I would probably be better about figuring out what they really need, and offering solutions to them... rather then just getting upset that they don't what they want.
I've seen people like this doing day to day business: it's absolutely awful. They attend meetings starting with software and ending up with elephants.They can't sit for more than two minutes and there's always phone, email, whatever. To expect for such a personal to produce a written piece on what they want,while they can't even do it verbally,is impossible. These are usually somewhat successful in some sort of a niche but would drown in any other environment.
I see similar issues with support emails. One thing I learnt is to never ask more than one question in an email as only the first question gets answered.
I’m sure it has been getting worse over time. I’m at the stage where I am surprised when I receive a coherent request.
Probably the most common question is “I tried you software, it don’t work”.
Not without loss of several significant subtextual channels: respect, clarity, and intent to name a few. Communication is a discipline; verbal shorthands like these are analogous to copy/paste laziness over thoughtful, intentional code.
> I was thinking about an imaginary communication system that would allow for decision making where there were some rules:
> [...]
> - The reader has to retype the original communication themselves before they can respond....
In email (not following Outlook/conversation style) and newsgroups, people would trim the original quoted material down to what they were responding to and then type their responses inline. While that would, in a way, meet that requirement, it could still lead to people responding to selected parts of your message while missing other parts. But, that would allow you to reiterate the points they didn't address in your subsequent response.
Yeah, it's really unfortunate that inline replying effectively died out, replaced by top-posting. I think inline replies, while lending themselves to the selective quotation problem you mention, nevertheless force more careful consideration of the original text.
I'm not even sure selective quotation is really a problem. Selective replying happens regardless of whether they are quoting or not, but is just more explicit when they are documenting which parts they reply to.
I agree. I still do this. But nowadays lot of people feedback that they do not understand my way of replying. Compared to many of my early digital acquaintances I was socialized quite late on the internet starting in 97. Compared to my colleagues I often feel old and out of sync with my style of long form written communication.
> nowadays lot of people feedback that they do not understand my way of replying.
Some clients, like Outlook, will actually collapse the original email and only show the top-posted reply. An inline reply would appears as an empty email in their client.
> - No responding from mobile devices. The poor response rate is just too high.
For me, the tendency of slack to let users write very short sentences/phrases is the issue. Etiquette for slack allows very IM like messages, whereas Emails are generally required to be more verbose.
It's probably a question of personality, custom and habit, but I tend to write like I speak (some would say "no, you speak like you write" :-) in any forum, including Slack, sometimes in defiance of the cultural norms of the audience.
It leads to something of a reputation for verbosity, but never the accusation of ambiguity or excessive terseness. I don't think anyone's ever said to me, "What did you mean by that two-word reply?"
You could only have such a system in an environment with a huge power imbalance between the sender and recipient, like Tim Cook sending a message to an Apple IC engineer. But with that kind of power imbalance all of these things happen anyways -- if an individual engineer gets an email from Tim Cook he definitely isn't firing off a poorly-thought-out reply from a mobile device.
I sort of see what you're saying. When a person with Great Authority says that Something Needs Doing, I need to think through what I'm going to say about what I'm going to do. But the single best response is to spend those fifteen minutes seeing if there's an obvious solution. If there is, you can be quite terse and just say: "done". Do that five times and even Tim Cook has your attention.
No, actually the opposite is true. The whole idea of any policy is to give artificial "power" to one side to straighten out the situations where the balance of power is unclear.
An exec (the remote-only version of Tim Cook if you like) can use their leverage to change the existing email flows between all managers and all engineers. Because it's more scalable than micromanaging one engineer.
In other words, some people are good at organizing through setting policies (the better sort of politics) and it's a good place to discuss such ideas.
Parent's formulation doesn't look convincing though :)
I hate this approach (even more so when I was involved in writing the written communication) because it usually turns into idly waiting for others to finish reading, while I get distracted, bored and just plain could be doing something more productive.
I understand the concept and some people must find it useful and valuable, but I’ve personally never got anything of value out of it other than making sure everyone has read the content before the meeting proper starts. Personally, I find asking somebody to attend a meeting, where 20 minutes is just silently reading, rather disrespectful of their time.
Hi! I recently opened my quiz generation service to public. Would you try out the quiz AI assistant at https://QuizRecall.com and let me know what would you need to be added to make useful also for your use case?
>For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out
Easier in what way? I think it makes people less frustrated by having to think hard about a hard problem, and feels "better" when everyone is saying what they think without any barriers, but I would guess it's much worse at arriving at good solutions to challenging business problems. Especially in the case you describe, with many decision points. I cannot fathom how a group of people chatting can efficiently work through many decisions at once, without laying it all out on paper anyway, whether it's before or after the fact. None of the meeting conversation matters unless you have someone taking good notes and summarizing decisions. Which makes me think, why not just start with the writing part? How is one person's notes about what a bunch of people said during a real-time conversation going to be even remotely on the same level as the people themselves composing their thoughts in writing? The in person meeting just seems like a space to share emotions and make shows of power in front of others.
I think async writing is much better (obviously nothing's perfect) for removing emotions from the discussion and forcing people to spend time thinking through their thoughts. The act of composing a written email, or composing a one-page spec document can do wonders for people ironing out their own thoughts and ideas.
And CC (+BCC) is, imo, the greatest business tool being dropped nowadays in favor of synchronous comms. CC keeps people informed without wasting time or disrupting schedules. It also allows the bosses to keep a much better handle on the comms culture of the company, since they obviously cannot sit in on or observe every meeting.
In person meetings have plenty of specific use cases, but I don't really understand the drive to make critical decisions synchronously in the moment during a meeting. Meetings are great for presentations, Q&A, gathering feedback, etc.
> and feels "better" when everyone is saying what they think without any barriers
Except there are barriers: People can tell you immediately that they don't understand you before you go off and speak for too long. Whereas with asynchronous, you could write a large amount and people won't be able to comprehend it because you made a mistake early on.
> I think async writing is much better (obviously nothing's perfect) for removing emotions from the discussion and forcing people to spend time thinking through their thoughts.
I agree on the latter, and disagree on the former. Rarely have I seen an important decision being discussed async that is devoid of emotion. With async, emotions are harder to gauge. This does not lead to people giving others the benefit of the doubt. It more often leads to people misreading emotions.
> And CC (+BCC) is, imo, the greatest business tool being dropped nowadays in favor of synchronous comms. CC keeps people informed without wasting time or disrupting schedules. It also allows the bosses to keep a much better handle on the comms culture of the company, since they obviously cannot sit in on or observe every meeting.
"You know how many emails I get every day? Do you think I have time to read every email I get?" spoken by every manager/senior engineer in my company.
(Although I'll admit, I prefer email to all other async comms I've seen. Pseudo-IM stuff is the worst).
There are, for sure, problems with both forms of communications. Conducting good "live" discussions in a room is a skill, and most of the participants have to be proficient at it. The same will go for async communications.
I think if there are serious, technical/tough issues to discuss, it is best to have it written up, with proper "counter" documents, and then get into a room to make the final decision, with everyone already well informed. It's a rare workplace where that will happen. People will respond to something well written with a one line objection on one minor aspect of the proposal, etc.
1.) Taking notes and summarizing conclusions is massively faster then having that whole discussion in writing.
2.) Most people are not gifted writers and speakers. They have hard time to express themselves properly. The spoken communication is faster and pretty often someone else can help to rephrase it couple of times or ask series of clarifying questions until it makes sense. This process is looong or does not happen in writing.
3.) Quick turn on simple clarifying questions.
4.) Honorable mention:
> The in person meeting just seems like a space to share emotions and make shows of power in front of others.
Emotions and politics are part of being humans. Humans typically need to share emotions and react to other peoples emotions. Someone refusing the idea for emotional reasons is not something exceptional - and typically harder to deal with in writing. It is harder to recognize in writing and harder to respond to in writing.
And I guarantee you that shows of power are crap in writing as much as they are in person. It does not disappear.
> even with the best of care your ideas can easily be misinterpreted resulting in the loss of an async cycle
This is not unique to async communication at all -- it is just becomes more apparent.
I have experienced a lot of sync communication, in which people only seemingly agreed and, when prompted later or as apparent by their resulting actions, quite clearly understood very different things.
There is also the very real issue of people getting increasingly tired and more agreeable during the course of a meeting. In async, when you stumble across something that doesn't gel with you, you might default to taking some extra time to think it through. Poor communication pops out that way. In sync communication you might let the same thing go -- not because of clearer signals or because it leads to a better outcome, but because you want things to end.
It's scary how many posters are missing the fact that writing is difficult Because It Makes Miscommunication Explicit
All the same misunderstandings - and more! - happen in spoken communications and discussions. The only difference is each party leaves without realizing it, and there is no record of what happened. (And if there are meeting notes, they only record the understanding of whoever wrote them)
Depending on the team and communication channel, the cycle time can be hours or even a day (not including weekends), and I think avoiding extra cycles has a significant impact on the way people communicate, whether they realize it or not.
> For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out. A remote meeting can work too.
If I find myself in strong disagreement with someone's statements (and maybe wanting to write an angry rebuttal), I find it's usually better to switch to a synchronous discussion. Most of the time it comes down to misinterpretation that takes 2 or 3 cycles to clear up, and in a sync conversation that can happen in a matter of minutes and with significantly shorter responses than the async equivalent requires.
When you're responding to something in async communication, most people don't want to waste a cycle by just asking "What do you mean by 'x'?" -- and so instead will respond to their interpretation of 'x', often wasting many keystrokes on a misunderstanding.
In a sync conversation starting by asking "What do you mean by 'x'?" is easy and low-effort, and in my experience results a much more constructive and positive discussion, regardless of which side the misunderstanding was on.
> it’s a lot easier to have people in a room and hash it out
IME it isn't because they aren't an environment conducive to informed debate. It's easy to get everyone in the room to agree, but as soon as you get out and check specifics, think the problem through properly, research what's already in pace, etc, you realize the whole meeting was a waste or worse, you've just committed to something sub-optimal/impossible.
An async "meeting" allow you to look for information so it's based in reality not best guesses, it gives you time to read necessary background info and do more research. These ultimately make for better decisions. They also don't waste the time of people that don't care.
> you've just committed to something sub-optimal/impossible
What about never making decisions at meetings -- instead, let everyone think 1 week after the meeting, and make the decision asynchronously? Eg vote via email
> misinterpreted resulting in the loss of an async cycle.
True, but readily fixed with "Can we talk about this when you have a minute?"
Also, losing "an async cycle" is a completely alien concept to me. I've been working remotely for a decade, never heard that phrase, and not entirely sure why it matters. Does a conversation that takes 14 Slack messages make the business less efficient than one that only took 11?
Honestly, I'm not trying to just nitpick, but why would a room full of people be beneficial to decisions "when they verge toward the arbitrary"? Wouldn't that be the perfect time for everyone to send their async opinions, and let a single decision-maker just decide? Large calls/meetings work when you don't know what you don't know - to get all the information on the table, and have all the knowledge in the same place at the same time. You talk, give answers where needed, assign some action items to people, and go back to your async lives.
As far as the initial statement that you must be competent at writing and reading prose... I'd love to hear more about that than "it's harder than it sounds". I've worked remotely with people with dyslexia and reading disabilities and C-level personalities that refused to get in-depth in any single communication. And one guy who had all those traits - the CEO... and it worked fine. None of that stopped us from doing our jobs effectively. You did need to learn how your co-workers communicated, but let me assure you - we were not excellent writers, we just knew our co-workers well enough to know their communication styles.
That is what remote work comes down to, at the end of it all. Not communication frameworks and rules of when to use what communication channel - but getting to know your team well enough that you know how to work together. If you do that, you succeed, whether remote or in an office.
Hmm... I think the idea with synchronous communication is very much the same as it is with with synchronous method calls. Synchronous communication lets you break your thoughts down into smaller chunks and thus make them easier to understand. Synchronous methods do very much the same (at least how I write them).
I like what you say about needing to "learn how your co-workers communicate[d]". Maybe that's the abstraction layer that makes async everything possible. Still a leaky abstraction and I'd prefer not to have it. But it might actually have worked for me over the last couple of months.
The problem with meetings is when they are the default. I find them much more productive when there has been written communication ahead of time. Writing forces everyone to put their thoughts in order and hopefully come into the meeting with a baseline understanding.
Writing works so well in thought organization that part of my own meeting preparation is to write down my thoughts on the topic, even if just for myself.
I can't say enough how much I love the Amazon style of disttill your thoughts into a doc (doesn't have to be long) then schedule a meeting where everyone gets time to read it first and comment inline, then discuss. As you scale out your influence this helps even more. Even friendly readers should take a bit of a grader/devil's advocate approach and call out anything that can improve. Any qq they ask a later person, less in the loop or more skeptical because they have their own ideas person will definitely ask. So fix those sections and your doc and your written communication skills will greatly improved through iteration.
Also you get bit the distilled document that can be reused later (big win of written) and the high rate communication of a live meeting. And focus.
> participants need to be competent at writing and reading prose (it’s harder than it sounds) and even with the best of care your ideas can easily be misinterpreted resulting in the loss of an async cycle.
I get what you're saying here, but can't we replace writing and reading with speaking and listening, and claim somewhat the same thing for synchronous communications?
To me, if you have employees who can't write or read effectively, that's as bad as employees who can't speak or listen effectively. If you have those kinds of people, you have hired sub-standard people.
Sure, but at least at my company and with our customers, there's a large number of people who can speak and listen just fine, but are terrible at written communication.
> If you have those kinds of people, you have hired sub-standard people.
I used to think so as well, but from my work experience I'm leaning towards being good at written communication is not the norm.
I think that what it ultimately comes down to is empathy. What determines how smooth and effective a line of communication is.
Why most people tend to feel 'exhausted' when communicating synchronously online is that it's usually not very synced at all (interruptions both online and off are constant). So makes empathy more difficult to cultivate.
Async communication does seem to have more of an advantage here, as it is by definition a more thoughtful style of correspondence (writing a tutorial for example). And ironically, is a more synced style of communication, when the information passed on is actually being consumed.
I touched on this, and the ways in which async communications can be made to be even more effective in a recent post on my blog: "Why Most Programming Tutorials Are So Hard To Understand – (And A Solution To This Problem)" - https://fromtoschool.com/why-most-programming-tutorials-are-....
Yes, totally agree with you here. Synchronising to make the decision, then writing it down for async later reference and to inform those who weren't included in the synchronous bit for whatever reason is the best mix.
(which is exactly what agenda and minutes are for - they are the asynchronous preparation and followup)
> For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out.
AKA when random I/O is needed, minimizing latency is the key.
Brainstorming can be a chatroom; this is a better meeting because note-taking is automated.
However that should generate a list of items to follow-up on, and there need to be chances for validating, correcting, and following up on that process.
We have real time text chat for decades but most people, after remote work become the norm thanks to the COVID-19, still prefer video chat rather than the efficient text chat. It's because most people are lacking the literacy. Even though they look like understanding the text, the reality is, they simply recognize a few seemingly important keywords and pretend they understand the text as a whole.
How can you trust someone's spoken words if they can't write?
And what's the problem in your opinion with written iterations?
I usually attend meetings, hours a day, when I have to repeat the same concepts over and over, multiple times, to the same people, because they just forget what we established hours before.
There are people at my job setting up meetings just to "recap", which is a poor excuse for "we didn't take notes and/or we weren't listening and just said yes"
It is my problem with meetings & calls; I have no issue with effective meetings, however, a lot of people I work with (but ofcourse not all), treat meetings and voice calls just as a reminder/recap. They basically do not remember most of anything and don’t read/write anything either. So the people who take notes, read the minutes and read the docs have to sit through hours or rehash per week.
I cannot imagine how much time/money is lost by this in the world.
Real-time, spoken communication is on-site work super power.
When uncertainty is high, and an intense discussion is needed, spoken word is much more efficient, from my experience. People are fundamentally better at speaking quickly and taking proper turns. This all is much slower and more cumbersome in video call, phone call, or a text chat. The perceived sequence breaks, the turn-taking protocol breaks (unless enforced by a moderator, at the expense of speed), and the communication become slower, less efficient, and more tiresome.
I love neatly written logically organized texts. But to produce such a text, a lot of the questions it answers should be already understood, answered, and arranged in a easy-to-consume order. There are situations when this is not possible, and finding out the scope of the problem and its structure is exactly the task. Here's where face-to-face verbal communication rules.
Of course, providing some written output after such a meeting is important, too, be it nicely written minutiae (a shared document on a large screen works well), or just a photo of the whiteboard.
So, both written and face-to-face types of communication are important. None can efficiently replace the other.
But with text there are tools to overcome this problem. Text scales into larger groups, and accepts days long latency. People adapt quite well to hierarchical chat and shared co-authored documents. Any group larger than half a dozen people will organize better around text. But any large group is also composed of smaller ones, that can always benefit from on-site talking.
My impression, after some time of forced remote-only interaction is that both modes are very important, but spoken on-site communication is ideal for a very small share of the total communication.
when you have three introverts and one extrovert talking you end up with the extrovert talking and introverts listening. All the introverts have agreed by minute 2 and are itching to get to work. Meanwhile the extrovert elaborates for a further 25 minutes on some philosophies and generalisms and the introverts eyes are glazed over.
That's because when the extrovert is talking to other extroverts, they will tell him "yeah, yeah, we get it" and not just sit there like a sheep and let him pontificate.
How about you try that instead of just bearing with uncomfortable experiences? Chances are he'll be far less offended than you might think. Talk is cheap, after all.
I agree with you partially. I found something interesting, with this everyone work from home: I'm able to communicate with certain people more effectively via zoom.
I think it boils down to with zoom, you are literally in someone's face, and it's very obvious when you aren't fully focused on them.
Perhaps the new way, with zoom, gave some people an opportunity to reset their manners? Not clear what the real reason behind it is, but I noticed it immediately.
In a natural conversation, it is rare to have someone stair you in the eyes for more than a couple seconds.
Hadn't considered that for some, this constant stair feels like they are finally being recognized. This makes a lot of sense. You wait for your turn to talk and the stage is yours. In some sense, everything is fairer.
I agree. I see a distinct difference between video-meetings where all people have video active vs. having that disabled. In the second case I have to actively work on keeping engaged. It is quite some effort. When people are in each other's face it is more easy.
Actually funny this question. Because come to think about it, text is by far my preffered way to communicate.
That goes for work and for serious-private matters.
The absolute strengt with text is that it gives you history by default - you can save it.
While you can save text it's also eaiser to the search.
The mental model around writing and communicating is the mental proces that goes into it, and which is also the reason i disagree with people that believe you should be good at writing - if you haven't thought about what you want to communicate you can't write it nor speak about it. Why would you be better at communicating by speech rather than text? Sure it's faster to speak or video, but does that give a better result? I say no way
It's worth noting that some people specifically see verbal communication's undocumented-by-default nature as a feature.
When I was younger I found that idea very offensive. I considered people who held that viewpoint to be suspect (engaging in political machinations, or using fluid recollections of conversations to their advantage). I still think there's a grain of truth to my suspicions, but I've learned to recognize that there are acceptable reasons for undocumented conversations.
There's still phone calls. Any co-worker you trust enough to have an "off the record" conversation with wouldn't turn down a "hey, can I call you?" request. They might think it's weird at first, but would understand later I'm sure.
I've called coworkers literally just to rant to someone before. Sometimes, you need to complain, but having a record of that is not helpful in any way.
> I've learned to recognize that there are acceptable reasons for undocumented conversations.
It seems bizarre to me that one could think otherwise. Unless you meant but did not specify that you're only speaking of line-of-business workplace communication, of course. Otherwise, I find it hard to believe you could forge any actual relationships with people if you try to have a record for everything.
I do mean in a business context. I still feel like a lot of business value fails to be captured when important decisions are made in an undocumented medium. The context and supporting facts associated with a decision are often just as important as the decision itself.
I spent about ten years with field service as part of my job.
What that taught me is every form of communication has it's uses. For full effect you often need multiple types. Talk on the phone. Send a follow up email. Then talk on the phone again. Update the original email into a formal doc. Two engineers with a whiteboard can solve some problems in a few minutes that would take days of back and forth over text.
Formal text though is usually very good. Especially if the author can produce high quality output quickly. This is my particular failing.
There's a lot of history here, going back centuries. The military has put much effort into designing written communication. There's the classic 5-paragraph operations order format. There's the "bottom line up front" style, which for information rather than orders. The military makes a very strong distinction between info documents and orders.
Diplomats have some traditional formats, too.[1] Most correspondence is formal. Sometimes there's an "appreciation of the situation" attached to correspondence from a mission to its state department. That's an informally written summary of what the writer has observed and what they think is going to happen.
An amusing read is "How to Live though an Executive", which is nominally by L. Ron Hubbard, the Scientology guy, but was really written by Richard DeMille. This is from 1953. It's someone trying to invent Slack, before computers. It's done with wallboards, clips, carbon paper forms, tear-off tickets, and people called "communicators" doing the paperwork. It was never used. Too complicated pre-computer. The basic concept is a trouble ticket, with an organized system to insure that handing off the problem to someone doesn't mean it gets lost to follow-up.
Yep, this article rings true on a number of levels, particularly regarding asynchronous work and lack of interrupts.
Anecdotally, I'm working on a software project at the moment with a small team of volunteers.
To explain some context: I'm the sole developer currently, and I'm treating communications to the team as high-value for us, now and in future - the same way that I'd like to think that I treat the code (I write this with the awareness I've recently cut some corners; but cleanup is on the cards).
One observation is that I'm really enjoying only using email for that communication.
Sometimes I code for a couple of days before checking or answering emails, simply based on what feels most productive or compelling at the time.
As a result I never get distracted by pings while working, and feel much more comfortable taking time while writing messages and replies, generally allowing me to be a bit more thoughtful.
And there's only one communication platform. My attention's not split between instant messages, emails, and other organizational tools.
This situation's probably an edge case based on the small team size and my personal preferences, but it's been an interesting experience.
I don't know how well this approach would scale* -- and an open question based on my experience and also raised by the article is: how and where do you organize that content so that it can be discovered by newcomers to the team?
*Example: crisis moments, such as technical outages, would be tricky to manage for a multi-person operations team
I like flow as much as anyone but find the thought of working multiple days without speaking to my team to be crazy, I'd feel like none of us would be able to move as fast alone as we do together, and half the time would end up following rabbitholes, or spending too much time on the wrong things because we'd never check in for an opinion. The only way I'd see a full or more days of work without communicating working well is if we'd work on larger amounts of releasable code at once, but then there's more chances of conflicts, reviews get longer and harder to do and there's more risk releasing.
I think having a team with 1 rotating person responsible to handle all external requests per week, and everyone else being focused on their work but still being able to pair when needed, ask questions provide guidance, etc to be really cool. All of this remote, of course.
Thanks, yep, those are all legitimate concerns about whether this would scale.
It's occurred to me that Stripe's email transparency[1] could help (although they discovered limitations with that approach too, and have been good about publishing those).
We're lucky (in some ways) not to have a large inbound feedback load, which is surely also a factor. Thanks for the external-request rotation suggestion; that's a good idea to provide a refresher from focus work when the burden starts to affect the team.
Honestly though, I have to re-state that it's been so refreshing and enabling to work this way that I wonder whether there'd be ways to scale up and solve the consensus, conflict and opinion problems you mention.
Despite that, I'd add another problem to the pile: not everyone is going to be able to contribute at equal pace at all times (for various completely valid reasons) in a large enough team - and there needs to be genuine cultural understanding and acceptance of that which I believe is frequently absent from high-intensity startup environments.
That’s an interesting idea regarding rotating external request handling. Do the team members not currently on call forward requests to those on call? How do you manage continuity of communication once the rotation has shifted?
We usually sync out of hours on-call with the "handle requests from outside the team" so that while you're at work you're the same person, everyone in the company knows to go to a specific slack room for these requests to our team, or they can straight up create a "change request" ticket in our jira board if the request can be done few hours/days later.
Usually there's nothing (in almost 4 years I think less than 5) that goes across weeks that's still in progress. We have a very low volume of actual incidents, and external requests that are sizeable enough get turned into actual prioritised stories by the next planning.
> One observation is that I'm really enjoying only using email for that communication.
If it were up to me, I would use a self-hosted NNTP server as an internal forum for communication and reserve email for one-on-one private communication.
> As a result I never get distracted by pings while working
I actually disable notifications from chat applications and email and just make sure I check them periodically throughout the day. No one has ever complained that I took 10 to 20 minutes to respond to a question. Though if there's an active discussion going on, I will participate as needed.
> how and where do you organize that content so that it can be discovered by newcomers to the team?
Newsgroups would typically have a monthly group FAQ post. While that could be done via email, newcomers wouldn't be able to see emails sent before they started.
> crisis moments, such as technical outages, would be tricky to manage for a multi-person operations team
The monthly post with the up-to-date operation procedures to follow for technical issues could work and could be checked for out-of-date information before posting (which is something that wiki documents don't handle well).
I was lucky enough to be able to use the Twist app for team communications for some time. I highly recommend it to people willing to go the async way. It feels like a perfect cross between e-mail, forum and slack.
Yeah, I really liked the concept, but when we tried it 2 years ago or so it had several bugs regarding never getting a notification although it should and showing me that I have a new message although everything was read. We reported them but nothing changed. And all team members had these problems. Probably they have fixed them now but we unfortunately we switched to slack and now it is very unlikely we switch back due to these serious problems.
Peter F. Drucker, influential author of countless books on management, once made a very simple argument: there are reader types, and there are listener types. If you are dealing with a partner you better know which type they are.
It doesn‘t make sense to hand a listener type a manuscript without talking about the subject, and it doesn‘t make sense to set up meetings with a reader type before you hand off the written argument.
We should perhaps just accept that an tolerate each other where our strengths are.
Whatever people’s preferences in terms of reading or listening, I am inclined to think teams get better results when a high quality meeting summary goes out ahead of time.
I don’t claim this is an absolute truth, but I also don’t think many organizations have given it proper try.
I agree, but think the virtue is as much as in the actual process of writing the summary forces the summoner to clearly work out ahead of time what the meeting is actually about and what it is aiming to achieve.
This article is great because it puts into words the relationship I've had with Slack since the beginning of my career. I've been working professionally for 4 years and I cannot remember a single time where I thought "I'm so glad we have Slack". Don't get me wrong, I think the platform itself is a great interpretation of IM, but IM is the absolute last thing I want to use in a work environment.
One of the reasons I didn't work out on my first remote job is because I refused to treat Slacks red icon as my #1 priority in the world. Coworker needs my attention immediately? Call me. Is calling too much of a hassle? Then it's probably not as urgent as you think. I understand it's very arrogant of me but I cannot bear the thought of losing all of my focus to answer a question that was really not that immediate. It sure doesn't help that people think they need to greet me and wait for a response before they actually say what they want to say.
I'm working at a new place now and we've gotten so good at asynchronous collaboration that I haven't exchanged a single message on Slack with one of my coworkers since they joined the team. All of our talks are done through Github and our weekly meeting on Friday where we plan the next week and spend an hour or two chatting. This is nice because it gives me time to reason about discussions, and even makes me look forward to the next meeting to have some fun with them, while previously I got so sick of my coworkers that I had literal nightmare-induced panic attacks over constant meetings.
I'm really glad I managed to find a team that enjoys working on the same way I do.
“ the relationship I've had with Slack since the beginning of my career.“
As someone a bit older, I’m just thinking that maybe it would be helpful to have an on-ramp of business communications course in college or when starting a first job. Start with important things about in person communication. Then with writing a good memo. Learn to make a good phone call. Then write a good email. Then write a good IM/slack/teams message.
Then be taught the strengths and weaknesses of each. Maybe I need to make a course.
> It sure doesn't help that people think they need to greet me and wait for a response before they actually say what they want to say.
This is indeed intensely frustrating. It is so ridiculous that when you just don’t respond, you’ll end up with a person just saying only ‘hello’ to you three days in a row...
> Coworker needs my attention immediately? Call me.
I despise unsolicited phone calls. It’s figuratively kicking in your door. I can delay a Slack response for a few minutes. I can’t delay some jackass barging into my “office.”
Second that. Phone calls - and they're all unsolicited as far as I'm concerned - aggravate me far more than a barrage of IMs, though both are undeniably aggravating.
There's a small irony to this since I've been in the VoIP industry for about 15 years. :-)
+1. if somebody needs my attention - look at my calendar and send me a calendar invite with zoom link attached and if I accept it - you can get some attention. your urgent is not my urgent, it is your poor planning.
unless it is live production support, for which I get incident notification from ServiceNow anyways
I agree, I also hate talking on the phone. I believe that's true for most people though, which makes them question themselves if they really need to go through that awful process. At least that's how I reason about a problem before bothering someone with what's essentially not their concern.
And then you have people who hate talking on the phone. If you don't respond reasonably quickly to IM, I'll make a ticket for you to write up documentation instead and mark it a blocker.
I think a big part of this article is that the author doesn't like being interrupted and therefore has defined this as the problem. I don't like being interrupted either - but often the interruptions I experience are the best opportunities I have to communicate ideas, have creative back and forth, and importantly, communicate the details that are going to get me shouted at for saying on the wiki.
The problem with asynchronous communication is that I need to predict what information you're going to need, before you need it. The result is huge amounts of documentation work going on - 90% of which is useless, and the other 10% is either undiscoverable or could as just as easily be solved with "has anyone touched the db" in chat.
The example is great - because it's absolutely something that I've seen happen. You post on the group chat "did anyone touch the db" and someone replies, "Oh Johnny mentioned something about it the other day". Suddenly you're not searching through thousands of jira tickets and wiki pages, and most likely not finding what you want anyway - since no one can predict how they'll scre up. You just ping Johnny, and if Johnny isn't there? Well he'll reply when it's back. It's fine. That is part of flexible working. Flexible working isn't "I get to pick up my kids at 12" it's about everyone having flexibility, and everyone giving flexibility.
To me, this asynchronous communication plan sets an unacheivable goal, because you're never going to know what it is other people are going to need to know, and documenting everything exhaustively is an uneconomical.
When writing you are not getting feedback (give more context, go faster, what concerns to address). A back and forth can be a much faster way (both in total time elapsed and time spend) to resolve something. At GitLab we recommend async by default and jump to sync when you start going back and forth. https://about.gitlab.com/company/culture/all-remote/asynchro...
In our business, async communication is at the core of how we deal with clients. We design UI/UX for tech companies (http://fairpixels.pro) and in the 10+ years of trying out a dozen of ways to work, async email conversations were by far the most effective for us.
Email over Slack, why? Slack and other chat environments still create the expectation of realtime responses. Also, messages you type there are short and often of a lower quality.
Email is usually more longform. This forces us and clients to think first, write second.
The quality of feedback and communication is just so much better.
I also find keeping a log of work helps provide the right communication at the right time. Especially when remote I find it is easy to forget all the things I’ve worked on in a given week. It doesn’t always make sense to interrupt somebody with updates on something the moment it is done. Colocation provides so many more cues to communicate progress, ideas, etc. in the collocation context the work log is less important as a communication tool.
It so happens, (shameless plug alert) I built a tool [0] that asks me what I did on a daily basis via sms, the responses are organized in my work notes folder. I use this for keeping track of long-running projects that depend on lots of other people for input. I also use it to build a monthly description of work to include with my clients’ invoices.
I am a firm believer that written communication is the best way to sustain a productive team.
Talking, especially in person, might get you the result you're looking for faster. Look, we decided what we needed to make and skipped the overhead of opening a ticket and capturing the back and forth.
But then you have to revisit your decision and your reasoning behind them 4 months from now. Why didn't we just do that other thing that seems more efficient?
Or even worse, someone picks up your work after you leave and they have to do that, without the potential ability to recall the context.
Or then you leave a meeting about making any sort of decision and start working and a few days later realize you're not on the same page.
I get that writing might not be some people's best skill, or even their preferred way of communication.
We all have to put up with things we don't enjoy and learn skills to work, why should this be any different?
I work for company that is in the process of going remote first, without embracing a culture of writing first and writing everything and it's not very pretty.
Previously, I worked for a company that despite not really prioritizing remote workers, because teams were distributed across the world, had to capture a lot of the things I mentioned in the tickets created for each task. And it was really empowering to have a lot of context as someone who was tasked with maintaining those things.
I think emotional intelligence coupled with integrity are the real super power wombo-combo, no matter the role.
It helps if you have the technical skills to go with it but to be honest, having those skills should be a matter of training, not expecting people to be learning on their own time.
This should be fixed on the company level - every employee should receive regular training, not be expected to magically keep up their workload and learn new technologies in their spare time.
Another issue that makes projects go side-ways is people relying on a paycheque for their livelihood. If you want people with integrity to practice it in the workplace, don't place them in impossible situations where they have to choose between their integrity and their family's financial well being.
This should be fixed on the government level.
This is all to say that this endless stream of blog posts about what an already over-worked, under-paid worker ought to improve upon, are not helpful - highly educated people used to be Aristocrats who fine dined and wrote poetry. Today we are expecting people to pay for their own training, spend the best years of their lives studying to pass tests, be hazed trying to get a job, for the privilege of getting worked to the bone for the benefit of a corporate entity. I thought only dystopian novels could think of a system so counter-productive and insane, until I read Brave New World and thought hm, this might be an upgrade over the life I'm currently living.
If I were to ever hire, I'd optimize first for clear, written, long-form asynchronous communication, second for ability for the job at hand, and anything else third.
Having hired some freelancers recently, I've found that there is a world of difference between those who can communicate clearly and those who can't.
Oh, indeed. I think this is the single most underrated dimension of actually being able to extract value from someone in a commercial organisation.
Also, having run into it a number of times, I feel compelled to mention those who are quite capable of clear, written, long-form asynchronous communication as a matter of skills and abilities, but seem cholerically averse to doing it.
Video calls are like single-room IRC 20 years ago, before PM, threads etc within same room were added. Probably just matter of months when we will see subrooms, side-channel whisper, history of transcribed logs and many other additions also in video calls. Just current software limitations.
I have a day where everyone else in on flex (basically their day off every two weeks).
I have already cleared two large tickets because I can address the comments they left when I am done another task (because they wrote out their entire thought instead of waiting for a conversation).
I would bet I am 2-3x as productive as I now have hours of uninterrupted time.
In my team if someone needs to pick up the kids he just says it in chat or even in a video meeting and gets them. I think webex meetings work better than real live ones. If they are tiring that's positive because meetings last too long. If only one person can speak at a time it prevents people from interrupting and makes them conscious not to hog the mic. Async communication? How would you do that? If you have a question and can't find an answer, what do you do? Make a jira user story to document this specific scenario and put yourself as the reporting too? Then assign to a colleague and hope he does something with it? I mean it could possibly work if everyone is accustomed to it, is of a very high level and is also a high level technical writer. But it just seems to me that in practice junior might be too dumb to understand seniors writing. Or senior just writes something that's not legible. Or senior ignores his new assigned story because junior created it and not the product owner. Or scrum master sees the story and thinks: that's not part of sprint goals and throws it out of the board. It seems really slow to work this way.
I think it really depends on the project size and the kind of work. If you're more in a waterfall model, where the specs are clear and you just got to do it, I can understand how being able to work uninterrupted is a nice-to-have.
But if you work very closely with the business and often run into things that could be done or understood in different ways, having to wait a day or more to get a clarifying response would not work. And this is know-how that can't be written down easily if at all, since a lot of decisions are purely based on experience and historical knowledge.
I used to have this illusionary vision of how everything should be neatly documented, but if you operate on a constantly changing code base, it's really hard to find a good balance. Documentation gets outdated every few weeks and sometimes days, plus most of the time, you don't even know that said documentation has been written. As such, you can't fully trust the documentation and you always have to check out at least part of the code.
What seems to work for me, is documentation that gives a broad overview of a topic and then gives certain pointers into the code. That way you capture the essence of functionality that is likely to remain for a longer time and the transition from documentation to code is made easier.
And finally, if someone is stuck or doesn't understand something, I find it problematic to have the expectation that nobody may be available to read your message for the next few hours or whole day. What is more efficient, someone spending a couple of minutes to provide assistance or someone googling/search Jira/wiki/Confluence for half a day and not making any progress?
Chat is only problematic if all you have is slack, with the lousy threading UX, and the prevalence of DM and private channel.
Still, slack is miles better than wiki pages (go staled immediately), emails (even more broken threading interface), and heaven forbids google docs (impossible for collaboration, may work for bosses).
I think the best solution is something like zulip chat, complemented by wiki pages for "immutable" information.
I gave a talk on this idea few years ago, that even just the metadata of slack messages was enough to make improvements to process. As a support engineer it was useful for us to see when we were asking questions in slack, what the patterns were to improve our team training:
Ticket comes in -> we don't know -> we link to ticket in X channel. Tally the channel links, look at chart, identify patterns.
In an office, this would require me to be an EXTREME micro manager, whereas remotely, I just paid attention and used the meta data to drive our training.
In an office, you could ask the team to keep track, or to tell you what they noticed, but by having a direct tap into the data stream, the team just does the work.
(This requires a high degree of trust, and we were looking _inward_ so it wasn't something that was met with disdain. If we were using this to compare what teams were more responsive and being outwardly critical, well, I don't think that will go over well anywhere.)
> participants need to be competent at writing and reading prose (it’s harder than it sounds)
In my experience, around 1/3rd of developers are not good typists. Writing code isn't really about typing, so it's OK, but when participating in an active conversation in a chat room with multiple people, not being able to type well hurts.
A strength (and weakness) of async is that it comes with a higher expectation of writing quality.
When the expectations are too high, it's likely that people won't get things down in the first place.
My team has noticed an unintuitive approach to communication that seems to work better than alternatives. Write better private notes.
Private notes are low-friction. You know what's worth writing. You don't need to worry as much about if it's a mess.
Our approach is to help you make your private notes a little better organized. And to make it fast to share these notes when they might be helpful to someone else too.
It's bytebase.io. Would love the community's feedback.
We're finding it quite effective to record short 2-minute videos and circulate those. Everyone can talk and point things on the screen, not everyone can write or even read attentively.
> Everyone can talk and point things on the screen
I think you may be making some unconscious assumptions about everyone having the same abilities. Deaf or mute people can't talk. Blind people can't point at things on a screen. And even people who can talk might be more comfortable writing, e.g. people who are self-conscious about their accent.
For these reasons, I think that the recent increase in remote work, though forced on us by the pandemic, gives us an opportunity to better include people who might be inadvertently excluded in an on-site environment.
On further reflection, I believe I responded uncharitably to the GP, by taking the quoted part of that comment out of context. The GP most likely meant that everyone on their team can talk and point at things on the screen. In that case, doing videos like that is fine, except that the team should be prepared to adapt if anyone who can't use that method of communication joins the team.
Are these screen recordings with narration or video recordings from a webcam?
Personal preference of course, but I'd be less able to express myself in a video recording than in an audio recording or written document, out of pure self-consciousness.
They are all screens. Rarely I record a design on the whiteboard and I end up in the frame, but I'm fine with it. BTW this also works much better than any spec.
Self consciousness is an interesting problem. I prefer seeing faces on the screen during the stand-up (such as it is in the days of COVID), but I was told many hesitate to be on camera.
Did you ever find a way out of this? Join.me has very small video size, I imagine this is one way to lessen the stress. Alas it doesn't work for me - I need to see the facial expressions because I need to know when I lost the audience, and because I find it hard to pay attention to a disembodied (and heavily compressed) voice.
> Self consciousness is an interesting problem. I prefer seeing faces on the screen during the stand-up (such as it is in the days of COVID), but I was told many hesitate to be on camera.
Getting people to turn on their cameras has always seemed to be a challenge in my experience, but it does seem contagious, once a few people do, everyone starts to over time.
It makes a huge difference to see peoples faces over talking into a void. I think empathy is a bit part of it.
I've noticed the biggest difference between junior developers and more experienced individuals is their written communication abilities. This has led me down the path of trying to find resources to help teach communications to those that I mentor but since this isn't my area of expertise (teaching communications) I'd love if anybody had resources to share.
I'm not an expert on teaching communications but I personally don't believe we need to be an expert to figure out how people can increase their communications skills. Its like anything else. They have to practice, and get correction when they do something wrong.
A big part of it is habit or level of effort.
Force them to read books. Maybe something fun like a genre of novel that they like. Because the fundamental level of literacy is going to have a big impact on writing ability.
Have them find a forum of subreddit that they like and then regularly participate in it. And then offline or in a private message, fix their grammar and point out the problems with their communication.
Or just have them use written communications at work rather than in-person meetings etc. And then when the communication is lacking, point out the specific flaws.
Practices is great and all, thats how I learned, but I'd know there have to be resources out there to help people learn beyond simply "figure it out as you go."
The key to communication is to remember: "It's not what you say, it's what they hear." (Note: say can be written, and hear therefore read.) The mantra works either way.
Ultimately, the responsibility of the communication belongs to the sender. Improvement still takes work, but you'll progress faster if you have this foundation.
People ask me what do they need to be good at to work at Google. I jokingly (but kind of seriously) tell them it's just like grade school - reading and writing. 80% of the job is reading, editing and commenting on docs people wrote or writing docs people will read.
Snir David writes well. One point that I think is missed in the "chats and video calls" is that you don't have situational awareness of whether the other person is busy like you do in person.
It's the same as the problem with taking phone calls when driving a car as compared to talking to people who are in the car with you. The people in the car with you can see when you're in a tricky traffic situation. The caller, not so much.
"The Mongol Empire was the largest contiguous land empire in history. It started with the unification of Mongolia in 1206 and territory of 4 million km² ruled by Genghis Khan, to have 35 million km² in 1279 under Emperor Kublai Khan."
"Here is the thing: all that remote work in one of the biggest empires in history was accomplished without videoconferencing."
In my experience, the people most averse to writing stuff down are usually the remote engineers. Remote workers don't typically have the same cultural influence as local employees, so they tend to be somewhat alienated and therefore have fewer expectations put on them. I think this disincentivizes remote workers from fully assimilating into the culture and leads to less interest in communication. Inevitably, this ends up affecting their willingness to properly document.
I have the exact opposite anecdotal experience. Remote engineers I've worked with have put a lot more effort into their writing because they understand that it's one of their only avenues to participate in the company communication culture.
Picking the Slack / Chat argument: I don't think it should be expected to reply immediately. It's more like a lightweight inbox (when being tagged / DMed) that's easy to reply to (no greeting/regards required). Channels are a great place for async discussions that can be linked to and are kind of public so noone needs to decide beforehand whom to engage, and everyone can decide to join or leave the discussion without being cc'd forever.
I have been thinking about the same problem as the author, but I’ve reached vastly different conclusions about how to do remote work better.Polar opposite.
Async writing is powerful but unfortunately, it requires also dedicated time slots to achieve it.
When you have the constant pressure from management to do X instead of writing on Y in a limited time, then you have no chance to write beautiful, centralised information. And so, the company itself accumulates technical debt, looses history and precious information that might be speed up people in the future.
There's a reason Technical Writing is a class offered in engineering courses in college. When you've read good documentation (HP user manuals from the 90s) and bad documentation (most open-source projects, no judgement, they're crowdsourced and we're lucky to have contributors willing to document things at all), you really get a sense for how valuable this skill is.
The super power I see is not so much written communication as intentional communication. I try to get myself to communicate intentionally by having command-enter send my Slack messages. But sometimes you need to Do the Thing. And you can't afford to Intend to Do the Thing first. In those situations the speed of spoken-face-to-face makes the organizational debt worth it.
The problem is, most people don't have enough literacy and practicing to communicate via text.
Most of them appear to be able to read and write text, but they are not. They simply recognize the few keywords and pretend they understand it.
That's why most of the people, after remote work become the norm, fallback to inefficient video chat rather than efficient text chat.
It is possible to convey much more nuance through speech.
I like to think of myself as an effective writer. Nonetheless, it is incredibly difficult to express nuanced emotions through writing. This is particularly true in “professional” contexts, where an informal message may be perceived as rude. In many situations, I suspect that the same message, delivered verbally, would not even warrant a second thought.
The reality is that few people are taught to write in a manner that allows them to actually express their feelings. The fact that we even need to learn this indicates to me that speech is a far more effective way of getting our thoughts across
I am surrounded by people who love to do voice and video meetings, and I find them taxing and not very efficient. I've been hearing a lot about communication in this remote work covid world, but I've seen that turn into more of these comms that I don't want.
I need to find a way to tactfully say I prefer text...
Nonwritten communication is unreliable. People often have different interpretations of what was said and what exactly should be done. The only way to reliably manage work is to have everything written down.
The author did a really good job of articulating why I've spent the last several years working on Zulip despite there being a thousand Slack clones to choose from.
Asynchronous communication is essential to being able to focus, at least if you do enough communication that it matters how you communicate. And it's very inefficient to do asynchronous communication at scale in Slack or any of its copycats. This leads to the Slack cultural issues detailed in the post; they're the result of people working around the bad core workflow of a beautiful, masterfully marketed tool.
Consider "Everybody expects an immediate response" culture. In my view, that is people adapting to it being unpleasant to be a busy person waiting for a reply in a Slack channel. (Which is because it's miserable to make sure you don't miss things in busy slack channel, so everyone does, so anyone who wants to be sure of a response spams PMs and mentions and otherwise applies pressure to get a reply now now now so that they can mentally move on to their next task).
Zulip aims to make asynchronous communication so efficient that such adaptations are unnecessary. The core innovation is that all messages in channels are organized within "topics", which work exactly like the Subject field in email. This model works great for enabling asynchronous communication in email, and it works even better in Zulip (mainly because of topic editing and linking features).
The main goal of Zulip's interaction design is to make skimming hundreds or thousands of Zulip messages (and replying thoughtfully to the ones where you can add something!) pleasant. This enables a better way of working. Personally, I read and respond to 500-1000 Zulip messages sent by dozens of people across 50+ topics every single day, and I get compliments on how responsive I am, despite the fact that I do focus work in multi-hour blocks most days, Zulip's development community is all over the world, and I lose hours of productive time every day due to a chronic illness. This wouldn't be possible with Slack.
And this isn't just my experience; I've heard from so many people in organizations that switched to Zulip that they love how Zulip makes better use of the limited time they have (whether busy managers at companies or participants in part-time communities).
> "You'll lose your history"
This is the other major bundle of problems that Zulip's topics solve. Zulip can be a valuable knowledge store because of the organization provided by topics (combined with features like permanent links and topic-powered search workflows).
Zulip is 100% open source software (Not open core! We're intentionally not VC-backed so that we can prioritize our values; see https://news.ycombinator.com/item?id=23102430).
And we sponsor free hosting on zulip.com for open source projects, academic research, and other non-commercial organizations.
I read it and I like it, thanks for sharing. Though I do hold the unpopular opinion that slack is antithetical to effective communication methods/mediums.
I don't know how to phrase this without sounding like a somewhat pedantic asshole, but I cannot understand this reasoning. Are we really saying there is less variability in people's spoken communication abilities than written? This concept is baffling to me. Who in the world talks better than they write?
Also, in my experience, written comms is immensely more accessible and accommodating to diverse teams with people who may have variable levels of expertise with English.
I worked with a guy who was legally blind, but could function with a physical screen overlay device that magnified things up to pretty absurd proportions. He was one of the better communicators (in writing) in the entire engineering org. I think we should work on individual cases to make writing more accessible to people for whom it's a struggle. But we shouldn't just throw out writing and it's overall effectiveness. That's not a solution, it's avoiding a hard problem.
We don't just decide to only build one story buildings because of physical accessibility, because we don't want to throw out the efficiencies of multi-story structures. Instead we install ramps, automatic doors, elevators, etc. And we have legal standards for door widths and hallway widths, etc, etc.
Totally agree - not suggesting we throw out writing, we would all be doomed.
I’m sure your blind colleague wrote well - so do many of my dyslexic colleagues. Doesn’t mean it was easy or fast For them though.
I suppose what I’m saying is that there’s no one-size-fits all or one thing for all tasks. This article highlights the advantages of writing. And I agree. But it isn’t the right work from home comms tool for all combinations of people and tasks.
Sure, that makes sense. Also I can for sure acknowledge that you answered my initial question. There are definitely people who speak better than they write, when it comes to certain conditions and disabilities that make writing harder than it is for the average person.
I'm not sure I follow that statement. I can see an argument that text is not strictly better than verbal communication but, at worst, I'd say it's equal (for people as a whole, not for one person in particular). Some people are better at written communication while some are better at verbal.
For most people, I'll happily agree with you. From a dyslexic's perspective, being forced to only ever present one's ideas and thoughts in text is pretty restricive.
And that's fair.. for a dyslexic, written communication is worse. I wasn't trying to imply that, for all people, which medium is better varies for each individual. I was trying to say that, over the set of all people, which medium is better tends to vary by person. That neither medium is "better" for everyone.
Agree with the headline. Good written communication is a requirement for a software development project. But I am not sure about all of his ideas in all circumstances. In particular in relation to a very small dev team and small client group. In terms of something different like for example an open-source piece of software on github, issue trackers are key.
However, for a small sort of private project. For example, if you have a very small team and can get people in a chat room consistently so that you can have solid conversations every day in there, that has worked better for me than using some kind of issue tracker. Especially in terms of dealing with clients or business-related team members. And maybe its really only for very small projects, like one or two developers, I don't know.
But for me, with most of the projects that I have been on my own building a product or tool for a client, the issue trackers and things like that worked against me and the project as far as I could tell:
- People would seem to think it was their job to fill the board/tracker up with as many things as they could think of. This caused extra stress and tended to make me want to rush through things to get them out of the way. The biggest problem with that was that it took time away from the really important things. And it is very difficult to get people to give realistic priorities.
- Sometimes, people would write critical information in the issue tracker or board, and I did not realize it had been updated or how critical it was. And so they operate with the assumption that they have communicated something, but actually I didn't see it until two days later.
- When they have a place to put an infinite number of tasks, it encourages them to increase the scope of the project, without having a real discussion or necessarily even thinking the feature through.
For me when doing projects on my own (or maybe with a designer) for a specific small group, there is just a limited amount of stuff that I can realistically finish in a given time frame. So I actually will not allow an issue tracker or board and try to get everyone to show up sort of simultaneously in a chat room. Sometimes people cannot or will not do that, and in those cases sometimes a phone call can work. Or maybe they actually are capable of reading and writing async messages in the chat room (not very common).
Basically every few days I meet in the chat or phone or whatever with the client and discuss what I have been working on in the last few days, walk them through the updates to the application. So something is being delivered and tested by the client every week or even every few days. Then we specifically talk about exactly what is the priority for the next few days. If there is development work that needs to be caught up on, then there may not be any new features to work on. Or there may be a feature that has been in progress, and the client gets an update on that.
Often the client has ideas for new features. Instead of putting them in a board or issue tracker to pile up, when they bring them up, we decide whether they are now higher priorities than other existing items and will fit into the work load of the next few days. Or, I tell them to remind me later. There is no such thing as a task that I will "get to when I have time". I have the client focus on the next most important priority and/or I explain the ongoing dev work, and we work out like 2-5 days of work and that's it. There is no infinitely expanding list of things to get to later. If something he has been thinking about is really important, it becomes a priority as soon as the previous task is completed. We check if I implemented something correctly as soon as it is implemented. We don't have to refer to a database of things, because we just talked about it a couple of days before.
Interestingly, I've been thinking about organization at work and I feel like there are many forms of async communications that should or could be merged, because of how common they are. We need to communicate announcements, ask for opinions on changes, document a process, list relevant steps to a change that is happening, ...
In my mind there are multiple goals a perfect system should have:
- Must be easy to create a new "conversation"
- Must be possible to write long form content in a "post", where "post" is the first item in a conversation
- Must be able to have a meaningful conversation with replies to specific points
- Must be able to change the content of the "post" based on the discussion that happened (such that a "post" can be a poll, participants discuss options, and the final decision is summarized)
- Must be able to easily enter and exit the full conversation
- Must be able to easily link the full conversation, for referencing
- Must be able to set metadata (dates, relevant people, status, stuff like that)
We have many systems, but none really fits the bill:
- Email is probably the worst, because you can't modify the original message, you can't link to it and you can't transparently enter the conversation if you weren't part of it initially. We've all seen the "adding XYZ to the loop" that provide 0 content to the conversation. There's also the whole issue about top-posting and lack of proper threading that make having a conversation difficult. Probably just a client issue rather than a protocol issue though
- NNTP is a step above, but ironically because it has remained niche the clients and the etiquette help having a proper conversation. Still doesn't fill the bill
- Ticket systems are paradoxically pretty good for this situation. They do contain the necessary structure for incorporating metadata, in all the various forms ingenuity can come up with.... sometimes too much ingenuity, such as the labels and fields and knobs that were needed for that project years ago are still here, cluttering a lot of space because most aren't actually needed anyway. Imagine using such a mess
- A wiki is nice, but the emphasis on structuring is detrimental for flows that go outside of documenting. Sometimes you just want a linear list of conversations ordered by date
- Google docs and associated are good for really long forms for the initial "post", but are not very good at structured conversation
Perhaps the best software, for all those use cases, is a forum software. I'm partial to the (old) reddit UX or the HN UX; remove the useless voting and it's almost the perfect way to communicate. The interface gives you the space to actually take time about what you want to say and properly articulate it. HN is a bit terse here, reddit gives you formatting helps to nicely present your ideas and makes reading it easier.
Only drawback is that they are text only, and sometimes you need to include non-text (a screenshot of the planned changes, a video of the flow to document, a map of the place you're discussing about, ...)
I wrote Emergency Remote[0] for companies thrown into remote due to the situation.
From my experience, it seems that the reason companies use sync communication and "emulating" an office is not because they don't understand the benefits of async, but because of the required discipline.
Fortunately, that discipline is required vastly more of the initiator of the conversation. This allows the recipient to quite easily refuse sync communication. This way employees can help each other out and get used to async.
For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out. A remote meeting can work too.
The problem with meetings are those which are not well prepared. There shall be an agenda and proper minutes should be produced.
For most complicated matters actions/investigations are supposed to be followed up. In a way that’s how you mix async with sync communication.