(highlight:: Working Remotely v.s. Working Asychronously: Challenges When It Comes to Sustainable Pace
Summary:
Remote work, if not managed properly, can lead to a culture of constant meetings, cluttering calendars and hindering deep focus.
This can affect both remote work and distributed work across different time zones. The constant meeting-centric culture can take a toll on personal lives, making it unsustainable to deliver projects.
Asynchronous work is seen as a solution to these challenges, allowing for a more pragmatic approach to communication by distinguishing what needs to be communicated in real time and what can wait.
Transcript:
Speaker 1
Yeah, to be honest, I try to decouple those two concepts of remote and async. And I'll tell you why, but of course, it works more effectively when you're remote, because when you're remote, if you're trying to do every interaction through a conversation, then Before long, your entire calendars cluttered with meetings, and each of us as a technologist on this conversation. So we know we need blocks of time where we are uninterrupted. We have a deep focus where we're able to hammer away at a problem either by ourselves or in pairs. And somehow a constant culture of meetings, which remote work drives, if you've not thought it through properly, can come in the way of that. But it also comes in the way of distributed work, which is another variant of remote work, which we've practiced for many years, right, where we work across geographies. And there, meeting-centric culture starts to take a toll on people's lives, because, well, I mean, I'm doing this call right now, this conversation at what, 940 my time. And if this was my daily routine, which often it happens to be for many people who are working across India and the US, then it starts to take a toll on people's personal lives. And so that as well, you can't be a sustainable way of delivering projects. And indeed, it's about sustainable pace. And so I think asynchronous work comes to the rescues in some of those places where we can take a more pragmatic approach towards what do you communicate in real time and what can wait A bit.)
- Time 0:01:43
- asychronous_communication, distributed_work, remote_work, sustainable_pace, meetings, synchronous_communication, work_performance,

(highlight:: Impose an Expiration Date on Slack Messages to Promote Proper Information Curation
Summary:
Many companies and teams have enforced policies to make Slack messages expire, with some setting the expiration period to 45 days.
The rationale behind this is to encourage the use of more permanent archiving methods for important information and to discourage reliance on Slack as a long-term storage solution.
Transcript:
Speaker 1
In fact, when I was doing the research for the book, one of the things I noticed, you mentioned Slack, a lot of companies that have been doing this for a while. And a lot of teams, that I worked with, they had a policy to make their Slack messages expire. The most extreme one that I saw was 45 days. So if you believe that it needs to be archived somewhere more permanent, then you better don't put it in Slack.
Speaker 4
I've seen some bots and stuff that just archive stuff. And I personally hated it because it just moves mud from one place to another.)
- Time 0:06:06
-

(highlight:: DEEP Framework: Documenting Decisions, Events, Explanations, and Proposals in Your Org
Summary:
The DEEP framework emphasizes the documentation of decisions, urging the recording of the rationale behind business and general decisions.
It also stresses the importance of documenting events such as meetings and town halls, highlighting the need for summarization. Furthermore, the framework encourages documenting explanations, especially in the context of onboarding, as they often involve repeated material.
Lastly, it emphasizes documenting proposals or ideas, allowing individuals to present their rationale to others and providing time for considered reactions.
The acronym 'DEEP' serves as a reminder for teams to consider the documentation created within their workflow.
Transcript:
Speaker 1
So I came up with an acronym as well, and I call that acronym deep. I think you'll identify with some of these. So deep for decisions, if there's ever a decision, then you should record the rationale for it. And we've talked about it endlessly on our tech radar's decision record systems. But I extend that to business decisions as well and general decisions as well. So similar format. Then there's events. So you have a town hall, you have a meeting, all of those are events, right? And you better document them for the benefit of other people. And when I say document, I mean, summarize, sure, you can have a recording or snippets of recordings if they are useful for people, but the summary is the more important thing. Then there's explanations, and I found these very useful in the context of onboarding, because there's a lot of explainer material that gets repeated in onboarding. And those are definitely great candidates for documentation. And the last one is proposals. And I called that proposals, but really I'm trying to talk about things like ideas. So let's take an example. I want to use this new library on my project. I have a certain rationale for it. Let me write down the thought process. What value is it going to bring? Let me present it to everyone. Everyone has the time to consume it. Oftentimes we go into decision making with a lot of cognitive load, where, you know, Ken explains in rapid fire things that he's been thinking about for the last 15 days. And now I have to consume it in the next 30 minutes and give Ken a year or nay. It's really difficult because Ken's done all the deep thinking, I need the time to process it and writing gives me the time to process it, right? And I can also not give knee jerk reactions, but considered reactions. So proposals, and that starts to include design documentation, idea papers, any kinds of proposals that you make on the team. So that acronym deep is a good trigger for teams to kind of hold on to and think about what is the documentation we're creating in the flow of work.)
- Time 0:09:12
- documentation, frameworks, organizational_knowledge, decision-making, information_architecture, knowledge_transfer,

(highlight:: High-Documentation Work Cultures Promote Inclusion of Non-Native Speakers
Summary:
In a multicultural team, communication at scale and onboarding benefit from having different English accents in play and from the availability of writing tools and spell checking tools.
These tools level the playing field and encourage empathy by making language simpler and prompting team members to slow down and consider opinions from all team members, regardless of their fluency in English. This promotes inclusion and prevents the domination of conversations by native speakers, creating a more welcoming and respectful work culture.
Transcript:
Speaker 1
I mean, one of the things which we often don't consider as a benefit, so communication at scale and onboarding, knowledge sharing being those two advantages, of course. Look, on this particular discussion, we've got three English accents at play. And in a multicultural team, people speak English differently. I came from a family where my mother spoke a different language, my dad spoke a different language, and then we have to default to a link language. And one of the link languages had to be English, right? But many people in my country don't learn English as a first language. So that becomes a challenge. And in certain circumstances where people, you have non-native speakers and native speakers of English, oftentimes, you know, you have this Captain America phenomenon where the Most experienced, the most extroverted, the most fluent person usually dominates the conversation. And that's not a great thing for inclusion. Whereas if you look at how tools have evolved, you've got writing tools, you've got spell checking tools, you've got tools like Hemingway that make your language simpler. So writing somehow levels the playing field a little bit. And then if you're consciously trying to be empathetic, then writing encourages you to slow down a little bit as well, where, you know, just because the proposal comes from the most Junior person on the team, you're not going to dismiss it offhand, you're going to take the time to read it because you're actively practicing empathy. And then you will give a considered opinion on that.)
- Time 0:14:08
-

(highlight:: Your Team's Communication Channels: Get Clear on Level of Engagement and Speed of Response
Summary:
Defining a team contract to specify the level of engagement and speed of response for each communication channel is crucial.
The exercise often reveals that phone calls are the only suitable medium for urgent matters like production bugs or client emergencies, as expecting constant interruptions through messaging platforms is unrealistic. Having a directory of phone numbers for urgent help is essential in such scenarios.
Transcript:
Speaker 1
And I feel like it's always good as a practice to define a team contract and say, which channel requires what level of engagement and what speed of response. And every time we've done that exercise as a team, we've discovered that the only urgent medium of communication, which is, you know, production bug, client needs our attention or The system needs our attention or everything's going to fire, right? The only medium for that is a phone call, because if you're expecting people to just keep command tabbing onto their slack, that basically means you're expecting them to be interrupted All the time. So you're you've got to have phone numbers in a directory and then call if you need urgent help.)
- Time 0:27:11
-

(highlight:: When to Use Synchronous vs Asynchronous Communication
Summary:
Consider the value you are seeking from communication.
When speed is essential, synchronous communication is preferable due to its immediate nature. Synchronous communication also helps in building connectedness and team cohesion, particularly in one-on-one interactions.
On the other hand, asynchronous communication is suitable for delving into depth, maintaining focus, and fostering thoughtfulness.
It allows for covering a breadth of topics at a rapid speed, making it useful for quick health checks and triaging multiple items efficiently.
Transcript:
Speaker 1
But what I'd rather ask individuals and teams to think about is what value are you getting from either mode of communication, right? So for example, if you're trying to, if you're trying to get speed, then going asynchronous is probably not the best idea, because you're going to be writing and it's, it hits by nature Slow, right? So, so in that case, you go synchronous. Similarly, if you're trying to build connectedness, right, we probably could have exchanged ideas even between the four of us on a Google Doc, but there is probably a sense of connection That we're building even this conversation where we are able to see each other and experience body language. So if I had to prescribe, I would say, one on once, absolutely, you've got to do those synchronously, right? And those are incredibly important practices to build team connection. And then if you want to cover a breadth of topics and you want to do them again, at speed, then that's a great candidate to do synchronously. So for example, if you wanted to do a quick health check, you wanted to look at your metrics and you see, all right, all of these high risk code branches, all of these reviews pending, and You want to do triage them at speed, no harm in getting into meeting because you'll do them at rapid speed and you'll get a lot of breadth in a short period of time, right? So, that tradeoff needs to be clear to people. If you want depth, you want focus, you want potfulness, you go towards async, you want speed, connectedness, spontaneity, then you go to words sync.)
- Time 0:28:22
-