#215 - The Async First Playbook: Build Effective and Inclusive Teams with Less Meetings - Sumeet Moghe

[00:01:30] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to the Tech Lead Journal podcast show. Today I have with me, Sumeet Moghe. He’s the principal product manager at ThoughtWorks. He’s the author of the book Async-First Playbook. I think we have gone through pandemic and you know, now everybody is starting to go back to office. But nevertheless, I think would still love to have this conversation and learn from Sumeet how can we actually do asynchronous working mode much better. And whether this trend is still going to continue, or it’s gonna kind of like die down. So welcome Sumeet to the show.

Sumeet Moghe: Hey, thanks. Thanks for inviting me.

[00:02:19] Career Turning Points

Henry Suryawirawan: Right. Sumeet, I always love in the beginning to invite my guests to actually share any kind of turning points that you think we can learn from you.

Sumeet Moghe: Yeah, I think the biggest turning point in my career was to join ThoughtWorks. And the reason why ThoughtWorks was a career turning point is for a couple of reasons. It introduced me to the world of Agile. It introduced me to a very different style of leadership where leaders were not necessarily meant to be the bosses of people, but to be the people who remove blockers. Even to this day, we appreciate leaders being in the details and not being overlords who sit above the details, right? And so that completely changed my mindset about what it takes to be a leader and what it takes to run effective teams.

And then somewhere in the middle of my consulting journey, I happened to be on a team where most of my colleagues were in another continent. And this happened well before the pandemic. And that’s where a lot of my traditional Agile tools of collaboration failed me. Because Agile, at least the way it’s written in the XP book is sit together, right? And so there is no sitting together when all of your colleagues are in other countries. And it’s not even as if your colleagues are sitting together. And I had to figure out how am I going to run a high performing team between people sitting in Belarus, Ukraine, Belgium, Germany, and the US. And that became a turning point, particularly because while making my own mistakes, while learning how to make that team productive and be productive in that team myself, I picked up many of the concepts and the techniques that I wrote about in the book. So I’d say those were two big turning points in my career.

Henry Suryawirawan: Well, very interesting that you actually learn, you know, doing all this remote asynchronous working style before even the pandemic, right? And I’m sure back then during the pandemic, you kind of like probably one of the champion of doing this remote work. So maybe let’s start to this discussion, right?

[00:06:21] The Return to Office Trend

Henry Suryawirawan: So I think we can see the current trends. Almost every company is going back to the office, or maybe they adopt some flavor of, you know, I don’t know, flexible or hybrid working style. Even the big techs are forcing people to go back to the office full time. What is your take to all this current trend?

Sumeet Moghe: Yeah, so there are a couple of takes I have. One is that it’s a good thing. While I happen to be a big remote work advocate, I know that every company is not going to do remote work. And every company is not going to do 100% remote work. And there are lots of reasons for it. I can elaborate on it a little bit.

I used to work for one of the WITCH companies in India. These are all the consulting firms. So there’s Wipro, Infosys, TCS, Cognizant, HCL. These employ hundreds and thousands of people, they have big campuses. Now, one of the campuses I used to work on was a 300 acre campus. There is no incentive for that company to leave their 300 acre campus empty so that people can work remotely. They’ve incurred the CAPEX on it. In a similar way, is there any incentive for Google to leave Googleplex empty or for Amazon to leave Cupertino empty? There isn’t, right? They’ve spent millions of dollars in setting up those complexes.

And let’s say Amazon or Google or Apple set up a rule for their headquarters, because they love their headquarters, can they then say that people in satellite offices don’t come to the office? It’s very hard, right? So there are lots of these constraints because of which certain companies just cannot be 100 percent remote. We have to accept it.

Other part of it is that certain companies also benefit from showing that people are in the office. Now I work in the IT outsourcing industry. Now imagine you want to win over a client. If you want to win over a client, you make them come to your country, you make them come to the office and then, if the visual is an empty office, it’s not a very impressive visual. But if your visual is a campus full of people, then you can show your strength. So certain business models are not conducive to remote. So you have to understand that this isn’t because remote is bad. It’s just because certain companies are not set up for remote.

But one of the things we need to be aware of is that there is a narrative that gets fueled by the big companies. And there are more small companies in this industry than there are big companies. So even if you think of my country, India, you look at the big tech, which is Tesla, Alphabet, Meta, Microsoft, Amazon, Netflix, Apple, all of those, the WITCH companies which I mentioned, they are just 28% of the companies that exist. In fact, even the workforce, when I say 28%, they employ 28% of the workforce. The remaining 72% work in smaller companies. And the smaller companies don’t have CAPEX incurred for which they need to keep pulling people into the office. Every bit of operational expense that they can save works for them.

So it’s a cynical business decision for them to decide do we call people into the office or do we let them work remotely? And right now is a hard time for tech. So a lot of the smaller companies are still choosing to be remote. So where I’m getting at, when I say this is a good thing with people calling, companies calling employees back in the office is that for the smaller companies where winning talent was a very difficult task in 2022, when big money was getting thrown out, now, remote work can be a differentiator. You can now start saying, hey, we will pay you a little less than let’s say, Amazon, but you can work remotely. No problem. And some people will take that offer. So that’s one part of it.

But the other part of it is that let’s say you work for an Amazon, or let’s say you work for a Microsoft. I mean, Microsoft is actually very permissive with their remote work. But let’s say you work for an Amazon. Will you have collaborators in another office? You absolutely will. Will you have collaborators who potentially are working from home on any particular day? You’re most likely to. Which means that somebody is remote in relation to you on any given day. And so many of the skills that we learned during the pandemic about being effective at remote work become even more necessary if you want to run a high performing inclusive team post pandemic. So those are my two takes on the return to office phenomenon.

Henry Suryawirawan: Yeah, so I think the narrative these days is always about the headline news, right? Like company X, Big Tech X is inviting people to go back to the office five days a week, right? 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, right? 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.

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, you will work with someone remote. Different time zone, different location, different countries. And you know, these skills will be still important, right? And async is not necessarily just work from home. I guess. It could be work from, you know, like what you mentioned, right, multicountries and all that.

[00:11:36] Companies Embracing Async-First

Henry Suryawirawan: 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?

Sumeet Moghe: So some of this is never an all-or-nothing switch, Henry. There are companies who embrace async first as their default way of working, but they happen to also be remote first companies. Examples of these companies will be GitLab. Really big company, really global, and they’re async first. Another good example of async first is Shopify, right? Really big company, fairly global and then also happens to be async first. Spotify is another company which is async first, right? And then amongst the slightly smaller companies, you will see Automattic.

Now these are companies that say async first and they are very, very explicit about it. 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. 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.

So I don’t see it as an all-or-nothing. You are all async first or all sync first. I see that it’s a gradual shift. And even in my book, I kind of represent it as a spectrum, right? That you choose the mode of collaboration based on the outcome that you’re trying to achieve.

Henry Suryawirawan: So I think very interesting that you mentioned that, right, because obviously there are many flavors of doing async and all that, right? So it’s a spectrum definitely, right?

[00:13:20] People’s Working Style Preference

Henry Suryawirawan: And I think one thing in particular that I find interesting in your book, you mentioned that you ran a survey with few thousand people, I guess, right? So asking them what preference would they have when they choose for work, right? I think this is really interesting, especially after pandemic, people have experienced remote. 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. So tell us about this trend and what do you actually find insights from your survey.

Sumeet Moghe: The biggest insight that you want to take away is most people want to work remotely most of the days. The numbers are not important, right? And I think this is true. 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. There will be exceptions. 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. Then if you start looking at working parents. Especially women who 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? So they also prefer remote work.

So these are very, very intuitive observations. I think we know about this now very well. And that’s what the survey threw up. 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 every week. That’s about two and a half days in meetings every week. Of course, there are some who are spending 40 hours, and then there are some who are spending eight hours, but 16 on average. And that’s a lot of hours and meetings, 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, but the interruption was always there. 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, hey, Henry, can you help me with this? And then what have I done at that point? You were probably in your flow trying to solve a problem. I disturbed your sense of flow, right? So I created that interruption for you. 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.

So those are the stunning findings that we spend way too much time in meetings and we get interrupted way too much. 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. And to solve complex problems, you need spells of deep work. Especially if, you know, you’re doing anything creative, you don’t work in 30 minute spells and one hour spells, you often work in two or 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, right? I’m sure you’ve achieved, you’ve had this feeling, right? Doing some creative work at the end of it.

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. Where is your flow and where is your productivity and where’s your deep work?

So I think that happened to be the biggest casualty that I was trying to address. 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.

Henry Suryawirawan: Yeah, so I think everyone here who listen can really relate to these problems, right? Too many meetings, too many interruptions. Interruptions doesn’t always mean, you know, physically. It could be digital as well, right? Your messages, you know, your emails, your notifications, whatever that is. And also regarding the commute, right? So people have to spend time, 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. I think that’s also a lot of time being wasted on the road.

[00:17:37] What is Async-First?

Henry Suryawirawan: So I want to ask you first, could you actually define what do you mean by async first, right? Because there’s so many different interpretation these days. You know, some people think it’s work from home, some think it’s remote work. Some think it could be like digital nomad, you know, you can work anywhere as long as you have internet. So what do you mean by async first? Maybe let’s start from there and then we can dive deep into it further.

Sumeet Moghe: Yeah. One provocative sentence, Henry, and that provocative sentence is that meetings are the last resort and they are not the first option. 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, and it doesn’t have to be that way. We need to be a little more thoughtful about how we collaborate. This is not to say meetings are bad. This is not to say we should ban meetings, but we are saying that it should be the last resort. 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. And so writing becomes the primary mode of conveying information in a team.

And if writing has to become the primary mode of conveying information in a team, and by the way I’m ready for all objections to this, right? If writing becomes the primary mode of conveying information in a team, then obviously everyone needs time to process that writing. You need time to write and you need time to read. So you need to also be comfortable with reasonable lag. And what is that reasonable lag is something that you define inside a team. So for example, what is the reasonable lag to respond to a pull request? What is the reasonable lag to respond to an IM? Or let us say you’ve written a design document, what is the reasonable lag to get feedback on that design document? This is what you need to define inside a team. Okay, let’s assume that there is a big production issue that needs urgent attention. How do I get in touch with somebody? Because again, in that case, you would say I should be able to Slack message somebody if it’s urgent.

But if you step back for a minute and think about it, that then means that somebody should be looking at Slack all the time. They need to be command tabbing between their IDE and Slack saying, oh, did Henry message me? Oh, did Sumeet message me? Which means you’ve built interruption into their work, right? When you think about it that way and say zero lag, but we also don’t want interruptions, 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 somebody saying it’s urgent. Right?

So this is what I mean. Writing becomes the primary way of communicating and we all become comfortable with reasonable lag. And why writing? I’ll just add a little bit to it. It’s something that you can produce quite quickly. All of us have a minimum of 16 years of education if you’re working in tech. So everyone knows how to write. Plus, if you use any writing tool, it helps you correct your spelling. It helps you correct your grammar. It shortens things for you. You can add headings, you can cut and move things somewhere else. You can’t do that with video and audio that easily, right? So writing is a little easier to produce than anything else that people will consume. So that’s why writing.

Henry Suryawirawan: Yeah, so I think very intriguing. So the way you define async, right, the first principle is like meeting should be the last option, right? If you think you want to create a meeting, think of it as a last option. So it should not be the first option when you want to communicate with others. And the second thing is writing is the primary communication mode, right? So it could be, you know, messages, it could be docs, right? It could be whatever PR, pull requests and things like that, right? And then the last thing is that you should tolerate a reasonable lag. And I think this reasonable lag is something that you need to define as a team, right?

[00:21:39] Team Handbook and Ways of Working

Henry Suryawirawan: 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? And in your book, you mentioned about team handbook or maybe organization handbook. I know that GitLab also have remote handbook and things like that. Is this something that really, really important for async first team?

Sumeet Moghe: For any team, in fact, because every team has a way of working. If you don’t write it down, people are imagining it, anyway. So it’s always better to write it down so you don’t leave anything to imagination. And it’s okay, you won’t get it right on the first day. Start with a few sensible defaults, right? Start with whatever feels sensible, reasonable on the first day. So if you feel, for example, that we should be 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? You’ll get a feedback loop. But that doesn’t stop you from writing it up.

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. Don’t get obsessed with perfection. Be okay with good enough. And there are many sensible defaults. You can even come to my website and take a look. There’s lots and lots of these sensible defaults that you can just copy paste from other teams. GitLab has a lot of sensible defaults as well. So yeah, agreeing those ways of working is absolutely crucial.

Henry Suryawirawan: So, I like that you mentioned no matter what, whether you’re async first or maybe you work in the office, right? Please come up with a handbook, right? I think it’s very, very good guideline for, you know, defining ways of working. Because as the team grow larger, in fact, organization grows larger, right? You will need to define some kind of SLA or, you know, primary mode of communication, expectations with other teams. All these can be defined in the handbook, right?

[00:23:24] The ConveRel Quadrants

Henry Suryawirawan: So I know that you must have dealt with these kind of arguments before, right? Because if you mentioned meeting should not be the first option, we all have to write first, and you need to accept reasonable lag, many leaders, I would assume, especially those who are like action oriented, will find it very difficult to adapt to this kind of working style. They think it’s too slow, they think it’s less productive. They think that it’s very difficult to reach out to people. So, maybe if you can give us some comments on this kind of arguments.

Sumeet Moghe: Yeah. So look, you’ve got to ask yourself a couple of things about meetings, right? One is who is meeting? And what are you trying to meet for, right? I have a concept and I’ll ask your users to try and visualize, your audience to try and visualize this two by two matrix. Okay, so on the x axis, try to measure the strength of the relationship of the group of people who are meeting. So on the right hand side, you can have a strong relationship. And you can have on the left hand side, a weak relationship between the people who are meeting. And then think about the purpose that you’re trying to achieve with this group of people. You are either trying to convey information or you’re trying to converge on a decision.

So now let’s try to look at it case by case. Strong relationships and you’re only trying to convey information. In these situations, you don’t need a meeting. You can just write an email, write a document, and it’s fine. There is no chance of misunderstanding. People have a strong relationship or a very small chance of misunderstanding. Go ahead and just send the information. People can read. You don’t have to read to literate people.

Now, imagine that you have people who have a weak relationship who are trying to then converge on a decision. In such a case, very simple. There’s a lot of chance of misunderstanding. And you’re also trying to do something which is fundamentally more difficult. Converging on a decision is more difficult than just conveying information. So in such a case, no problem. Do a meeting. Much better. It helps your relationship and it also helps you get to the decision faster.

Now, let’s imagine somebody that you have a weak relationship with, who you’re trying to convey information to. Ideally, you should just be able to send the information to them in a document or an email or a message. But sometimes it helps to spend the time to build the relationship. So maybe do a few meetings to build the relationship, get them to the quadrant where the relationship is strong, and then start going async.

And then think about the last bit, which is you have people who have a strong relationship who are also trying to converge on a decision. Now, in this situation, you can take a blended approach where some part is asynchronous and some part is synchronous. So how do you do it? Let’s say, Henry, you and I are on a team with a few other people. Before a decision has to get made, everyone needs to have the same information, right? Let’s say we are trying to change one of the frameworks which we are using on the project. It’s a team decision. Before that, everyone needs to know what are our choices. So they need to study all of that. So how about you share all of that information asynchronously, give everyone the time to share feedback. And then when it comes to making the final high stakes decision, you get into a meeting.

Now, when people say, oh, no, no, I want speed, I want action. You need to ask them are you mistaking speed and productivity? Speed and productivity aren’t the same thing. You can do unproductive things really fast. What you need to be looking at is decision hygiene. The process that you follow, is that actually repeatable, stress free? And then you will get the right answers about what you should be doing.

Henry Suryawirawan: Yeah, so I think many people associate speed with execution and, you know, being productive, right? Well, that doesn’t necessarily mean that all the actions that you take in a fast manner, right, is something that is effective, right? So this is something, especially in the knowledge work where programming, you know, maybe creating materials, contents, documents, and all that, which needs a lot of thinking.

[00:27:41] Inclusion as a First-Class Responsibility

Henry Suryawirawan: And I think one thing also very, very important that I read from your book, you mentioned that because in a typical meeting, right, not everybody naturally will participate simply because some are introverts, some don’t have enough information when they join the meeting, or some just don’t know why they’re there. And I think this point of about inclusion, right, where people are given some time to actually process, digest, giving comments, feedback, and doing some kind of analysis. So tell us why this inclusion, very, very important and how async first actually helps to solve this.

Sumeet Moghe: Yeah, I call it the Captain America phenomenon. So, Henry, you in Singapore, people speak English everywhere almost, right? But even then, you and I speak English very differently. We have different accents. Now you start thinking about this as a global team. See, in my country, we have 20 odd official languages and 500 plus documented languages and many people don’t speak English as a first language. Now try imagining a situation where somebody comes from a small town, they’ve not spoken English as a first language growing up. They probably don’t have your and my experience in the industry. Now if it was you as the tech lead and me as the product manager and these inexperienced and also not fluent in English people out there. Add, let’s say, women into the mix. Add, let’s say, neurodiverse people into the mix. Guess who’s dominating the conversation? It’s the people who have experience. It’s the people who are fluent in English.

And if you want to run an inclusive team, you don’t want to just hold your ideas hostage to somebody’s fluency in a language. You don’t want to hold your ideas hostage to somebody’s experience, because I have found in a very humbling manner that a lot of ideas come from the most junior people in the team. Because they will think of things that experts don’t think of. And you’ve got to create the environment for them to feel safe to contribute where they can take the time to read what you’ve written and they can write something in safety. See, the thing is, even if I’m not fluent in English, I can put my statement into a word processor, ask it to correct the grammar and then post my question or comment. I don’t feel that bad as compared to if I have to speak on a Zoom call, because Zoom is not going to translate my English in real time.

So all of these are impacts. But then start to think about a few other situations. Let’s say you have a parent who is not able to attend your decision making call because they have a parenting responsibility. Would you like them not to be part of the decision making process just because they are a parent? You should be able to take their inputs, right? And this is where using an approach which takes people’s inputs asynchronously and blends asynchronous and synchronous communication gives you the best chance of running an inclusive team with a good cast of characters.

And let’s take a step back. Why is this important, right? I mean, lots of companies in the US are killing their DEI programs. And I think it’s a good point for us to reflect as an industry as to why is this important. It’s important because we come with our own sets of biases when we build software, when we build solutions. The more diverse our group, the more we are likely to cancel out each other’s biases. And for the simple reason that you want to build better solutions, you need to have a diverse team.

But even otherwise, you know, Singapore is a multicultural country city, India is multicultural. I think teams have a responsibility to reflect the way society is, right? So that’s another very important reason why teams should look like the society that they exist in. And so it’s very important that you look at inclusion as a first class responsibility for any leader to take care of. And if that is a first class responsibility, then async first becomes a great tool for you to employ.

Henry Suryawirawan: Yeah, so I think the point about language fluency, in fact, is very, very important, right? Because especially now that everyone is kind of like having a multinational teams, right? We kind of like assume that people can speak English, but actually the fact is not everyone is fluent in English. Some maybe because of being afraid of being embarrassed when speaking in English, broken English, to be precise, right? They tend not to speak out. But I think giving them chance to actually be included as part of the discussion, as part of team, giving their best critical input, I think it’s something that is very, very important, right?

[00:32:14] Defaulting to Action

Henry Suryawirawan: The other thing that you mentioned for async first team, right, there’s one thing that in particular kind of like alleviate this speed problem, right? There’s this thing called default to action, right? Some leaders think actually if you work asynchronously and you are blocked to something, people will just be idle, do something else, watch YouTube probably. But actually this is one critical distinction that you mentioned is that the default to action mode. So tell us a little bit more about this, why this is also important.

Sumeet Moghe: Yeah, and I think this has become a lot easier in the last 10, 15 years because of continuous delivery and all of the good DevOps practices that we have in place where almost everything we do in software is reversible. So the way to look at this is that there are reversible decisions you make and there are irreversible decisions you make. I think it’s fair to say that 99 percent of the decisions that you will make will be reversible. Because most people are making decisions at the level of design and code and within the space of one day, you’re not going to make a change in code, which hasn’t even gone to production, probably has just gone to UAT, which will tank the business.

So in these circumstances, let’s say you are working on a piece of code or you’re working on a piece of design, and you would love to get somebody’s input but you’re not able to get it. What do you do? You do the best you can, document the decision that you’ve made, and move on. You have a bias for action. You default to action. Now there are two possibilities. One is great, everything works fine, you made the right decision. That is the happy path. The sad path is that something went wrong. But if it’s a reversible decision, no problem, right? You should be able to backtrack. So if it’s code you’ve committed, you can roll it back. If it’s a design that you pushed forward, you should be able to take it back. So as long as you have the humility to learn, bias for action works well.

Now there is also a bit of team learning to happen here wherein you spend some time to say, there are certain categories of decisions that we will take with some ceremony, but there are other decisions that we will decentralize as much as possible. And there are ways of decentralizing your decisions as well, right? You can choose team structures that give you a little bit of decentralizing power. But the idea should be that most decisions can happen at the level of the individual and you don’t need to get 10 engineers to screw in a light bulb. Because Henry, you and I know this, any team that makes more decisions will make more mistakes, yes, but they will also make more progress. And if most of those mistakes are reversible, then it’s a good cost of progress.

Henry Suryawirawan: Yeah, so I think intuitively, right, when we listen to just now what you mentioned right. So the team which makes a lot of decisions, a lot of progress, right. I think theoretically they would also progress much, much better, right, even though some decisions may not be, you know, optimal or maybe it’s wrong completely, right. But I think as long as we have a way to kind of like reverse easily, that’s why all these best practices in engineering, you know, CI/CD, test coverage and all that will actually give you some feedback, especially fast feedback loop so that you’re not going much, much, uh, into the wrong direction, right?

So I think bias for action, default to action is something that is really, really good. Not just in terms of async first team probably, right? And this also goes back to, you know, many, people are interrupted a lot, you know, having a lot of meetings.

[00:35:50] Async-First Leadership

Henry Suryawirawan: But I think for this to happen, right, a critical thing that must also happen is actually the leadership part. Because for this to work, especially there needs to be a lot of trust. It cannot work if leaders just simply don’t trust people working invisibly. Because some people would prefer, you know, seeing people doing the things with their eyes visibly. So a lot of trust and empowerment probably must be there. So tell us the critical role of the leaders, what kind of mindset should they have and how could they inculcate this kind of culture within the team?

Sumeet Moghe: We’ve all been on planes. One of the things that they say on the plane is before you help anyone else, wear your own mask first, right? And there is another saying before you light a thousand lamps, light your own lamp first. So there are some fundamental skills that leaders need to start practicing. And one of the things is that we are in the throes of hustle culture, Henry, where performative productivity, how many meetings am I in? How many messages did I respond to? How many emails did I respond to? I did this and I’m so busy and I have so many back to back meetings. We wear this as a badge of honor, right?

And we’ve got to step back from it. If we really want to run high performing inclusive teams that are delivering outcomes without being stressed, then we need to take a step back and say, how do we model the behaviors that we’d like our team to follow? And so there are some fundamental skills that all leaders need to build. So are you building the skill of writing? Are you building the patience to read and comprehend? Are you able to work for long hours, like three or four hours while blocking all distractions? Are you practicing a bias for action where you can work independently?

Now that could happen between, let’s say you’re an engineering manager and you have a peer group of engineering managers. So in that peer group, are you able to work independently? Are you asking all engineering managers to come together for every single decision, right? I mean, that’s a red flag right there. And then you start reflecting on little things, right, which is how am I creating systems, for example for my team. Where I can take away, for example, this thing of having to give everyone a status update. Think about it. I started doing status updates in standup meetings way back in 2006 and 2007. Because at that time, there were no electronic task boards. There were no tools of that nature. And even if they were, they were very clunky and then everyone didn’t have access. And also everyone used to stay in the same room. So then what would happen is all of your cards that would represent the piece of work were on the wall. And you didn’t have any detail because you couldn’t go and write a big update on the card because it was just a card. So then you would have to stand in front of the wall and give a status update. It used to be a reasonable thing to do those many years back, right? I’m talking about 20 years back almost. But today, for you to know the status of your project, it should be real time. Anytime you want to know the status of your project, you should know it.

And so your job as the leader should be to put in systems so that you always have real time status. How do you do that? Probably you integrate GitHub with Confluence and with Jira, so that every time there is a commit, the card updates with the commit status, and you know exactly what’s happening on the card, right? That’s an easy way of being able to refresh and taking away the unnecessary work of doing a status update. So then you start thinking about systems. So the first thing really is for the leaders to make that change in themselves, be effective knowledge workers. And then think about systems that you will put in place to make your team’s job easier. And isn’t that the fundamental thing about leadership that you make your team’s job easier?

Henry Suryawirawan: Yeah, I like that you emphasize about the importance of systems, right? It’s not about execution speed, one to one decision making, right? It’s about systems and processes where everyone kind of like aligns. You build a system such that people follow it and you can kind of like solve the kind of problems that you are trying to solve, right? And I think these days people also mentioning that stand up, you know, Agile stand up, daily stand up, kind of like a waste of time where people are just gathering, you know, it’s one of the meetings that we have, right? Where everybody is inside and giving mostly status updates. It’s not like true to the Agile principle. Like you just discuss, you know, like the blockers and things like that. So I think definitely, it speaks a lot to so many people out there who are still practicing this.

[00:40:38] Being Good in Written Communication

Henry Suryawirawan: And I think you mentioned a lot about writing, right? Written communication. When we talk about not many people are fluent in speaking English, I would say also even though we all know how to write, not many are, good writer, you know, in terms of effectiveness, the density of information. So tell us how can we be a better writer, you know, so that communication not becoming one of the bottleneck of effectiveness, but it can also become one thing that everyone can aspire to be.

Sumeet Moghe: Yeah. So look, we need to separate a few things. Nobody’s asking us to be a great novelist. We are only trying to be good business writers, right? And when you want to write for business communication, then you need to think about writing like a journalist. Which is trying to give information in the least number of words possible. Most of us have read a newspaper sometime in our life, right? And journalists follow this inverted pyramid of giving information where the most newsworthy information is in the first paragraph itself. Then the next few paragraphs have important details. And then anything that is just optional, background, interesting information comes right at the end, right?

That’s an interesting technique that anyone can adopt. One thing to consider is today you have more tools than ever to improve your writing. So, for example, if you had Microsoft Word as a writing tool, which a lot of people have, Microsoft Word has some of the best spelling and grammar corrections. So if you go to the spelling and grammar section of Microsoft Word, you can configure it to your own cultural setting so that it goes and gives you corrections for every piece of text that you’ve written.

Then think about standard things that we can do to make it easy for people to read. Because see, this is where you need to also operate with empathy. If you write 200 words in one paragraph, it becomes difficult to read. But if you write four paragraphs of 50 words each, the same text becomes a little easier to read. If you then split the paragraphs, out of those four paragraphs, let’s say you split two paragraphs into bullet points, it becomes even more easy to read. If you structure something into a table, it becomes even easier to read. If you then add headings and subheadings, it becomes easier to scan.

So little things that you can do to make your reading easy to scan, easy to consume, you will only learn by practicing it little by little by little. But the good thing is, our examination systems and our university systems that we went through taught us all of this, right? How do you write a good answer? You try to make it concise. You write it in bullets. We know all of these skills. We probably lost it like 10 years back or 15 years back or 20 years back whenever we left university. But we practiced it for 16 years or 17 years. Some people even 20 years of their lives. So the muscle is there. It just needs to get exercised.

Henry Suryawirawan: Yeah. So I think it’s really critical to improve the writing skill, right? Because so many variants of how people write. So some who love a prose, you know, start with small thing, builds up and then the important thing at the end. But I think like what you mentioned, your journalist thing or the TL;DR version or some people also call it pyramid principle, you know, Barbara Minto, right? Put the most important things, especially if there’s an action that you would like people to take at the first thing. And I think I also read a book some time ago that there is this thing how to write in much more effective manner, just like what you mentioned, right? Convert paragraphs maybe into bullet points, shorter sentences rather than long sentences, right? Don’t try to cram too many details in one sentence, putting tables, subheadings, and all that, colors, emojis, and all that. Sometimes it could also work so that the people can actually scan through the content much, much easier.

[00:44:35] AI Usage in Written Communication

Sumeet Moghe: One of the things that often helps is to give people a heads up of how much time is it going to take you to consume this writing. So one thing which I always do with the documents I write is I have a heading which says this will take you seven minutes to read. And how do you calculate? A rough way to calculate is take the number of words in your document and divide it by 240. Most people can read 240 words a minute. And then just round it upwards. So let’s say it’s seven minutes. Then people are okay to know, okay, it’ll take me seven minutes. Let me block off 15 minutes and just focus and read. People will do it.

And then you can also ask yourself. Is this reasonable? Should it take me seven minutes to convey this concept? Can I pare it down? Can I sharpen it? Can I shorten it? And then you will also give yourself a little bit of a feedback loop. And the good thing is these days, AI tools are so good that they can help you even structure your text. So let’s say you’ve written your first draft. You can give it to an AI and say, can you please structure it using tables, headings, bullets, so that it’s easy to read and you will actually get a pretty good output.

Henry Suryawirawan: Yeah. So I think I love the mentioning of AI here because everyone thinks AI pros and cons, right? 50-50 something it’s useful. But I think condensing, summarizing, changing the way you write is something that AI is really good at. I’ve used it so many times as well. And I think maybe even calculating this time to read your content could be something that AI can help as well. So I think I haven’t done this, giving the amount of time that people is expected to read my content. But this is something maybe everyone can try, right? So that people know up front how, how much time they should allocate to read your content.

[00:46:17] Time to Read and Reading Comprehension

Henry Suryawirawan: So one thing also when we have so many things written, right? Many people write stuff. It’s also the time for people to actually read, analyze, and, you know, comprehend, right? And with so many writings out there, how do you prioritize the reading? So maybe some tips from you, how can people also prioritize the reading part?

Sumeet Moghe: So one thing is, obviously when you’re working in a team, and you have lots of decisions, lots of things happening, there will be a lot of documents, right? And firstly, let’s say you are creating the document, then it somehow becomes your responsibility to give people enough time. And this is where the idea of reasonable lag comes in. Because if it’s a matter of making a decision in one day, then probably async is not the way to go. Probably you need async light, which is that you write the document but you get on a call and set up the first 15 minutes of that call for everyone to read. But if it’s not an urgent decision, you need to give people time so that people can consume that information. And then it becomes a responsibility of everyone in the team to block their calendar, to be able to consume what they were expected to consume.

Now, again, this is a change that takes time in the teams. And I’ve gone through this with three or four teams at least, where we agree as a team that, okay, okay, we will go async first, we will write, and then we will consume. And then you have the meeting where you’re actually supposed to make the decision and nobody’s done the reading. This is where you start using forcing functions. And one forcing function is to set aside the first 15 minutes, as I said, as a silent meeting, where if you are seeing this pattern that people are not reading, then you say, okay, first 15 minutes is always for reading. And soon what happens, you do one meeting where 15 minutes is for reading, you do another meeting where 15 minutes is for reading, you do 10 meetings like this. And after that, people are like, you know what, it’s probably better that I do the reading in my own time. And that’s how you force the behavior. So sometimes it’ll happen by itself where people will make the time. Sometimes you will need to implement a forcing function.

Henry Suryawirawan: Yeah, so I’ve been in teams where we do this silent meeting. So I must say, back then when I was a leader with many things, many meetings, many people, many things to attend to, right? The silent meeting in the first few minutes actually is really, really helpful. But obviously, right, I must say that if you just read at that particular time, right, the kind of thought process that you went through also not optimal, right?

You can’t give much critical feedback because maybe you are rushing. Maybe you still kind of like haven’t fully switched from what you did previously, right? So I think still the best time to read is actually before the meeting and maybe you give some feedback, comment, critical feedback, right, rather than waiting at that particular time, right?

So I think silent meeting if everyone hasn’t done it, something that you can try so that people are aligned rather than you force a meeting, some people didn’t read it and didn’t participate and they don’t give feedback, right? So I think this comes back to the early thing that you mentioned, the decision hygiene, right? How many people actually participate in the discussion and the decision? And how good quality of the decision, right?

Sumeet Moghe: One piece of advice for people who are going to be reading, right? Actually two pieces of advice. One piece of advice is that whatever you feel is the reading duration, block 4x of that. Because it’ll take you some time to absorb the content. It’ll also take you some time to critique, to drop comments and things like that. So drop 4x the time.

The other is to progressively build your reading muscle. Because a lot of good input comes from reading sources. As technologists, reading is going to be one of those things that we do all the time, right? And it helps us learn quite a bit. And so even if you set yourself, let’s say, 10 minutes every morning and 10 minutes at night to just practice reading. And it could be reading a book. It could be reading articles. It could be reading anything, but just give yourself that 10 minutes of practice every morning and every evening outside work. It doesn’t have to be inside work. You will realize that your reading muscle will get stronger.

Henry Suryawirawan: Yeah, so I think definitely improving reading is something that we all can do. Of course, we think that we have mastered reading, right, because we have gone to school and, you know, we read books for I don’t know at least 12 years. Some 16 years, 18 years, whatever that is, right? And we think we are good at reading but actually think back again, your reading must, I think it’s not as good as what you think, right?

Especially if you classify yourself with people who can speed read, you know, they can read in very, very fast manner, right? So I think there are some techniques that I learned as well that you can improve your reading. Don’t assume that you are a good reader. And especially trying to comprehend at the same time, right? Because sometimes reading in a fast speed manner doesn’t mean that you comprehend what you read, right? So I think it’s very important for people to also continue upskilling your reading skill.

[00:51:14] The Future of Work

Henry Suryawirawan: So I want to move on to the last part of your book where you mentioned there’s a future where maybe this async first can still be the working mode that people assume, right? And I like the analogy that you mentioned. This is just like another sport, right? If people are so used to, you know, like working in office as one kind of a sport, working in a remote manner, async first is kind of like another sport that, you know, needs a different skill, maybe a different culture and all that. And tell us what kind of possibilities that you think could happen in the future of work. And what can people actually think in terms of adopting async first.

Sumeet Moghe: I am seeing a few trends. It’s very hard to predict the future. But one of the trends that all of us are seeing is AI, right? And we have to accept that for many of us now, AI is a coworker. It’s a great thing because if you think about it, it’s a superpower that you have a coworker who does not need deep work, who does not need job satisfaction, who does not need a holiday, who does not get tired. Next time you want to tap somebody on the shoulder, you can start tapping AI on the shoulder and you can still get bias for action, decision velocity. So that’s going to be a big trend going forward that we are going to have these AI coworkers. And I have a feeling that that could make the prevalence of async all the more common in our workplaces.

But a couple of other things are also likely to happen, Henry, because tech as an industry always wants to grow. And even if there are layoffs, eventually there’s going to be a scarcity of talent. And if you look back at the history of our industry, I started working about 20 odd years back. When I started working, developers wouldn’t get laptops. Only the managers used to get laptops. And then at some point, developers said, why do the managers only get laptops? We should get laptops too. And first the managers said no. And then the top developers said, okay, if I don’t get a laptop, I’m leaving the company. And then all developers got laptops, right? Now it’s common for all developers to have laptops.

It was the same thing. I don’t know if you remember the time when managers used to have Blackberries and they were the only people who had email. And then workers said, well, we’d like to have email on our phone as well. We’d like to have smartphones as well. And companies said, no. And then the top developers, the top technologists said, well, in that case, we are leaving the company. And they said, oh, don’t leave, don’t leave. You can have email on your phone. You can have smartphones. I mean, was that a good thing? I could argue no, but that’s what top talent wanted and that’s what top talent got.

I don’t think it’s a stretch of imagination to say that top talent wants to work remotely. Top talent wants location autonomy. And if that is indeed the case, usually whatever top talent gets, everyone eventually gets. You may not get it in the next four years, five years, you may get it in 10 years. But in 10 years time, it’s very likely that our workforce is going to be extremely remote. And companies that are remote first and as a consequence async first, are going to be more competitive because they have access to talent.

So that’s where I see the trend that companies that embrace location independence will probably have more access to talent. They will realize that location independence without time independence, which is being able to work asynchronously is pointless. So they will embrace asynchronous work. And because we have this growing trend of AI as a co-worker, working asynchronously will become significantly easier than it used to be in the past.

Henry Suryawirawan: Yeah, so I love the rationale that you put, right? So whenever the top talents kind of like demand in the market, right? Maybe some change could also be driven by that, right? So I think today we see many companies are moving back to the office. But one thing for sure, everyone has experienced this remote work and everyone, I think, aspire deep down, they want to continue that remote working style, right? Or at least asynchronous first and where you have autonomy. They want to maybe also move to the location that is not common in the cities, right? So maybe closer to the parents, their family. Maybe they just want to live in a simple lifestyle, whatever that is, right? So I think many, many people would deep down love this kind of working style. And if you’re a top talent and you demand this, probably one day in the future, we can see more remote work, more async first.

And another thing that I also see that because of this AI introduction, teams tend to get smaller and smaller. People now can do a lot more things with just a small team, right? And many people aspire to create small, medium enterprise or small like gig worker, so to speak, right? Be like consulting, fractional work and things like that. Is this also some trends that you see would also drive async first and remote work to become more popular?

Sumeet Moghe: Yeah, for fractional work, I think there is no point trying to get your fractional CTO or a fractional CMO into the office all the time. Because your fractional CTO probably works in four other companies. So for them, I think they become fractional by virtue of the fact that they are top talent, right? And they will always demand a certain level of autonomy. And in fact, this is what I was wanting to say when you said big companies are calling people back. But here’s the thing with big companies. All big companies also have top talent and guess what? They are making exceptions for that top talent. Are you really telling me that their top talent is coming to the office without any objections whatsoever?

Who implements a return to office? Usually it is the managers. And the managers usually will have… I mean, I know a lot of people in big tech and generally it’s a conversation with your manager. Because yes, there will be some data that comes out saying you didn’t come to the office for these many days. And then your manager has a word with you. And then if you’re the best engineer out there, you say, well, if that’s the case, I’m going to leave and your manager says, no, don’t leave, maybe come into the office one day a week, not three days a week. And that’s the setup that I see in a lot of places where the top engineers are either not coming into the office or coming into the office less than required. And they’re in this hushed hybrid situation. So top engineers, top talent will always get what they want. It just so happens to be the case. It has always been the case. And eventually, whatever top talent gets, everyone gets.

Henry Suryawirawan: Right. Very, uh, interesting arguments indeed, right. So I think another thing that I foresee, right? People would still kind of like try to look for remote jobs, especially now there are many websites that promote remote jobs, remote work. Probably if there’s an interesting opportunity, top talents would still love that, because I find that sometimes, you know, during this pandemic, right, people can spend much more time doing something more meaningful rather than spending the time doing commute, right? Because commute itself, you know, waste a lot of hours in your day, right? So I think something that everyone here can aspire to see in the coming future.

[00:58:33] 3 Tech Lead Wisdom

Henry Suryawirawan: So Sumeet, uh, it’s been a fascinating conversation. You know, I really love reading your book and also this conversation obviously, right? Unfortunately, we reached the end of our conversation. But before I let you go, I have one last question that I must ask to all my guests which I call the three technical leadership wisdom. If you think just like an advice you want to give to us as the listeners here, what would they be?

Sumeet Moghe: I’ll cheat a little. I’ll put out stuff from the Async First manifesto. So I would say, think about it as a manifesto items, right? So think about focus and cognitive flow over always on productivity, availability, right? So, for example, is it really about the work you deliver? Or is it about how many places people see you visible in? It obviously isn’t the latter. It’s about the work you deliver. So that should be more important.

The second is, we’ve talked about this a couple of times in this podcast episode, which is AI is going to be a superpower. Embrace it. Embrace it as your co-worker, embrace it as your coach. That’ll be a big thing in helping you work asynchronously and to actually elevate your standing as a technologist.

And then finally, if you are a leader, then don’t bank on lucky things happening. I’ll give you an example. Oh, we will all come into the office and then we will all have coffee, and then therefore we will all share knowledge. I think you’re just betting on luck that way, right? Don’t do that. You need to have intentional actions, not serendipitous success. So what does that mean? You create the systems for that success to happen as part of your daily life, right? So if you want good decisions, set up a process to make good decisions. If you want good knowledge sharing, then set up a system for good knowledge sharing. If you want good code quality, set up a system for good code quality. Don’t wait for an accident to happen. Oh, because we sat at the same table, we had good code quality. I think that’s rubbish.

So those are my pieces of advice. Focus, AI as a co-worker and a coach, and then intentional actions.

Henry Suryawirawan: I was laughing when you mentioned about this serendipitous thing, because it is one big reason whenever leaders say you must go back to the office. Because we want to allow more serendipitous moment where, you know, you bump into someone in either the pantry or, you know, during coffee, lunch, whatever that is. And it sparks an idea, you know, that creates a big innovation and things like that. Obviously, sometimes it could happen, but I would argue that it is very rare that actually you will have this kind of serendipitous moment. And creating systems to allow, you know…

Sumeet Moghe: I was saying it’s funny because you are saying that knowledge sharing is really important and you want to leave it to the chance that two people are thirsty at the same time.

Henry Suryawirawan: Yeah. So I think, yeah, creating systems is much more important, right? Maybe you create community of practice, channels, wiki blogs, whatever that is, right? So that this serendipitous moment can also happen without leaving it to chance of people bumping into each other.

So Sumeet, if people love this conversation, they would want to connect with you, ask you more questions, maybe about best practices, is there a place where they can find you online?

Sumeet Moghe: Yeah, I write every week on asyncagile.org. You can follow my writing there. I’m also on LinkedIn, Sumeet Moghe. You can find me with my first name and last name. Yeah, those are the two channels that I maintain. And you can always get in touch with me either using the contact form on my website or through a direct message on LinkedIn.

Henry Suryawirawan: Right. So if people would love to learn more about asynchronous work, remote work, I highly suggest Sumeet’s book, right? It has a lot of important things that you can learn. Thank you for writing that and thank you for this conversation, Sumeet.

Sumeet Moghe: The pleasure is all mine, my friend. Thank you so much for inviting me.

– End –