#215 - The Async First Playbook: Build Effective and Inclusive Teams with Less Meetings - Sumeet Moghe
Summary
Sumeet Moghe, Principal Product Manager at ThoughtWorks and author of The Async First Playbook, joins the show to discuss the principles and practices of asynchronous-first work. He argues that meetings should be a last resort, not a default, and that written communication should be the primary mode of conveying information within teams. This shift requires accepting a “reasonable lag” in responses and is crucial for fostering deep work, reducing constant interruptions, and improving overall productivity.
The conversation delves into the critical importance of async-first practices for building inclusive teams. Moghe highlights how synchronous meetings often disadvantage non-native English speakers, neurodiverse individuals, working parents, and junior team members. Asynchronous communication, by allowing time for processing and composing thoughts, creates a safer and more equitable environment for contribution, leading to better decision-making by incorporating a wider range of perspectives.
Moghe addresses common leadership concerns, such as the fear that async work is slow or leads to idleness. He introduces the concept of “default to action,” where team members are empowered to make reversible decisions independently, documenting their rationale, rather than waiting for approval. This bias for action, combined with modern DevOps practices that allow for easy rollbacks, accelerates progress. Leaders must model this behavior by building their own skills in writing, deep work, and systems thinking.
Looking to the future, Moghe predicts that the demand for location autonomy from top talent, coupled with the rise of AI as a co-worker that thrives in async environments, will make asynchronous and remote-first companies more competitive. He advises leaders to move away from relying on serendipitous office encounters for collaboration and instead build intentional systems for knowledge sharing, decision hygiene, and effective communication to create sustainable, high-performing teams.
Recommendations
Books
- The Async First Playbook — Sumeet Moghe’s book, which details the principles and practices for building effective, inclusive teams through asynchronous work. It is based on his experiences leading distributed teams and extensive research.
Companies
- GitLab — Cited as a prime example of a large, global company that is both remote-first and async-first, with a well-documented handbook.
- Shopify — Mentioned as another large, global company that has adopted async-first as its default way of working.
- Automattic — Referenced as a smaller company that is explicitly async-first in its operations.
Concepts
- Async First Manifesto — The core principles championed by Moghe, including making meetings the last resort, prioritizing written communication, and accepting reasonable lag. These form the foundation of his recommended work model.
- Default to Action — A mindset where team members are empowered to make reversible decisions independently and document them, rather than waiting for meetings or approvals, in order to maintain velocity in an async environment.
Tools
- Swim.io — A sponsor of the episode, Swim.io combines static code analysis with generative AI to help developers, especially those working with legacy mainframe codebases like COBOL, understand and document their codebases rapidly.
Topic Timeline
- 00:01:44 — Introduction and Career Turning Points — Sumeet Moghe is introduced as the author of The Async First Playbook. He shares two major career turning points: joining ThoughtWorks, which introduced him to agile and servant leadership, and later leading a globally distributed team pre-pandemic. This experience forced him to move beyond traditional agile tools like “sit together” and develop the async techniques he later wrote about.
- 00:06:10 — Analysis of the Return-to-Office Trend — Moghe provides a nuanced take on companies calling employees back to the office. He explains that large firms with significant real estate investments (like big tech campuses) have little incentive to go fully remote. However, he argues that remote and async skills remain essential because even in hybrid settings, collaborators are often in different locations or time zones. For smaller companies, remote work can be a key differentiator in attracting talent.
- 00:13:48 — Survey Insights: Meeting Overload and Interruptions — Moghe shares key findings from his survey of thousands of IT workers. Most people prefer to work remotely most of the time, especially those with disabilities or caregiving responsibilities. The average IT worker spends 16-18 hours per week in meetings and faces about 18 interruptions daily. This constant context-switching is the enemy of the deep, creative work that knowledge workers need to be productive and satisfied.
- 00:17:56 — Defining Async First Principles — Moghe defines async-first with a provocative statement: “meetings are the last resort.” The core principles are: 1) Writing becomes the primary mode of communication. 2) Teams must become comfortable with a “reasonable lag” in responses, which they define themselves. He argues writing is accessible, editable, and easier to consume than audio/video. For true emergencies, a phone call is better than an expectation of instant Slack response.
- 00:27:49 — Async First for Inclusion and Better Decisions — This segment focuses on how async practices foster inclusion. Moghe describes the “Captain America phenomenon,” where fluent, experienced speakers dominate synchronous meetings. Async communication allows non-native speakers, junior team members, and those with caregiving duties to contribute thoughtfully. He also introduces a 2x2 matrix for deciding when a meeting is necessary, based on relationship strength (weak vs. strong) and purpose (convey info vs. converge on a decision).
- 00:32:35 — Default to Action and Reversible Decisions — To counter the perception that async work is slow, Moghe advocates for a “default to action” mindset. He distinguishes between reversible and irreversible decisions, noting that 99% of software decisions are reversible. Team members should be empowered to act on reversible decisions, document their choice, and learn from outcomes. This decentralized approach leads to faster progress, as teams that make more decisions also make more (reversible) mistakes and learn faster.
- 00:36:14 — The Critical Role of Leadership and Systems — Moghe emphasizes that leaders must first change their own behaviors to model async-first work. They need to move away from “hustle culture” and performative productivity (e.g., back-to-back meetings). Leaders should build skills in writing, deep work, and independent action. Their primary job is to create systems (e.g., integrated tools for real-time project status) that make the team’s work easier and eliminate unnecessary ceremonies like status-update meetings.
- 00:40:43 — Improving Writing and Reading Skills — The discussion turns to practical tips for effective business writing. Moghe suggests writing like a journalist using the inverted pyramid, putting the most important information first. Use tools for grammar, break text into short paragraphs, use bullet points, tables, and headings for scannability. He recommends estimating and stating the reading time for documents. For readers, he advises blocking 4x the estimated reading time to absorb and comment, and practicing reading daily to build the muscle.
- 00:51:48 — The Future of Work: AI and Talent Demands — Moghe predicts two major trends will drive async-first adoption. First, AI as a co-worker provides a “superpower” for async collaboration, offering instant assistance without needing deep work cycles. Second, top talent’s demand for location autonomy will eventually become the norm, as historically happened with laptops and smartphones. Companies that embrace location and time independence (async) will have a competitive advantage in accessing global talent pools.
- 00:58:54 — Three Pieces of Technical Leadership Wisdom — Moghe concludes with three manifesto-like pieces of advice drawn from his book. First, prioritize focus and cognitive flow over constant availability and performative productivity. Second, embrace AI as a co-worker and coach to elevate your work. Third, for leaders, rely on intentional systems for success (like decision processes or knowledge-sharing platforms) rather than hoping for serendipitous outcomes from office encounters.
Episode Info
- Podcast: Tech Lead Journal
- Author: Henry Suryawirawan
- Category: Technology
- Published: 2025-05-05T12:00:00Z
- Duration: 01:03:03
References
- URL PocketCasts: https://pocketcasts.com/podcast/tech-lead-journal/952099f0-a7bc-0138-e686-0acc26574db2/215-the-async-first-playbook-build-effective-and-inclusive-teams-with-less-meetings-sumeet-moghe/b00a5262-efc3-4031-be3b-df75126f02df
- Episode UUID: b00a5262-efc3-4031-be3b-df75126f02df
Podcast Info
- Name: Tech Lead Journal
- Type: episodic
- Site: https://techleadjournal.dev
- UUID: 952099f0-a7bc-0138-e686-0acc26574db2
Transcript
[00:00:00] meetings are the last resort and they are not the first option the average i.t worker is spending
[00:00:06] about 16 to 18 hours in meetings every week that’s about two and a half days in meetings every week
[00:00:11] you ran a survey with a few thousand people what preference they choose for work most people want
[00:00:16] to work remotely most of the days many people associate speed with execution and being
[00:00:20] productive that doesn’t necessarily mean that all the actions that you take in a fast manner
[00:00:24] is something that is effective right some leaders think actually if you work asynchronously
[00:00:28] and you are blocked to something people will just be idle or do something else but one critical
[00:00:33] distinction that you mentioned is the default to action mode why this is important if we really
[00:00:37] want to run high performing inclusive teams that are delivering outcomes without being stressed
[00:00:44] then how do we model the behaviors that we’d like our team to follow many of the
[00:00:50] skills that we learned during the pandemic about being effective at remote work become
[00:00:54] even more necessary if you want to run a high performing inclusive team
[00:00:58] post pandemic writing becomes the primary mode of conveying information in the team
[00:01:02] then obviously everyone needs time to process that right you need time to write and you need time to
[00:01:07] read so the first thing really is for the leaders to make that change in themselves be effective
[00:01:12] knowledge workers and then think about systems that you would put in place to make your team’s
[00:01:16] job easier what kind of possibilities that you think could happen in the future of work in terms
[00:01:22] of adopting async first i don’t think it’s a stretch of imagination to say that top talent
[00:01:28] wants
[00:01:44] hello everyone welcome back to detective journal podcast show today i have with me sumit mogi
[00:01:50] he is the principal product manager at thoughtworks he’s the author of the book async first playbook
[00:01:56] i think we have gone through pandemic and like i just mentioned how anything we do at the top of the
[00:01:58] And, you know, now everybody is starting to go back to office.
[00:02:01] But nevertheless, I think we’d still love to have this conversation and learn from Sumit
[00:02:05] how can we actually do asynchronous working mode much better, and whether this trend is
[00:02:11] still going to continue or it’s going to kind of like die down.
[00:02:14] So welcome, Sumit, to the show.
[00:02:16] Hey, thanks.
[00:02:17] Thanks for inviting me.
[00:02:19] Right, Sumit, I always loved in the beginning to invite my guests to actually share any
[00:02:23] kind of turning points that you think we can learn from you.
[00:02:26] Yeah, I think the biggest turning point in my career was to join ThoughtWorks.
[00:02:34] And the reason why ThoughtWorks was a career turning point is for a couple of reasons.
[00:02:39] It introduced me to the world of agile.
[00:02:41] It introduced me to a very different style of leadership where leaders were not necessarily
[00:02:46] meant to be the bosses of people, but to be the people who remove blockers.
[00:02:51] Even to this day, we appreciate leaders being in the deep end.
[00:02:57] And not being overlords who sit above the details, right?
[00:03:00] And so that completely changed my mindset about what it takes to be a leader and what
[00:03:05] it takes to run effective teams.
[00:03:06] And then somewhere in the middle of my consulting journey, I happened to be on a team where
[00:03:12] most of my colleagues were in another continent.
[00:03:17] And this happened well before the pandemic.
[00:03:20] And that’s where a lot of my traditional agile tools of collaboration failed.
[00:03:26] Because agile, at least the way it’s written in the XP book is sit together, right?
[00:03:31] And so there is no sitting together when all of your colleagues are in other countries.
[00:03:35] And it’s not even as if your colleagues are sitting together.
[00:03:38] And I had to figure out how am I going to run a high performing team between people
[00:03:44] sitting in Belarus, Ukraine, Belgium, Germany, and the US.
[00:03:50] And that became a turning point, particularly because while making my own mistakes, while
[00:03:55] learning how to run a team, I had to figure out how to run a team.
[00:03:56] And I had to figure out how to run a team.
[00:03:56] And so in order to make that team productive and be productive in that team myself, I picked
[00:04:00] up many of the concepts and the techniques that I wrote about in the book.
[00:04:04] So I’d say those were two big turning points in my career.
[00:04:07] This episode is brought to you by Swim.io.
[00:04:10] And I’m excited to have its CTO and co-founder, Omer Rosenbaum, with me today to tell you
[00:04:16] more about Swim.
[00:04:17] Hi, Henry.
[00:04:17] Very nice to meet you.
[00:04:18] And thank you for having me.
[00:04:20] So tell us a little bit more.
[00:04:21] What is Swim.io?
[00:04:22] At Swim, we want to help companies understand their
[00:04:26] codebases.
[00:04:27] We combine static code analysis with generative AI to create comprehensive documents that
[00:04:33] help you navigate the codebase.
[00:04:35] As an engineer myself, I wouldn’t want engineers to spend so much time understanding existing
[00:04:41] code.
[00:04:41] I would want them to spend time creating and building new stuff.
[00:04:45] When you have code that has accumulated over decades, and especially in legacy languages
[00:04:51] that not many people are adapted nowadays.
[00:04:55] Then the problem is even bigger.
[00:04:58] Swim.io is specializing into helping mainframe developers to understand their codebase.
[00:05:03] Why mainframes?
[00:05:04] We actually didn’t start there.
[00:05:06] COBOL had been, by some people, obsolete for a few years, and I discovered that it’s not
[00:05:14] really obsolete.
[00:05:14] Not at all.
[00:05:15] There are more than 800 billion lines of COBOL code that are in production, and they drive
[00:05:20] lots of the business in the world.
[00:05:22] And we got more and more requests.
[00:05:25] From customers to help them understand the legacy codebases.
[00:05:30] This was written decades ago and accumulated over a very long period of time.
[00:05:35] So from your customers so far, what are some of the success stories that you can share?
[00:05:39] So we worked with an analyst who shared with us that it took them a year to document a
[00:05:46] single mainframe application.
[00:05:48] And using Swim, they were able to document a similar application in a matter of hours.
[00:05:52] So saving that amount of time enables them to.
[00:05:55] Focus on other tasks.
[00:05:58] Thanks, Omer, for sharing with us about Swim today.
[00:06:01] To learn more about Swim, check out their website at Swim.io.
[00:06:06] Very interesting that you actually learn, you know, doing all this remote, asynchronous
[00:06:10] working style before even the pandemic, right?
[00:06:12] And I’m sure back then during the pandemic, you kind of like probably one of the champion of
[00:06:17] doing this remote work.
[00:06:19] So maybe let’s start to this discussion, right?
[00:06:21] So I think we can see the current trends.
[00:06:24] Almost every company.
[00:06:25] Is going back to the office, or maybe they adopt some flavor of, you know, I don’t know,
[00:06:29] flexible or hybrid working style.
[00:06:32] Even the big techs are forcing people to go back to the office full time.
[00:06:36] What is your take to all this current trend?
[00:06:39] Yeah.
[00:06:40] So there are a couple of takes I have.
[00:06:41] One is that it’s a good thing.
[00:06:43] While I happen to be a big remote work advocate, I know that every company is not going to do remote
[00:06:49] work and every company is not going to do a hundred percent remote work.
[00:06:52] And there are lots of reasons for it.
[00:06:53] I can elaborate on it a little bit.
[00:06:55] I used to work for one of the witch companies in India.
[00:07:00] These are all the consulting firms.
[00:07:02] So there’s Wipro, Infosys, DCS, Cognizant, HCL.
[00:07:06] These employ hundreds and thousands of people.
[00:07:08] They have big campuses.
[00:07:10] Now, one of the campuses I used to work on was a 300 acre campus.
[00:07:14] There is no incentive for that company to leave their 300 acre campus empty so that
[00:07:20] people can work remotely.
[00:07:21] They’ve incurred the capex on it.
[00:07:24] In a similar way.
[00:07:25] Is there any incentive for Google to leave Googleplex empty or for Amazon to leave Cupertino
[00:07:31] empty?
[00:07:32] There isn’t, right?
[00:07:32] They’ve spent millions of dollars in setting up those complexes.
[00:07:36] And let’s say Amazon or Google or Apple set up a rule for their headquarters because they
[00:07:43] love their headquarters.
[00:07:44] Can they then say that people in satellite offices don’t come to the office?
[00:07:48] It’s very hard, right?
[00:07:49] So there are lots of these constraints because of which certain companies just can’t do their
[00:07:55] job.
[00:07:55] They cannot be 100% remote.
[00:07:57] We have to accept it.
[00:07:59] Other part of it is that certain companies also benefit from showing that people are in
[00:08:05] the office.
[00:08:05] Now, I work in the IT outsourcing industry.
[00:08:08] Now, imagine you want to win over a client.
[00:08:10] If you want to win over a client, you make them come to your country.
[00:08:14] You make them come to the office.
[00:08:15] And then if the visual is an empty office, it’s not a very impressive visual.
[00:08:19] But if your visual is a campus full of people, then you can show your strength.
[00:08:24] So certain businesses…
[00:08:25] Business models are not conducive to remote.
[00:08:27] So you have to understand that this isn’t because remote is bad.
[00:08:31] It’s just because certain companies are not set up for remote.
[00:08:34] But one of the things we need to be aware of is that there is a narrative that gets
[00:08:39] fueled by the big companies.
[00:08:41] And there are more small companies in this industry than there are big companies.
[00:08:45] So even if you think of my country, India, you look at the big tech, which is Tesla,
[00:08:51] Alphabet, Meta, Microsoft, Amazon, Netflix, Apple, all of those.
[00:08:55] So which companies, which I mentioned, they are just 28% of the companies that exist.
[00:09:01] In fact, even the workforce, when I say 28%, they employ 28% of the workforce.
[00:09:06] The remaining 72% work in smaller companies.
[00:09:09] And the smaller companies don’t have CapEx incurred, for which they need to keep pulling
[00:09:14] people into the office.
[00:09:16] Every bit of operational expense that they can save works for them.
[00:09:20] So if it’s a cynical business decision for them to decide, do we call people into the
[00:09:24] office?
[00:09:25] Or do we let them work remotely?
[00:09:26] And right now is a hard time for tech.
[00:09:29] So a lot of the smaller companies are still choosing to be remote.
[00:09:33] So where I’m getting at when I say this is a good thing with people calling, companies
[00:09:36] calling employees back into the office, is that for the smaller companies where winning
[00:09:42] talent was a very difficult task in 2022, when big money was getting thrown out, now
[00:09:49] remote work can be a differentiator.
[00:09:51] You can now start saying, hey, we will pay you a little less.
[00:09:55] Then let’s say Amazon, but you can work remotely, no problem.
[00:09:58] And some people will take that offer.
[00:10:01] So that’s one part of it.
[00:10:02] But the other part of it is that let’s say you work for an Amazon, or let’s say you work
[00:10:05] for Microsoft.
[00:10:06] I mean, Microsoft is actually very permissive with their remote work.
[00:10:09] But let’s say you work for an Amazon.
[00:10:12] Will you have collaborators in another office?
[00:10:14] You absolutely will.
[00:10:16] Will you have collaborators who potentially are working from home on any particular day?
[00:10:21] You’re most likely to.
[00:10:23] Which means that somebody is remote.
[00:10:25] In relation to you on any given day.
[00:10:29] And so many of the skills that we learned during the pandemic about being effective
[00:10:33] at remote work become even more necessary if you want to run a high-performing, inclusive
[00:10:39] team post-pandemic.
[00:10:41] So those are my two takes on the return to office phenomenon.
[00:10:46] Yeah.
[00:10:47] So I think the narrative these days is always about the headline news, right?
[00:10:50] Like company X, big tech X is inviting people to go back to the office five days.
[00:10:55] A week, right?
[00:10:55] You know, they even put like a strict email saying that if you don’t follow, then you better find another job or something like that.
[00:11:01] Right?
[00:11:01] So I think the narrative there is pretty clear for some of those big tech, especially as you mentioned, they kind of like have all these big premises and maybe they have invested a lot in actually making sure that people work productively in the office, arguably.
[00:11:14] But I think, I also think that what you said, right, at any given day, you will work, especially if it’s a multinational company, right?
[00:11:20] You will work with someone remote, different time zone, different location, different countries.
[00:11:25] And, you know, these skills will be still important, right?
[00:11:28] And async is not necessarily just work from home, I guess it could be work from, you know, like what you mentioned, right, multi-countries and all that.
[00:11:36] So maybe anecdotally, have you ever heard also big companies who switch fully into like, you know, more async first rather than, you know, going back to the office?
[00:11:46] So some of this is never an all or nothing switch, Henry.
[00:11:51] There are companies who embrace async first.
[00:11:55] As their default way of working, but they happen to also be remote first companies.
[00:11:59] Examples of these companies will be GitLab, really big company, really global, and they are async first.
[00:12:06] Another good example of async first is Shopify, right?
[00:12:10] Really big company, fairly global, and then also happens to be async first.
[00:12:15] Spotify is another company, which is async first, right?
[00:12:19] And then amongst the slightly smaller companies, you will see Automatic.
[00:12:23] Now, these are companies that say, you know, I’m going to do this, I’m going to do that.
[00:12:24] So they say async first, and they are very, very explicit about it.
[00:12:29] But in other companies, which are big, but have different modes of working, depending on their team, you will find that there is a growing appreciation that you cannot do everything synchronously, because then your calendar just gets full of meetings.
[00:12:44] And so you need other ways of communicating information inside a team, other ways of collaborating on complex ideas, and other ways of arriving at decisions.
[00:12:54] So I don’t see it as an all or nothing.
[00:12:57] You are all async first or all sync first.
[00:13:00] I see that it’s a gradual shift.
[00:13:01] And even in my book, I kind of represent it as a spectrum, right?
[00:13:05] That you choose the mode of collaboration based on the outcome that you’re trying to achieve.
[00:13:11] So I think very interesting that you mentioned that, right?
[00:13:14] Because obviously, there are many flavors of doing async and all that, right?
[00:13:18] So it’s a spectrum, definitely, right?
[00:13:20] And I think one thing in particular that I find interesting in your book, you mentioned that you ran a survey.
[00:13:24] With a few thousand people, I guess, right?
[00:13:27] So asking them what preference would they have when they choose for work, right?
[00:13:31] I think this is really interesting, especially after pandemic, people have experienced remote.
[00:13:35] And I feel also like many people that I know, they prefer working, you know, it’s kind of like more remotely, working from home or more flexible kind of working arrangement.
[00:13:44] So tell us about this trend and what do you actually find insights from your survey?
[00:13:48] The biggest insight that you want to take away is most people want to work remotely most of the days.
[00:13:54] The numbers are not.
[00:13:54] Important, right?
[00:13:55] And I think this is true.
[00:13:56] You can just poll your friends, poll any group, and you will see most people, given a choice, will want to work remotely most of the time.
[00:14:04] There will be exceptions.
[00:14:05] If you try to fine tune this observation, then you will see that people with disabilities, about two thirds of them will want to work remotely, especially in countries like India, where people with motor disabilities find it very difficult to get around the city.
[00:14:20] Then if you start looking at working parents, especially women who.
[00:14:24] Shoulder a disproportionate burden of the household responsibility, being able to include them often means being able to accommodate flexible work of some kind, right?
[00:14:36] So they also prefer remote work.
[00:14:38] So these are very, very intuitive observations.
[00:14:41] I think we know about this now very well, and that’s what the survey threw out.
[00:14:46] But the other things that people told us is that, you know, the average IT worker is spending about 16 to 18 hours in meetings.
[00:14:54] Every week, that’s about two and a half days in meetings every week.
[00:14:58] Of course, there are some who are spending 40 hours and then there are some who are spending eight hours, but 16 on average.
[00:15:05] And that’s a lot of hours in meetings.
[00:15:08] Right. And this has somehow increased during the pandemic, because what used to happen is, Henry, if you sit on a table side by side, you wouldn’t account for the interruption.
[00:15:22] But the interruption was always there.
[00:15:24] Where I’d be sitting next to you and I’m stuck at something and I’d be like, Henry, I tap your shoulder and I say, Henry, can you help me with this?
[00:15:33] And then what have I done at that point?
[00:15:35] You were probably in your flow trying to solve a problem.
[00:15:38] I disturbed your sense of flow.
[00:15:40] Right. So I created that interruption for you.
[00:15:43] And people report this, that be it meetings, be it a Slack message, be it anything else, they’re facing about 18 interruptions a day.
[00:15:52] So those are the stunning findings.
[00:15:54] That we spend way too much time in meetings and we get interrupted way too much.
[00:16:01] And that has a direct impact on our job satisfaction, because most of us who are in tech, we’re in tech because we like solving complex problems.
[00:16:12] And to solve complex problems, you need spells of deep work, especially if you’re doing anything creative.
[00:16:19] You don’t work in 30 minute spells and one hour spells.
[00:16:23] You often work in two or three.
[00:16:24] You often work in three hour spells and you get a real kick out of it when, you know, you’ve been working for three hours and at the end of three hours, you have a breakthrough and you feel like, oh, bloody hell, I actually achieved something.
[00:16:36] Right. I’m sure you’ve achieved you’ve had this feeling, right.
[00:16:39] Doing some creative work at the end of it.
[00:16:41] But imagine that you are five minutes into this creative work and somebody taps your shoulder or a Slack message pops up or 30 minutes into your work, you realize, oh, dang, I have a Zoom call to attend.
[00:16:54] Where is your flow and where is your productivity and where’s your deep work?
[00:16:58] So I think that happened to be the biggest casualty that I was trying to address.
[00:17:01] And I think that’s one of the biggest insights that we can take away as well, that we are way too interrupted and we have way too many meetings.
[00:17:09] Yeah.
[00:17:09] So I think everyone here who listened can really relate to these problems, right?
[00:17:13] Too many meetings, too many interruptions.
[00:17:15] Interruptions doesn’t always mean, you know, physical, it could be digital as well, right.
[00:17:19] Your messages, you know, your emails, your notifications, whatever that is.
[00:17:23] And also regarding the content.
[00:17:24] Commute, right.
[00:17:25] So people have to spend time.
[00:17:27] It could be hours for some to spend, you know, going to the office and also back, especially in those cities which has bad traffic.
[00:17:34] I think that’s also a lot of time being wasted on the road.
[00:17:37] So I want to ask you first, could you actually define what do you mean by async first, right?
[00:17:42] Because there are so many different interpretations these days.
[00:17:45] You know, some people think it’s work from home.
[00:17:47] Some think it’s remote work.
[00:17:49] Some think it could be like digital nomad.
[00:17:51] You know, you can work anywhere as long as you have internet.
[00:17:54] So.
[00:17:54] What do you mean by async first?
[00:17:56] Maybe let’s start from there and then we can dive deep into it further.
[00:17:59] Yeah.
[00:18:00] One provocative sentence, Henry, and that provocative sentence is that meetings are the last resort and they are not the first option.
[00:18:10] And it’s provocative for the simple reason that we’ve now gotten into a point where we default to meetings as a way of collaborating.
[00:18:20] And it doesn’t have to be that way.
[00:18:22] We need to be a little more thoughtful about how we collaborate.
[00:18:24] This is not to say meetings are bad.
[00:18:26] This is not to say we should ban meetings, but we are saying that it should be the last resort.
[00:18:31] Now, when you say meetings are the last resort, then it devolves into two sub principles, which means that if you cannot convey everything real time, then there has to be an alternative to that real time.
[00:18:43] And so writing becomes the primary mode of conveying information in a team.
[00:18:49] And if writing has to become the primary mode of conveying information in a team.
[00:18:54] And by the way, I’m ready for all objections to this, right?
[00:18:57] If writing becomes the primary mode of conveying information in a team, then obviously everyone needs time to process that writing.
[00:19:05] You need time to write and you need time to read.
[00:19:08] So you need to also be comfortable with reasonable lag.
[00:19:12] And what is that reasonable lag is something that you define inside a team.
[00:19:18] So, for example, what is the reasonable lag to respond to a pull request?
[00:19:24] What is the reasonable lag to respond to an IM?
[00:19:28] Or let us say you’ve written a design document.
[00:19:31] What is the reasonable lag to get feedback on that design document?
[00:19:36] This is what you need to define inside a team.
[00:19:38] OK, let’s assume that there is a big production issue that needs urgent attention.
[00:19:44] How do I get in touch with somebody?
[00:19:47] Because, again, in that case, you would say I should be able to slick message somebody if it’s urgent.
[00:19:53] But.
[00:19:54] If you step back for a minute and think about it, that then means that somebody should be looking at Slack all the time.
[00:20:00] They need to be command tabbing between their ID and Slack saying, oh, did Henry message me or did Sumit message me?
[00:20:06] Which means you’ve built interruption into their work, right?
[00:20:09] When you think about it that way and say zero lag, but we also don’t want interruptions.
[00:20:15] The simplest way of being able to connect with people if it’s urgent is to just pick up the old instrument that we all have, which is the phone and call.
[00:20:24] Somebody saying it’s urgent, right?
[00:20:26] So this is what I mean.
[00:20:27] Writing becomes the primary way of communicating and we all become comfortable with reasonable lag.
[00:20:33] And why writing?
[00:20:33] I’ll just add a little bit to it.
[00:20:35] It’s something that you can produce quite quickly.
[00:20:38] All of us have a minimum of 16 years of education if you’re working in tech.
[00:20:44] So everyone knows how to write.
[00:20:46] Plus, if you use any writing tool, it helps you correct your spelling.
[00:20:51] It helps you correct your grammar.
[00:20:52] It.
[00:20:54] You can add buttons, things for you.
[00:20:56] You can add headings, you can cut and move things somewhere else.
[00:20:59] You can’t do that with video and audio that easily, right?
[00:21:02] So writing is a little easier to produce than anything else that people will consume.
[00:21:07] So that’s why writing.
[00:21:08] Yeah.
[00:21:09] So I think very intriguing.
[00:21:10] So the way you define async, right?
[00:21:12] The first principle is like meeting should be the last option, right?
[00:21:15] If you think you want to create meeting, think of it as a last option.
[00:21:19] So it should not be the first option when you want to communicate with others.
[00:21:23] And then second thing is.
[00:21:24] The primary communication mode, right?
[00:21:25] So it could be, you know, messages, it could be docs, right?
[00:21:28] It could be whatever PR pull requests and things like that.
[00:21:31] Right.
[00:21:32] And then the last thing is that you should tolerate a reasonable lag.
[00:21:36] And I think this reasonable lag is something that you need to define as a team, right?
[00:21:39] Which means like having all this, it seems like there must be a guideline that the team or the organization needs to define as a kind of like a principle, right?
[00:21:48] And in your book, you mentioned about team handbook or maybe organization handbook.
[00:21:52] I know that GitLab also have remote handbook.
[00:21:54] And things like that.
[00:21:55] Is this something that really, really important for async first team?
[00:21:59] For any team, in fact, because every team has a way of working.
[00:22:03] If you don’t write it down, people are imagining it anyway.
[00:22:07] So it’s always better to write it down.
[00:22:08] So you don’t leave anything to imagination and it’s okay.
[00:22:12] You won’t get it right on the first day.
[00:22:14] Start with a few sensible defaults, right?
[00:22:17] Start with whatever feels sensible, reasonable on the first day.
[00:22:21] So if you feel, for example, that we should be responsible.
[00:22:24] If you feel that you’re not responding to emails in 48 hours, put it in and then wait for somebody to complain and if somebody complains, then you can change it, right?
[00:22:32] You’ll get a feedback loop, but that doesn’t stop you from writing it up.
[00:22:35] Now, the problem with many of these exercises in writing team guidelines, team ways of working, team handbooks is that people get obsessed with perfection.
[00:22:44] Don’t get obsessed with perfection, be okay with good enough and there are many sensible defaults.
[00:22:49] You can even come to my website and take a look.
[00:22:51] There’s lots and lots of these sensible defaults.
[00:22:53] So yeah, you can recommend it to some other teams.
[00:22:56] GitLab has a lot of sensible defaults as well.
[00:22:57] So yeah, agreeing those ways of working is absolutely crucial.
[00:23:01] So I like that you mentioned no matter what, whether you’re async first or maybe you work in the office, right?
[00:23:07] Please come up with a handbook, right?
[00:23:08] I think it’s a very, very good guideline for, you know, defining ways of working, because as the team grow larger, in fact, our organization grows larger, right?
[00:23:16] You will need to define some kind of SLA or, you know, primary mode of communication expectations with other teams.
[00:23:22] All this can be defined in the handbook.
[00:23:23] handbook right so i know that you must have dealt with these kind of arguments before right because
[00:23:29] if you mentioned meeting should not be the first option we all have to write first and you need to
[00:23:34] accept reasonable like many leaders i would assume especially those who are like action oriented
[00:23:39] will find it very difficult to adapt to this kind of working style they think it’s too slow they
[00:23:45] think it’s less productive they think that it’s very difficult to reach out to people so maybe
[00:23:50] if you can give us some comments on this kind of arguments yeah so look you’ve got to ask yourself
[00:23:57] a couple of things about meetings right one is who is meeting and what are you trying to
[00:24:05] meet for right i have a concept and you i’ll ask your users to try and visualize your audience to
[00:24:16] try and visualize this two by two matrix okay so on the x-axis
[00:24:20] try to measure the strength of the relationship of the group of people who are meeting so on the
[00:24:26] right hand side you can have a strong relationship and you can have on the left hand side a weak
[00:24:32] relationship between the people who are meeting and then think about the purpose that you’re
[00:24:37] trying to achieve with this group of people you’re either trying to convey information
[00:24:42] or you’re trying to converge on a decision so now let’s try to look at it case by case
[00:24:49] strong relationship between the people who are meeting and the people who are meeting
[00:24:50] strong relationships and you’re only trying to convey information in these situations you don’t
[00:24:56] need a meeting you can just write an email write a document and it’s fine there is no chance of
[00:25:01] misunderstanding people have a strong relationship or a very small chance of misunderstanding go ahead
[00:25:07] and just send the information people can read you don’t have to read to literate people now imagine
[00:25:12] that you have people who have a weak relationship who are trying to then converge on a decision
[00:25:20] very simple there’s a lot of chance of misunderstanding and you’re also trying to do
[00:25:25] something which is fundamentally more difficult converging on a decision is more difficult than
[00:25:29] just conveying information so in such a case no problem do a meeting much better it helps your
[00:25:36] relationship and it also helps you get to the decision faster now let’s imagine somebody that
[00:25:43] you have a weak relationship with who you’re trying to convey information to ideally you
[00:25:48] should just be able to send the information to the person who you’re trying to convey information to
[00:25:50] them in a document or an email or a message but sometimes it helps to spend the time to build
[00:25:57] the relationship so maybe do a few meetings to build the relationship get them to the quadrant
[00:26:02] where the relationship is strong and then start going async and then think about the last bit
[00:26:08] which is you have people who have a strong relationship who are also trying to converge
[00:26:15] on a decision now in this situation you can take a blended approach where
[00:26:19] some part is asynchronous and some part is synchronous so how do you do it let’s say
[00:26:25] henry you and i are on a team with a few other people before a decision has to get made everyone
[00:26:31] needs to have the same information right let’s say we are trying to change one of the frameworks
[00:26:36] which we are using on the project it’s a team decision before that everyone needs to know what
[00:26:42] are our choices so they need to study all of that so how about you share all of that information
[00:26:46] asynchronously give everyone the time to share feedback and then you can make a decision about
[00:26:49] and then when it comes to making the final high stakes decision you get into a meeting
[00:26:53] now when people say oh no no i want speed i want action you need to ask them are you mistaking
[00:27:01] speed and productivity speed and productivity aren’t the same thing you can do unproductive
[00:27:06] things really fast what you need to be looking at is decision hygiene the process that you follow
[00:27:13] is that actually repeatable stress-free and then you will get the right answers about what you
[00:27:18] should be doing
[00:27:19] yeah so i think many people associate speed with execution and you know being productive right
[00:27:25] well that doesn’t necessarily mean that all the actions that you take in a fast manner right is
[00:27:30] something that is effective right so this is something especially in the knowledge work
[00:27:34] where programming you know maybe creating materials contents documents and all that
[00:27:39] which needs a lot of thinking and i think one thing also very very important that i read from
[00:27:44] your book you mentioned that because in a typical meeting right not everybody naturally will
[00:27:49] participate simply because some are introverts some don’t have enough information when they join
[00:27:53] the meeting or some just don’t know why they are there and i think this point of about inclusion
[00:27:59] right where people are given some time to actually process digest giving comments feedback and doing
[00:28:04] some kind of analysis so tell us why this inclusion very very important and how async first actually
[00:28:09] helps to solve this yeah i call it the captain america phenomenon so henry you in singapore
[00:28:17] people speak english everywhere or anywhere in the world and i think that’s a very important
[00:28:19] thing to think about and i think that’s a very important thing to think about and i think that’s a very important thing to think about
[00:28:20] right but even then you and i speak english very differently we have different accents now you
[00:28:26] start thinking about this as a global team see in my country we have 20 odd official languages and
[00:28:33] 500 plus documented languages and many people don’t speak english as a first language now try
[00:28:40] imagining a situation where somebody comes from a small town they’ve not spoken english as a first
[00:28:46] language growing up they probably don’t have your first language but they probably don’t have your
[00:28:49] first language but they probably don’t have your first language but they probably don’t have your first language
[00:28:50] experience in the industry now if it was you as the tech lead and me as the product manager
[00:28:56] and these inexperienced and also not fluent in english people out there add let’s say women into
[00:29:03] the mix add let’s say neurodiverse people into the mix guess who’s dominating the conversation
[00:29:08] it’s the people who have experience it’s the people who are fluent in english and if you
[00:29:14] want to run an inclusive team you don’t want to just hold your ideas hostage to something
[00:29:19] somebody’s fluency in a language you don’t want to hold your ideas hostage to somebody’s
[00:29:24] experience because i have found in a very humbling manner that a lot of ideas come from the most
[00:29:31] junior people in the team because they will think of things that experts don’t think of
[00:29:36] and you’ve got to create the environment for them to feel safe to contribute where they can take the
[00:29:42] time to read what you’ve written and they can write something in safety see the thing is even
[00:29:48] if i’m not fluent in english i’m not fluent in english i’m not fluent in english i’m not fluent in
[00:29:49] english i can put my statement into a word processor ask it to correct the grammar and
[00:29:54] then post my question or comment i i don’t feel that bad as compared to if i have to speak on a
[00:30:00] zoom call because zoom is not going to translate my english in real time so all of these are impacts
[00:30:06] but then start to think about a few other situations let’s say you have a parent who
[00:30:12] is not able to attend your decision making call because they have a parenting responsibility
[00:30:17] would you like them not tolu
[00:30:19] be part of the decision-making process just because they are a parent, you should be able
[00:30:23] to take their inputs, right? And this is where using an approach which takes people’s inputs
[00:30:29] asynchronously and blends asynchronous and synchronous communication gives you the best
[00:30:34] chance of running an inclusive team with a good cast of characters. And let’s take a step back.
[00:30:40] Why is this important, right? I mean, lots of companies in the US are killing their DEI
[00:30:46] programs. And I think it’s a good point for us to reflect as an industry as to why is this
[00:30:51] important. It’s important because we come with our own sets of biases when we build software,
[00:30:58] when we build solutions. The more diverse our group, the more we are likely to cancel out each
[00:31:04] other’s biases. And for the simple reason that you want to build better solutions, you need to
[00:31:10] have a diverse team. But even otherwise, you know, Singapore is a multicultural country, city.
[00:31:16] India is multicultural. I think teams have a responsibility to reflect the way society is,
[00:31:21] right? So that’s another very important reason why teams should look like the society that they
[00:31:27] exist in. And so it’s very important that you look at inclusion as a first-class responsibility for
[00:31:32] any leader to take care of. And if that is a first-class responsibility,
[00:31:37] then Async First becomes a great tool for you to employ.
[00:31:40] Yeah, so I think the point about language fluency, in fact, is very, very important, right? Because
[00:31:46] now that everyone is kind of like having multinational teams, right? We kind of like
[00:31:51] assume that people can speak English, but actually the fact is not everyone is fluent in English.
[00:31:56] Some, maybe because of being afraid of being embarrassed when speaking in English,
[00:32:00] broken English, to be precise, right? They tend not to speak out. But I think giving them a chance
[00:32:06] to actually be included as part of the discussion, as part of the team, giving their best critical
[00:32:11] input, I think is something that is very, very important, right? The other thing that you
[00:32:16] Async First team, right? There’s one thing that in particular kind of like alleviate this speed
[00:32:20] problem, right? There’s this thing called default to action, right? Some leaders think actually if
[00:32:24] you work asynchronously and you are blocked to something, people will just be idle or do something
[00:32:30] else, watch YouTube probably. But actually, this is one critical distinction that you mentioned is
[00:32:35] that the default to action mode. So tell us a little bit more about this, why this is also
[00:32:39] important. Yeah, and I think this has become a lot easier in the last 10, 15 years because of
[00:32:45] continuous delivery and all that kind of stuff. So I think it’s a really important thing to
[00:32:46] look at when it comes to making decisions that are reversible, to make decisions that
[00:32:50] are irreversible, and to say that this is interesting, because we now have all of the
[00:32:54] good DevOps practices that we have in place, where almost everything we do in software is
[00:33:01] reversible. So the way to look at this is that there are reversible decisions you make. And
[00:33:08] there are irreversible decisions you make. I think it’s fair to say that 99% of the decisions that
[00:33:14] you will make will be reversible.
[00:33:16] within the space of one day, you’re not going to make a change in code, which hasn’t even gone to
[00:33:22] production, probably has just gone to UAT, which will tank the business. So in these circumstances,
[00:33:29] let’s say you are working on a piece of code, or you’re working on a piece of design,
[00:33:33] and you would love to get somebody’s input, but you’re not able to get it. What do you do? You do
[00:33:39] the best you can, document the decision that you’ve made, and move on. You have a bias for
[00:33:46] action. You default to action. Now, there are two possibilities. One is, great, everything works
[00:33:53] fine, you made the right decision. That is the happy path. The sad path is that something went
[00:33:58] wrong. But if it’s a reversible decision, no problem, right? You should be able to backtrack.
[00:34:03] So if it’s code you’ve committed, you can roll it back. If it’s a design that you pushed
[00:34:09] forward, you can roll it back. If it’s a design that you pushed forward, you can roll it back.
[00:34:09] If it’s a design that you pushed forward, you should be able to take it back. So as long as
[00:34:13] you have the humility to learn, bias for action works well. Now, there is also a bit of team
[00:34:18] learning to happen here, wherein you spend some time to say, there are certain categories of
[00:34:23] decisions that we will take with some ceremony, but there are other decisions that we will
[00:34:28] decentralize as much as possible. And there are ways of decentralizing your decisions as well,
[00:34:33] right? You can choose team structures that give you a little bit of decentralizing power.
[00:34:38] But the idea is that you have to be able to take it back. So as long as you have the humility to
[00:34:39] idea should be that most decisions can happen at the level of the individual and you don’t need to
[00:34:45] get 10 engineers to screw in a light bulb. Because Henry, you and I know this, any team that makes
[00:34:51] more decisions will make more mistakes. Yes, but they will also make more progress. And if most of
[00:35:00] those mistakes are reversible, then it’s a good cost of progress. Yeah, so I think intuitively,
[00:35:08] right?
[00:35:08] When we listen to just now what you mentioned, right? So the team which makes a lot of decisions,
[00:35:13] a lot of progress, right? I think theoretically, they will also progress much, much better,
[00:35:17] right? Even though some decisions may not be, you know, optimal, or maybe it’s wrong completely,
[00:35:21] right? But I think as long as we have a way to kind of like reverse easily, that’s why all these
[00:35:26] best practices in engineering, you know, CICD, test coverage, and all that will actually give
[00:35:31] you some feedback, especially fast feedback loop so that you’re not going much, much into the wrong
[00:35:36] direction, right? So I think by the end of the day, you’re going to have a lot of progress. And I think
[00:35:38] for action, default to action is something that is really, really good, not just in terms of
[00:35:42] acing first team, probably, right? And this also goes back to, you know, many people are
[00:35:47] interrupted a lot, you know, having a lot of meetings. But I think for this to happen, right,
[00:35:52] a critical thing that must also happen is actually the leadership part. Because for this to work,
[00:35:58] especially there needs to be a lot of trust. It cannot work if leaders just simply don’t trust
[00:36:03] people working invisibly, because some people would prefer, you know, seeing people,
[00:36:08] doing the things with their eyes visibly. So a lot of trust and empowerment probably must be there.
[00:36:14] So tell us the critical role of the leaders. What kind of mindset should they have? And how could
[00:36:20] they inculcate this kind of culture within the team? We’ve all been on planes. One of the things
[00:36:25] that they say on the plane is before you help anyone else, wear your own mask first, right?
[00:36:32] And there is another saying, before you light a thousand lamps, light your own lamp first.
[00:36:38] So there are some fundamental skills that leaders need to start practicing. And one of the things is
[00:36:44] that we are in the throes of hustle culture, Henry, where performative productivity,
[00:36:50] how many meetings am I in? How many messages did I respond to? How many emails did I respond to?
[00:36:56] I did this, and I’m so busy, and I have so many back-to-back meetings. We wear this as a badge
[00:37:00] of honor, right? And we’ve got to step back from it. If we really want to run high-performing,
[00:37:06] inclusive teams, that is the thing that we need to do. And I think that’s the key. And I think that’s
[00:37:08] delivering outcomes without being stressed, then we need to take a step back and say,
[00:37:15] how do we model the behaviors that we’d like our team to follow? And so there are some fundamental
[00:37:22] skills that all leaders need to build. So are you building the skill of writing? Are you building
[00:37:29] the patience to read and comprehend? Are you able to work for long hours, like three or four hours,
[00:37:36] while blocking all distractions?
[00:37:38] Are you practicing a bias for action, where you can work independently? Now, that could happen
[00:37:44] between, let’s say you’re an engineering manager, and you have a peer group of engineering managers.
[00:37:48] So in that peer group, are you able to work independently? Are you asking all engineering
[00:37:52] managers to come together for every single decision, right? I mean, that’s a red flag right
[00:37:56] there. And then you start reflecting on little things, right? Which is, how am I creating systems,
[00:38:05] for example, for my team, where I can take…
[00:38:08] For example, this thing of having to give everyone a status update. Think about it. I started doing
[00:38:15] status updates in stand-up meetings way back in 2006 and 2007. Because at that time, there were no
[00:38:23] electronic task boards. There were no tools of that nature. And even if they were, they were
[00:38:30] very clunky, and then everyone didn’t have access. And also, everyone used to stay in the same room.
[00:38:36] So then what would happen?
[00:38:38] All of your cards that would represent the piece of work were on the wall.
[00:38:43] And you didn’t have any detail because you couldn’t go and write a big update on the card
[00:38:48] because it was just a card. So then you would have to stand in front of the wall and give a
[00:38:51] status update. It used to be a reasonable thing to do those many years back, right? I’m talking
[00:38:57] about 20 years back almost. But today, for you to know the status of your project, it should be
[00:39:03] real-time. Anytime you want to know the status of your project, you should know it. And so,
[00:39:08] your job as the leader should be to put in systems so that you always have real-time status.
[00:39:16] How do you do that? Probably you integrate GitHub with Confluence and with Jira so that every time
[00:39:24] there is a commit, the card updates with the commit status. And you know exactly what’s happening on
[00:39:29] the card, right? That’s an easy way of being able to refresh and taking away the unnecessary work of
[00:39:36] doing a status update. So that’s an easy way of being able to refresh and taking away the unnecessary work of doing a status update.
[00:39:38] So then you start thinking about systems. So the first thing really is for the leaders to make
[00:39:43] that change in themselves, be effective knowledge workers, and then think about systems that you
[00:39:49] will put in place to make your team’s job easier. And isn’t that the fundamental thing about
[00:39:53] leadership, that you make your team’s job easier? Yeah, I like that you emphasize about the
[00:39:58] importance of systems, right? It’s not about execution, speed, one-to-one decision-making,
[00:40:03] right? It’s about systems and processes where everyone kind of like aligns. You build a system
[00:40:08] that people follow it, and you can kind of like solve the kind of problems that you are trying to
[00:40:13] solve, right? And I think these days, people also mentioning that stand-up, you know, agile stand-up,
[00:40:18] daily stand-up, kind of like a waste of time where people are just gathering, you know, it’s one of
[00:40:22] the meetings that we have, right? Where everybody is inside and giving mostly status updates. It’s
[00:40:27] not like true to the agile principle, like you just discuss, you know, like the blockers and things
[00:40:32] like that. So I think definitely speaks a lot to so many people out there who are still practicing this.
[00:40:38] And I think you mentioned a lot about writing, right? Written communication. When we talk about
[00:40:43] not many people are fluent in speaking English, I would say also, even though we all know how to
[00:40:47] write, not many are good writer, you know, in terms of effectiveness, the density of information.
[00:40:52] So tell us, how can we be a better writer, you know, so that communication not becoming one of
[00:40:58] the bottleneck of effectiveness, but it can also become one thing that everyone can aspire to be?
[00:41:04] Yeah, so look, we need to separate a few things.
[00:41:08] Nobody’s asking us to be a great novelist. We are only trying to be good business writers,
[00:41:15] right? And when you want to write for business communication, then you need to think about
[00:41:21] writing like a journalist, which is trying to give information in the least number of words possible.
[00:41:29] Most of us have read a newspaper sometime in our life, right? And journalists follow this
[00:41:35] inverted pyramid of giving information.
[00:41:38] Where the most newsworthy information is in the first paragraph itself. Then the next few
[00:41:46] paragraphs have important details. And then anything that is just optional background,
[00:41:53] interesting information comes right at the end, right? That’s an interesting technique that anyone
[00:41:58] can adopt. One thing to consider is today you have more tools than ever to improve your writing.
[00:42:06] So for example, if you had Microsoft Word,
[00:42:08] as a writing tool, which a lot of people have, Microsoft Word has some of the best
[00:42:14] spelling and grammar corrections. So if you go to the spelling and grammar section of Microsoft Word,
[00:42:18] you can configure it to your own cultural setting so that it goes and gives you corrections for
[00:42:24] every piece of text that you’ve written. Then think about standard things that we can do to
[00:42:29] make it easy for people to read. Because see, this is where you need to also operate with empathy.
[00:42:34] If you write 200 words in one paragraph,
[00:42:37] it becomes difficult to read. But if you write four paragraphs of 50 words each,
[00:42:43] the same text becomes a little easier to read. If you then split the paragraphs out of those
[00:42:49] four paragraphs, let’s say you split two paragraphs into bullet points, it becomes
[00:42:54] even more easy to read. If you structure something into a table, it becomes even easier to read.
[00:43:00] If you then add headings and subheadings, it becomes easier to scan. So little things that
[00:43:07] you can do to make your reading easy to scan, easy to consume, you will only learn by practicing it
[00:43:15] little by little by little. But the good thing is our examination systems and our university systems
[00:43:22] that we went through taught us all of this, right? How do you write a good answer? You try to make it
[00:43:27] concise. You write it in bullets. We know all of these skills. We probably lost it like 10 years
[00:43:32] back or 15 years back or 20 years back whenever we left university. But we practice it in our
[00:43:37] 16 years or 17 years, some people even 20 years of their lives. So the muscle is there. It just
[00:43:43] needs to get exercised. Yeah, so I think it’s really critical to improve the writing skill,
[00:43:48] right? Because there’s so many variants of how people write. So some who love a prose, you know,
[00:43:53] start with a small thing, builds up, and then the important thing at the end. But I think like what
[00:43:58] you mentioned, your journalist thing or the TLDR version, or some people also call it pyramid
[00:44:02] principle, you know, a barminto, right? Put the most important things, especially if they’re
[00:44:07] there’s an action that you would like people to take at the first thing. And I think I also read a
[00:44:11] book some time ago that there is this thing, how to write in much more effective manner, just like
[00:44:17] what you mentioned, right? Convert paragraphs, maybe into bullet points, shorter sentences
[00:44:21] rather than long sentences, right? Don’t try to cram too many details in one sentence, putting
[00:44:26] tables, subheadings and all that, colors, emojis and all that. Sometimes it could also work so that
[00:44:31] the people can actually scan through the content much, much easier. One of the things often helps
[00:44:37] people heads up of how much time is it going to take you to consume this writing? So one thing
[00:44:42] which I always do with the documents I write is I have a heading which says this will take you seven
[00:44:47] minutes to read. And how do you calculate? A rough way to calculate is take the number of words in
[00:44:53] your document and divide it by 240. Most people can read 240 words a minute, and then just round it
[00:45:01] upwards. So let’s say it’s seven minutes, then people are okay to know what they’re doing. And then
[00:45:07] okay, it’ll take me seven minutes, let me block off 15 minutes, and just focus and read, people
[00:45:12] will do it. And then you can also ask yourself, is this reasonable? Should it take me seven minutes
[00:45:17] to convey this concept? Can I pare it down? Can I sharpen it? Can I shorten it? And then you will
[00:45:23] also give yourself a little bit of a feedback loop. And the good thing is these days, AI tools
[00:45:28] are so good that they can help you even structure your text. So let’s say you’ve written your first
[00:45:37] sentence, and you want to make sure that you’re using tables, headings, bullets, so that it’s easy
[00:45:42] to read, and you will actually get a pretty good output.
[00:45:44] Yeah, so I think I love the mentioning of AI here, because everyone thinks AI pros and cons, right?
[00:45:50] 50-50 something, it’s useful. But I think condensing, summarizing, changing the way you write is
[00:45:56] something that AI is really good at. I’ve used it so many times as well. And I think maybe even
[00:46:01] calculating this time to read your content could be something that AI can help as well. So I think I
[00:46:06] haven’t done this.
[00:46:07] I don’t have time that people is expected to read my content. But this is something maybe
[00:46:11] everyone can try, right? So that people know upfront how much time they should allocate to
[00:46:16] read your content. So one thing also, when we have so many things written, right, many people write
[00:46:22] stuff, it’s also the time for people to actually read, analyze, and, you know, comprehend, right?
[00:46:28] And with so many writings out there, how do you prioritize the reading? So maybe some tips from
[00:46:33] you, how can people also prioritize the reading part?
[00:46:36] Yeah, I think that’s a really good question. I think that’s a really good question.
[00:46:37] Yeah, I think that’s a really good question.
[00:46:37] So one thing is, obviously, when you’re working in a team, and you have lots of decisions,
[00:46:42] lots of things happening, there will be a lot of documents, right? And firstly, let’s say you’re
[00:46:49] creating the document, then it somehow becomes your responsibility to give people enough time.
[00:46:54] And this is where the idea of reasonable lag comes in. Because if it’s a matter of making
[00:47:00] a decision in one day, then probably async is not the way to go. Probably you need async
[00:47:06] light, which is that you write the document, but you get on a call and set up the first 15 minutes
[00:47:12] of that call for everyone to read. But if it’s not an urgent decision, you need to give people
[00:47:18] time so that people can consume that information. And then it becomes a responsibility of everyone
[00:47:25] in the team to block their calendar, to be able to consume what they were expected to consume.
[00:47:31] Now, again, this is a change that takes time in the teams. And I’ve gone through this with three
[00:47:36] or four teams. And I’ve gone through this with three or four teams. And I’ve gone through this
[00:47:36] at least, where we agree as a team that, okay, okay, we will go async first, we will write and
[00:47:43] then we will consume. And then you have the meeting where you’re actually supposed to make the decision
[00:47:47] and nobody’s done the reading. This is where you start using forcing functions. And one forcing
[00:47:53] function is to set aside the first 15 minutes, as I said, as a silent meeting, where if you are
[00:48:01] seeing this pattern that people are not reading, then you say, okay, first 15 minutes is always for
[00:48:05] reading. And soon, what happens is that you’re not reading. And you’re not reading. And you’re not
[00:48:06] reading. And you’re not reading. And you’re not reading. And you’re not reading. And you do one
[00:48:08] meeting where 15 minutes is for reading, you do another meeting with 15 minutes is for reading,
[00:48:12] you do 10 meetings like this. And after that, people are like, you know what, it’s probably
[00:48:16] better that I do the reading in my own time. And that’s how you force the behavior. So sometimes
[00:48:22] it’ll happen by itself, where people will make the time sometimes you will need to implement
[00:48:27] a forcing function. Yeah, so I’ve been in teams where we do this silent meeting. So I must say,
[00:48:33] back then, when I was a leader with many things, many meetings, many,
[00:48:36] people, many things to attend to, right, the silent meeting in the first few minutes actually
[00:48:41] is really, really helpful. But obviously, right, I must say that if you just read at that particular
[00:48:46] time, right, the kind of thought process that you went through also not optimal, right, you can’t
[00:48:51] give much critical feedback, because maybe you’re rushing, maybe you still kind of like haven’t
[00:48:55] fully switched from what you did previously, right. So I think still the best time to read is actually
[00:49:01] before the meeting. And maybe you give some feedback, comment, critical feedback, right,
[00:49:04] rather than waiting at that particular time, right. So I think silent meeting, if everyone
[00:49:08] haven’t done that, something that you can try so that people are aligned, rather than you force a
[00:49:14] meeting, some people didn’t read it and didn’t participate, and they don’t give feedback, right.
[00:49:18] So I think this comes back to the early thing that you mentioned, the decision hygiene, right?
[00:49:22] How many people actually participate in the discussion and the decision, and then how good
[00:49:26] the quality of the decision, right? One piece of advice for people who are going to be reading,
[00:49:31] right? Actually, two pieces of advice. One piece of advice is that,
[00:49:34] whatever you feel is the reading duration, block 4x of that, because it’ll take you some time to
[00:49:42] absorb the content, it’ll also take you some time to critique, to drop comments and things like that.
[00:49:46] So drop 4x the time. The other is to progressively build your reading muscle, because a lot of good
[00:49:53] input comes from reading sources. As technologists, reading is going to be one of those things that we
[00:50:00] do all the time, right? And it helps us learn quite a bit.
[00:50:03] And so even if you set yourself, let’s say, 10 minutes every morning and 10 minutes at night
[00:50:10] to just practice reading, and it could be reading a book, it could be reading articles,
[00:50:15] it could be reading anything, but just give yourself that 10 minutes of practice every
[00:50:19] morning and every evening, outside work. It doesn’t have to be inside work. You will realize
[00:50:24] that your reading muscle will get stronger. Yeah, so I think definitely improving reading
[00:50:29] is something that we all can do. Of course, we think that we have mastered reading,
[00:50:33] because we have gone to school and we read books for, I don’t know, at least 12 years,
[00:50:38] some 16 years, 18 years, whatever that is, right? And we think we are good at reading,
[00:50:43] but actually think back again. Your reading must, I think, is not as good as what you think,
[00:50:47] right? Especially if you classify yourself with people who can speed read, they can read in very,
[00:50:53] very fast manner, right? So I think there are some techniques that I learned as well that you
[00:50:56] can improve your reading. Don’t assume that you are a good reader, and especially trying to
[00:51:01] comprehend at the same time, right? Because sometimes, you know, you’re not good at reading,
[00:51:03] reading in a fast-speed manner doesn’t mean that you comprehend what you read, right? So I think
[00:51:08] it’s very important for people to also continue upskilling your reading skill.
[00:51:14] So I want to move on to the last part of your book, where you mentioned there’s a future where
[00:51:18] maybe this async first can still be the working mode that people assume, right? And I like the
[00:51:24] analogy that you mentioned. This is just like another sport, right? If people are so used to,
[00:51:28] you know, like working in office as one kind of a sport, working in a remote manner, async first,
[00:51:33] it’s kind of like another sport that, you know, needs a different skill, maybe a different
[00:51:37] culture and all that. And tell us what kind of possibilities that you think could happen
[00:51:41] in the future of work, and what can people actually think in terms of adopting async first?
[00:51:48] I am seeing a few trends. It’s very hard to predict the future, but one of the trends that
[00:51:53] all of us are seeing is AI, right? And we have to accept that for many of us now, AI is a co-worker.
[00:52:03] It’s a great thing, because if you think about it, it’s a superpower that you have a co-worker who
[00:52:10] does not need deep work, who does not need job satisfaction, who does not need a holiday,
[00:52:16] who does not get tired. Next time you want to tap somebody on the shoulder,
[00:52:21] you can start tapping AI on the shoulder, and you can still get bias for action decision velocity.
[00:52:27] So that’s going to be a big trend going forward, that we are going to have these AI co-workers,
[00:52:33] and I have a feeling that that will make the prevalence of async all the more common in our
[00:52:41] workplaces. But a couple of other things are also likely to happen, Henry, because tech as an
[00:52:47] industry always wants to grow. And even if there are layoffs, eventually, there’s going to be a
[00:52:53] scarcity of talent. And if you look back at the history of our industry, I started working about
[00:52:59] 20-odd years back. When I started working,
[00:53:03] developers wouldn’t get laptops. Only the managers used to get laptops. And then at some point,
[00:53:09] developers said, why do the managers only get laptops? We should get laptops too.
[00:53:13] And first, the managers said no. And then the top developers said, okay, if I don’t get a laptop,
[00:53:19] I’m leaving the company. And then all developers got laptops, right? Now it’s common for all
[00:53:24] developers to have laptops. It was the same thing. I don’t know if you remember the time when
[00:53:28] managers used to have BlackBerrys, and they were the only people who had emails.
[00:53:33] And then workers said, well, we’d like to have email on our phone as well. We’d like to have
[00:53:38] smartphones as well. And companies said no. And then the top developers, the top technologists
[00:53:45] said, well, in that case, we’re leaving the company. And they said, oh, don’t leave, don’t
[00:53:48] leave. You can have email on your phone. You can have smartphones. I mean, was that a good thing?
[00:53:51] I could argue no. But that’s what top talent wanted. And that’s what top talent got.
[00:53:57] I don’t think it’s a stretch of imagination to say that top talent wants to work remotely,
[00:54:03] top talent wants location autonomy. And if that is indeed the case, usually whatever top talent
[00:54:11] gets, everyone eventually gets. You may not get it in the next four years, five years, you may get
[00:54:16] it in 10 years. But in 10 years time, it’s very likely that our workforce is going to be extremely
[00:54:21] remote. And companies that are remote first, and as a consequence, async first, are going to be
[00:54:28] more competitive because they have access to talent.
[00:54:31] So that’s where I see the trend that companies that embrace location independence will probably
[00:54:40] have more access to talent. They will realize that location independence without time independence,
[00:54:47] which is being able to work asynchronously, is pointless. So they will embrace asynchronous work.
[00:54:53] And because we have this growing trend of AI as a co-worker, working asynchronously will become
[00:55:00] significantly easier. And that’s why I see the trend that companies that embrace location independence
[00:55:01] will become significantly easier than it used to be in the past.
[00:55:03] Yeah, so I love the rationale that you put, right? So whenever the top talents kind of like demand in
[00:55:10] the market, right? Maybe some change could also be driven by that, right? So I think today, we see
[00:55:16] many companies are moving back to the office. But one thing for sure, everyone has experienced this
[00:55:22] remote work. And everyone, I think, aspire deep down, they want to continue that remote working
[00:55:27] style, right? Or at least asynchronous first, and where you have autonomy,
[00:55:31] they want to maybe also move to the location that is not common in the cities, right? So maybe
[00:55:36] closer to the parents, the family, maybe they just want to live in a simple lifestyle, whatever that
[00:55:42] is, right? So I think many, many people would deep down love this kind of working style. And if you
[00:55:47] are top talent, and you demand this, probably one day in the future, we can see more remote work,
[00:55:52] more async first. And another thing that I also see that because of this AI introduction,
[00:55:57] teams tend to get smaller and smaller. People now can do a lot of work, but they can’t do a lot of
[00:56:01] more things with just a small team, right? And many people aspire to create small, medium
[00:56:06] enterprise or small, like gig worker, so to speak, right? Be like consulting, fractional work and
[00:56:11] things like that. Is this also some trends that you see would also drive async first and remote
[00:56:16] work to become more popular? Yeah, for fractional work, I think there is no point trying to get
[00:56:24] your fractional CTO or a fractional CMO into the office all the time, because your fractional CTO
[00:56:30] probably works in four other companies. So for them, I think they become fractional by virtue of
[00:56:37] the fact that they are top talent, right? And they will always demand a certain level of autonomy.
[00:56:43] And in fact, this is what I was wanting to say when you said big companies are calling people
[00:56:47] back. But here’s the thing with big companies. All big companies also have top talent. And guess
[00:56:53] what? They are making exceptions for their top talent. Are you really telling me that their top
[00:56:58] talent is coming to the office without?
[00:57:00] Any objections whatsoever? Who implements a return to office? Usually, it is the managers.
[00:57:07] And the managers usually will have, I mean, I know a lot of people in big tech. And generally,
[00:57:16] it’s a conversation with your manager. Because yes, there will be some data that comes out saying
[00:57:20] you didn’t come to the office for these many days. And then your manager has a word with you. And
[00:57:25] then if you’re the best engineer out there, you say, well, if that’s the case, I’m going to leave.
[00:57:30] And your manager says, no, don’t leave. Maybe come into the office one day a week, not three days
[00:57:35] a week. And that’s the setup that I see in a lot of places where the top engineers are either not
[00:57:41] coming into the office or coming into the office less than required. And they’re in this hushed
[00:57:45] hybrid situation. So top engineers, top talent will always get what they want. It just so happens
[00:57:52] to be the case. It has always been the case. And eventually, whatever top talent gets, everyone gets.
[00:57:57] Right. Very interesting arguments indeed, right?
[00:58:00] So I think another thing that I foresee, right, people will still kind of like try to look for
[00:58:05] remote jobs. Especially now, there are many websites that promote remote jobs, remote work.
[00:58:11] Probably if there’s an interesting opportunity, top talents will still love that. Because I find
[00:58:15] that sometimes, you know, during this pandemic, right, people can spend much more time doing
[00:58:20] something more meaningful rather than spending the time doing commute, right? Because commute
[00:58:25] itself, you know, wastes a lot of hours in your day, right? So I think something that everyone
[00:58:29] here can aspire to. Right. So I think another thing that I foresee, right, people will still kind of
[00:58:30] aspire to see in the coming future. So Sumit, it’s been a fascinating conversation. You know,
[00:58:36] I really love reading your book and also this conversation, obviously, right? Unfortunately,
[00:58:40] we reached the end of our conversation. But before I let you go, I have one last question that I must
[00:58:45] ask to all my guests, which I call the three technical leadership wisdom. If you think just
[00:58:50] like an advice you want to give to us as the listeners here, what would they be?
[00:58:54] I’ll cheat a little. I’ll put out stuff from the Async First manifesto. So I would say,
[00:59:00] think about it as manifesto items, right? So think about focus and cognitive flow over always on
[00:59:09] productivity, availability, right? So for example, is it really about the work you deliver? Or is it
[00:59:15] about how many places people see you visible in? It obviously isn’t the latter. It’s about the work
[00:59:21] you deliver. So that should be more important. The second is, we’ve talked about this a couple
[00:59:25] of times in this podcast episode, which is AI is going to be a superpower. It’s going to be a
[00:59:30] superpower. Embrace it. Embrace it as your coworker. Embrace it as your coach. That’ll be
[00:59:36] a big thing in helping you work asynchronously and to actually elevate your standing as a
[00:59:41] technologist. And then finally, if you are a leader, then don’t bank on lucky things happening.
[00:59:51] I’ll give you an example. Oh, we will all come into the office and then we will all have coffee
[00:59:55] and then therefore we will all share knowledge. I think you’re just
[01:00:00] luck that way, right? Don’t do that. You need to have intentional actions, not serendipitous
[01:00:06] success. So what does that mean? You create the systems for that success to happen as part of
[01:00:14] your daily life, right? So if you want good decisions, set up a process to make good decisions.
[01:00:19] If you want good knowledge sharing, then set up a system for good knowledge sharing. If you want
[01:00:24] good code quality, set up a system for good code quality. Don’t wait for an
[01:00:30] accident to happen. Oh, because we sat at the same table, we had good code quality. I think that’s
[01:00:35] rubbish. So those are my pieces of advice. Focus AI as a coworker and a coach and then intentional
[01:00:42] actions. I was laughing when you mentioned about this serendipitous thing because it is one big
[01:00:47] reason whenever leaders say you must go back to the office because we want to allow more
[01:00:52] serendipitous moment where you bump into someone in either the pantry or during coffee, lunch,
[01:00:58] whatever that is, and it sparks an idea.
[01:01:00] That creates a big innovation and things like that. Obviously, sometimes it could happen,
[01:01:05] but I would argue that it is very rare that actually you will have this kind of serendipitous
[01:01:10] moment and creating systems to allow… I was saying it’s funny because you are saying
[01:01:16] that knowledge sharing is really important and you want to leave it to the chance that two people
[01:01:22] are thirsty at the same time. Yeah. So I think creating systems is much more important, right?
[01:01:29] Maybe you create community of practice.
[01:01:30] Channels, wiki blogs, whatever that is, right? So that this serendipitous moment can also happen
[01:01:36] without leaving it to chance of people bumping into each other. So Sumit, if people love this
[01:01:40] conversation, they would want to connect with you, ask you more questions, maybe about best practices.
[01:01:45] Is there a place where they can find you online? Yeah, I write every week on asyncagile.org.
[01:01:52] You can follow my writing there. I’m also on LinkedIn, Sumit Moge. You can find me with my
[01:01:57] first name and last name. Yeah, those are the two channels that I’m making videos on. I’m also on
[01:02:00] LinkedIn. And you can always get in touch with me either using the contact form on my website or
[01:02:05] through a direct message on LinkedIn. Right. So if people would love to learn more about asynchronous
[01:02:10] work, remote work, I highly suggest Sumit’s book, right? It has a lot of important things that you
[01:02:16] can learn. Thank you for writing that. And thank you for this conversation, Sumit.
[01:02:19] The pleasure is all mine, my friend. Thank you so much for inviting me.
[01:02:30] Thank you.
[01:03:00] Thank you.