Written communication is remote work super power
snir.dev
snir.dev
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.
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.
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.
There's a lot of history here, going back centuries. The military has put much effort into designing written communication. There's the classic 5-paragraph operations order format. There's the "bottom line up front" style, which for information rather than orders. The military makes a very strong distinction between info documents and orders.
Diplomats have some traditional formats, too.[1] Most correspondence is formal. Sometimes there's an "appreciation of the situation" attached to correspondence from a mission to its state department. That's an informally written summary of what the writer has observed and what they think is going to happen.
An amusing read is "How to Live though an Executive", which is nominally by L. Ron Hubbard, the Scientology guy, but was really written by Richard DeMille. This is from 1953. It's someone trying to invent Slack, before computers. It's done with wallboards, clips, carbon paper forms, tear-off tickets, and people called "communicators" doing the paperwork. It was never used. Too complicated pre-computer. The basic concept is a trouble ticket, with an organized system to insure that handing off the problem to someone doesn't mean it gets lost to follow-up.
[1] https://projects.iq.harvard.edu/files/hks-communications-pro...
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.
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 doesn‘t make sense to hand a listener type a manuscript without talking about the subject, and it doesn‘t make sense to set up meetings with a reader type before you hand off the written argument.
We should perhaps just accept that an tolerate each other where our strengths are.
[1] Peter F. Drucker: Managing Oneself. https://www.amazon.com/Managing-Oneself-Harvard-Business-Cla...
Edit: Online: http://academic.udayton.edu/lawrenceulrich/LeaderArticles/Dr...
I don’t claim this is an absolute truth, but I also don’t think many organizations have given it proper try.
One of the reasons I didn't work out on my first remote job is because I refused to treat Slacks red icon as my #1 priority in the world. Coworker needs my attention immediately? Call me. Is calling too much of a hassle? Then it's probably not as urgent as you think. I understand it's very arrogant of me but I cannot bear the thought of losing all of my focus to answer a question that was really not that immediate. It sure doesn't help that people think they need to greet me and wait for a response before they actually say what they want to say.
I'm working at a new place now and we've gotten so good at asynchronous collaboration that I haven't exchanged a single message on Slack with one of my coworkers since they joined the team. All of our talks are done through Github and our weekly meeting on Friday where we plan the next week and spend an hour or two chatting. This is nice because it gives me time to reason about discussions, and even makes me look forward to the next meeting to have some fun with them, while previously I got so sick of my coworkers that I had literal nightmare-induced panic attacks over constant meetings.
I'm really glad I managed to find a team that enjoys working on the same way I do.
This is indeed intensely frustrating. It is so ridiculous that when you just don’t respond, you’ll end up with a person just saying only ‘hello’ to you three days in a row...
I despise unsolicited phone calls. It’s figuratively kicking in your door. I can delay a Slack response for a few minutes. I can’t delay some jackass barging into my “office.”
There's a small irony to this since I've been in the VoIP industry for about 15 years. :-)
unless it is live production support, for which I get incident notification from ServiceNow anyways
As someone a bit older, I’m just thinking that maybe it would be helpful to have an on-ramp of business communications course in college or when starting a first job. Start with important things about in person communication. Then with writing a good memo. Learn to make a good phone call. Then write a good email. Then write a good IM/slack/teams message.
Then be taught the strengths and weaknesses of each. Maybe I need to make a course.
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.
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.
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.
Talking, especially in person, might get you the result you're looking for faster. Look, we decided what we needed to make and skipped the overhead of opening a ticket and capturing the back and forth.
But then you have to revisit your decision and your reasoning behind them 4 months from now. Why didn't we just do that other thing that seems more efficient? Or even worse, someone picks up your work after you leave and they have to do that, without the potential ability to recall the context. Or then you leave a meeting about making any sort of decision and start working and a few days later realize you're not on the same page.
I get that writing might not be some people's best skill, or even their preferred way of communication. We all have to put up with things we don't enjoy and learn skills to work, why should this be any different?
I work for company that is in the process of going remote first, without embracing a culture of writing first and writing everything and it's not very pretty.
Previously, I worked for a company that despite not really prioritizing remote workers, because teams were distributed across the world, had to capture a lot of the things I mentioned in the tickets created for each task. And it was really empowering to have a lot of context as someone who was tasked with maintaining those things.
It helps if you have the technical skills to go with it but to be honest, having those skills should be a matter of training, not expecting people to be learning on their own time.
This should be fixed on the company level - every employee should receive regular training, not be expected to magically keep up their workload and learn new technologies in their spare time.
Another issue that makes projects go side-ways is people relying on a paycheque for their livelihood. If you want people with integrity to practice it in the workplace, don't place them in impossible situations where they have to choose between their integrity and their family's financial well being.
This should be fixed on the government level.
This is all to say that this endless stream of blog posts about what an already over-worked, under-paid worker ought to improve upon, are not helpful - highly educated people used to be Aristocrats who fine dined and wrote poetry. Today we are expecting people to pay for their own training, spend the best years of their lives studying to pass tests, be hazed trying to get a job, for the privilege of getting worked to the bone for the benefit of a corporate entity. I thought only dystopian novels could think of a system so counter-productive and insane, until I read Brave New World and thought hm, this might be an upgrade over the life I'm currently living.
Anyhow :)
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.
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.
But if you work very closely with the business and often run into things that could be done or understood in different ways, having to wait a day or more to get a clarifying response would not work. And this is know-how that can't be written down easily if at all, since a lot of decisions are purely based on experience and historical knowledge.
I used to have this illusionary vision of how everything should be neatly documented, but if you operate on a constantly changing code base, it's really hard to find a good balance. Documentation gets outdated every few weeks and sometimes days, plus most of the time, you don't even know that said documentation has been written. As such, you can't fully trust the documentation and you always have to check out at least part of the code.
What seems to work for me, is documentation that gives a broad overview of a topic and then gives certain pointers into the code. That way you capture the essence of functionality that is likely to remain for a longer time and the transition from documentation to code is made easier.
And finally, if someone is stuck or doesn't understand something, I find it problematic to have the expectation that nobody may be available to read your message for the next few hours or whole day. What is more efficient, someone spending a couple of minutes to provide assistance or someone googling/search Jira/wiki/Confluence for half a day and not making any progress?
<remote_tz_projectmate> do you have time for a question?
<me> ... that's one. TTYL
[iterate]
Yahoo! had a TLA for it or something. It was the "hey, are you there" syndrome, coined back when their IM was king.
[edit: may have been AOL / same upshot]
Still, slack is miles better than wiki pages (go staled immediately), emails (even more broken threading interface), and heaven forbids google docs (impossible for collaboration, may work for bosses).
I think the best solution is something like zulip chat, complemented by wiki pages for "immutable" information.
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.)
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.
When the expectations are too high, it's likely that people won't get things down in the first place.
My team has noticed an unintuitive approach to communication that seems to work better than alternatives. Write better private notes.
Private notes are low-friction. You know what's worth writing. You don't need to worry as much about if it's a mess.
Our approach is to help you make your private notes a little better organized. And to make it fast to share these notes when they might be helpful to someone else too.
It's bytebase.io. Would love the community's feedback.
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.
A big part of it is habit or level of effort.
Force them to read books. Maybe something fun like a genre of novel that they like. Because the fundamental level of literacy is going to have a big impact on writing ability.
Have them find a forum of subreddit that they like and then regularly participate in it. And then offline or in a private message, fix their grammar and point out the problems with their communication.
Or just have them use written communications at work rather than in-person meetings etc. And then when the communication is lacking, point out the specific flaws.
The key to communication is to remember: "It's not what you say, it's what they hear." (Note: say can be written, and hear therefore read.) The mantra works either way.
Ultimately, the responsibility of the communication belongs to the sender. Improvement still takes work, but you'll progress faster if you have this foundation.
https://fastmail.blog/2020/05/22/email-for-remote-productivi...
Snir David writes well. One point that I think is missed in the "chats and video calls" is that you don't have situational awareness of whether the other person is busy like you do in person.
It's the same as the problem with taking phone calls when driving a car as compared to talking to people who are in the car with you. The people in the car with you can see when you're in a tricky traffic situation. The caller, not so much.
"Here is the thing: all that remote work in one of the biggest empires in history was accomplished without videoconferencing."
Why Videoconferencing Is for Rookies https://medium.com/swlh/why-video-conferencing-is-for-rookie...
Just my opinion built on my anecdotal experience.
I wrote my opinion here: https://www.naveed.dev/posts/consider-xp-for-distributed-tea...
However, I think his points are thought provoking, and it’s interesting to see how someone else thinks about the problem.
When you have the constant pressure from management to do X instead of writing on Y in a limited time, then you have no chance to write beautiful, centralised information. And so, the company itself accumulates technical debt, looses history and precious information that might be speed up people in the future.
That's why most of the people, after remote work become the norm, fallback to inefficient video chat rather than efficient text chat.
I like to think of myself as an effective writer. Nonetheless, it is incredibly difficult to express nuanced emotions through writing. This is particularly true in “professional” contexts, where an informal message may be perceived as rude. In many situations, I suspect that the same message, delivered verbally, would not even warrant a second thought.
The reality is that few people are taught to write in a manner that allows them to actually express their feelings. The fact that we even need to learn this indicates to me that speech is a far more effective way of getting our thoughts across
I need to find a way to tactfully say I prefer text...
"Too many words."
I trend prolix. In my essays, this can be corrected by post-edit, but it is not so easy to do that in realtime.
Asynchronous communication is essential to being able to focus, at least if you do enough communication that it matters how you communicate. And it's very inefficient to do asynchronous communication at scale in Slack or any of its copycats. This leads to the Slack cultural issues detailed in the post; they're the result of people working around the bad core workflow of a beautiful, masterfully marketed tool.
Consider "Everybody expects an immediate response" culture. In my view, that is people adapting to it being unpleasant to be a busy person waiting for a reply in a Slack channel. (Which is because it's miserable to make sure you don't miss things in busy slack channel, so everyone does, so anyone who wants to be sure of a response spams PMs and mentions and otherwise applies pressure to get a reply now now now so that they can mentally move on to their next task).
Zulip aims to make asynchronous communication so efficient that such adaptations are unnecessary. The core innovation is that all messages in channels are organized within "topics", which work exactly like the Subject field in email. This model works great for enabling asynchronous communication in email, and it works even better in Zulip (mainly because of topic editing and linking features).
The main goal of Zulip's interaction design is to make skimming hundreds or thousands of Zulip messages (and replying thoughtfully to the ones where you can add something!) pleasant. This enables a better way of working. Personally, I read and respond to 500-1000 Zulip messages sent by dozens of people across 50+ topics every single day, and I get compliments on how responsive I am, despite the fact that I do focus work in multi-hour blocks most days, Zulip's development community is all over the world, and I lose hours of productive time every day due to a chronic illness. This wouldn't be possible with Slack.
And this isn't just my experience; I've heard from so many people in organizations that switched to Zulip that they love how Zulip makes better use of the limited time they have (whether busy managers at companies or participants in part-time communities).
> "You'll lose your history"
This is the other major bundle of problems that Zulip's topics solve. Zulip can be a valuable knowledge store because of the organization provided by topics (combined with features like permanent links and topic-powered search workflows).
Zulip is 100% open source software (Not open core! We're intentionally not VC-backed so that we can prioritize our values; see https://news.ycombinator.com/item?id=23102430). And we sponsor free hosting on zulip.com for open source projects, academic research, and other non-commercial organizations.
Honestly finding programmers with good writing skills too is difficult.
It comes down to knowing your sources, not relying on some Bacon number of reinforced echoes.
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.
next question.
/me: an expert writer who sees no change on the horizon
However, for a small sort of private project. For example, if you have a very small team and can get people in a chat room consistently so that you can have solid conversations every day in there, that has worked better for me than using some kind of issue tracker. Especially in terms of dealing with clients or business-related team members. And maybe its really only for very small projects, like one or two developers, I don't know.
But for me, with most of the projects that I have been on my own building a product or tool for a client, the issue trackers and things like that worked against me and the project as far as I could tell:
- People would seem to think it was their job to fill the board/tracker up with as many things as they could think of. This caused extra stress and tended to make me want to rush through things to get them out of the way. The biggest problem with that was that it took time away from the really important things. And it is very difficult to get people to give realistic priorities.
- Sometimes, people would write critical information in the issue tracker or board, and I did not realize it had been updated or how critical it was. And so they operate with the assumption that they have communicated something, but actually I didn't see it until two days later.
- When they have a place to put an infinite number of tasks, it encourages them to increase the scope of the project, without having a real discussion or necessarily even thinking the feature through.
For me when doing projects on my own (or maybe with a designer) for a specific small group, there is just a limited amount of stuff that I can realistically finish in a given time frame. So I actually will not allow an issue tracker or board and try to get everyone to show up sort of simultaneously in a chat room. Sometimes people cannot or will not do that, and in those cases sometimes a phone call can work. Or maybe they actually are capable of reading and writing async messages in the chat room (not very common).
Basically every few days I meet in the chat or phone or whatever with the client and discuss what I have been working on in the last few days, walk them through the updates to the application. So something is being delivered and tested by the client every week or even every few days. Then we specifically talk about exactly what is the priority for the next few days. If there is development work that needs to be caught up on, then there may not be any new features to work on. Or there may be a feature that has been in progress, and the client gets an update on that.
Often the client has ideas for new features. Instead of putting them in a board or issue tracker to pile up, when they bring them up, we decide whether they are now higher priorities than other existing items and will fit into the work load of the next few days. Or, I tell them to remind me later. There is no such thing as a task that I will "get to when I have time". I have the client focus on the next most important priority and/or I explain the ongoing dev work, and we work out like 2-5 days of work and that's it. There is no infinitely expanding list of things to get to later. If something he has been thinking about is really important, it becomes a priority as soon as the previous task is completed. We check if I implemented something correctly as soon as it is implemented. We don't have to refer to a database of things, because we just talked about it a couple of days before.
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)
The absurdity of synchronous realtime communication is most evident when taking to an extreme of online coding. Nothing but crap is being produced.
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.