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.
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.
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.
> 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.
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.
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.
> 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 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 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.
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.
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.
>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.
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.
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.
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.
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 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.
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.
> 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.
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.
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.
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'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”.
> - 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?"
> 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.
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?
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.
> 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.
> 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
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.
> 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.
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)
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-....
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.
> 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.
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.
> 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)
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.
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.)
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.
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.
> 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.
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.
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 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.
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.
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.
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.
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.
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 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.
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.
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.
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, ...)
193 comments
[ 3.2 ms ] story [ 229 ms ] threadI 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.
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.
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.
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 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.
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 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.
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.
[1] - https://stripe.com/blog/email-transparency
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.
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).
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.
0. https://www.tatatap.com
absolutely +1 to keeping records, but as a form of communication it's not terribly equal.
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 do agree that for non native english speakers, the written word is more accessible.
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.
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.
Drawing also resolves language barriers which some people in my side of the world face.
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.
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.
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.
I
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.
- 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.
> 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.
Start with "Unless you disagree, I'll ..." Instead :)
“I’ll ..., unless anyone disagrees”
2 changes:
- Starting the sentence with a doubt can highlight doubts so I’d avoid that.
- “Anyone” distributes responsibility, because https://en.m.wikipedia.org/wiki/Diffusion_of_responsibility
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 :)
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.
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.
It's really not hard to do. You'll never get there 100%, but getting to 80%? It's easy.
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 find writing up the minutes during the meeting and distilling to “are these the most important points?” works to grab folks’ attention.
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.
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’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”.
How long are those texts?
What about trying a maybe reverse text order? Start with: "do this, that, that. Because ..."? The actions first? I'm guessing
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.
Long messages for tickets, slack for near real time chat.
Email for transactional spam and emailing old friend once a year.
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?"
Not saying it's impossible otherwise of course, just slightly more convenient.
> [...]
> - 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.
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.
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.
Unless (all for the meeting really important ppl did), meeting cancelled
- https://vaclavkosar.com/ml/starspace-embedding
- https://quizrecall.com/rack/Cynefin-Framework--Making-The-Be...
I use the service for personal training, but it is opened for others now as well.
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"
At least emails are searchable...
I cannot imagine how much time/money is lost by this in the world.
(What do you think about their recruitment process?)
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.
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.
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.
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
Combining meetings and async
Instead, send out a written proposal, require well supported written commentary on the ideas, and then then meeting is to take an actual decision.
> require well supported written commentary on the ideas
That sounds good -- in that case I'd think it'd work fine both with and without meetings
This is great way to think about this, thanks.
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.
AKA when random I/O is needed, minimizing latency is the key.
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.
(which is exactly what agenda and minutes are for - they are the asynchronous preparation and followup)
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-....
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.
> 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.
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.
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)
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.
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.)
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
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.
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.
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.
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.
Just my opinion built on my anecdotal experience.
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.
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.
[0]: https://www.emergencyremote.com/EmergencyRemote.pdf
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.
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.
What a great bonus it was.
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.
(But impossible in real life)
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.
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.
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.
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.
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.
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, ...)
(If it is not clear already, I'm still sad at the death of Google Wave. 10 years later and it's still the future: https://www.youtube.com/watch?v=p6pgxLaDdQw)