Asynchronous collaboration: Getting it right

Episode transcript

Neal Ford: Hello, everyone, and welcome to the Thoughtworks Technology Podcast. I'm one of your regular hosts, Neal Ford, and I'm joined by another of our regular hosts, Ken, who I'll let introduce himself.

Ken Mugrage: Hi, my name is Ken Mugrage. Nice to be talking to you.

Neal: We are talking today about asynchronous collaboration. We have two guests here, who I will let them introduce themselves, starting with Maya.

Maya Ormaza: Hi, I'm Maya Ormaza. I am from the Chile office right now.

Sumeet: Hi, I'm Sumeet, and I'm a product manager at Thoughtworks.

Neal: All right, one of the topics that came up on our most recent Technology Radar, and in fact, one of the things that yielded one of our themes is this idea of have we gotten better at remote work. We were building slowly good practices, and then we were forced to do it for a while. Now it's sometimes optional, as to whether you can work remotely and asynchronously or not. We have some thoughts about that, that we were going to talk about here on our podcast. What is our opinion about the asynchronous collaboration in the current post-pandemic era?

Let Sumeet start because he's been thinking about this a lot to the point of writing a book about it. We should talk a little bit about what his book is and some perspectives he has.

Sumeet: To be honest, I tried to decouple those two concepts of remote and async, and I'll tell you why. Of course, it works more effectively when you're remote because when you're remote, if you're trying to do every interaction through a conversation, then before long your entire calendar is cluttered with meetings. Each of us is a technologist in this conversation, so we know we need blocks of time where we are uninterrupted, we have deep focus, where we're able to hammer away at a problem either by ourselves or in pairs.

Somehow a constant culture of meetings, which remote work drives, if you've not thought it through properly, can come in the way of that. It also comes in the way of distributed work, which is another variant of remote work, which we've practiced for many years, where we work across geographies. There meeting-centric culture starts to take a toll on people's lives because, well, I'm doing this call right now, this conversation at, what, 9:40 my time.

If this was my daily routine, which often it happens to be for many people who are working across India and the US, then it starts to take a toll on people's personal lives. That as well can't be a sustainable way of delivering projects, and indeed XP talks about a sustainable pace. I think asynchronous work comes to the rescue in some of those places where we can take a more pragmatic approach towards what do you communicate in real-time, and what can wait a bit.

Then there's, of course, the archival value of writing, which is that when you write something, and you're not, of course, writing for the sake of writing, and creating reams of documentation because you have some compliance to complete, your writing because it's effective, and it's a scalable way of communicating, and you're writing with empathy as well. That can then start to build the knowledge base of the team and help other factors.

Developer knowledge to developer portal. It starts to help onboarding. It starts to make a number of processes easier, you start to keep better decision records, so you can trace back where your project came from, and stuff like that. Even when we are in the same place, I argue that reaching for a conversation is not always the best thing because, hear me out as I say this, that sometimes we have this tendency of, "Oh, let me tap Ken on the shoulder and just get an answer immediately."

What I've done is I've possibly disturbed Ken's deep focus at that time. Some questions aren't urgent enough that we need them addressed immediately. Some problems don't have to be addressed at that point of time. Can we write things up? Can we actually structure a problem through writing? Sometimes the solution emerges through writing. That's indeed the premise and the argument of the book, if I had to sum it up.

Neal: Let's talk about one interesting aspect of that. Thinking in that way forces you to think about what is the appropriate communication channel that I should use for this and every software project I know has a place where information goes to die. It's very often Slack now is the place where information goes to die. Because it's so ubiquitous, that's where you dump all information because that's just where it goes without thinking about, "Well, what should be longer term, and what is, in fact, really ephemeral?"

If you started thinking about that from the outset, I think you'd do a better job of capturing the things that you do, in fact, benefit from keeping longer than your typical plaque message.

Sumeet: Yes, I agree. I think you make a fine point there about where information goes to die. I found that to be the classic case of the tragedy of commons: everyone owns it, but nobody really owns it, and therefore, information goes to die. On distributed teams, it's got to be a conscious act of design, where just like you're pruning your codebase, you're refactoring all the time, you're getting rid of stuff that is not needed anymore, and you're keeping it useful for everyone.

You've got to do that with whatever documentation repository you're using. In fact, when I was doing the research for the book, one of the things I noticed, you mentioned Slack, a lot of companies that have been doing this for a while, and a lot of teams even that I worked with, they had a policy to make their Slack messages expire, the most extreme one that I saw was 45 days. If you believe that it needs to be archived somewhere more permanent, then you better don't put it on Slack.

Ken: I've seen some bots and stuff that just archive stuff, and I personally hated it because it just moves mud from one place to another. Have you ever seen anything like that, are people doing chat in such a way that they can archive stuff in an effective manner?

Sumeet: The one which I'm finding really good is the one on Zoom, the AI companion, and I think that one does a pretty decent job of archiving meetings because what I noticed often is we'll have a meeting, and meetings are inevitable, you can get as pragmatic as you like with meetings, but there will always be meetings on a project team. What usually happens is we never document them and summarize them for the benefit of others.

Often, I've noticed the anti-pattern of just sending a Zoom recording to people and saying, "Oh, we spent two hours in a conversation. Now, you spend two hours as well trying to summarize the whole conversation for yourself," which is just unempathetic, whereas the Zoom AI companion does a good first cut for you, where it just summarizes the whole thing. Then you can take a few minutes after the meeting to clean it up, and then put it into wherever you put your meeting records. I found that work well. Slack, I don't know, Maya, do you know much about that, Slack?

Maya: I'm just going to comment that, I find that just the video recording of the meeting, I find it to be maybe the least effective way of documentation because you are making people who are in need of information scan, I think that's very difficult to scan. Even more, if you were in the meeting, so you don't know in which part of the video you're going to find the information. Having tools that make it possible for us to extract the meaningful parts of a meeting are great companion, pun intended, to have handy.

Neal: Let's talk about some of the benefits of asynchronous when it's done well. I know Sumeet is cataloging some of these benefits, and perhaps some advice about-- we're talking about artifacts. What work sort of artifacts should you keep longer and which are much more ephemeral? How do you think about categorizing information in that way that facilitates, as you said, both asynchronous work, but also longer-term documentation?

Sumeet: Pardon me, I live in a country where our political leaders come up with acronyms to help us remember things. I came up with an acronym as well, and I call that acronym DEEP. I think you'll identify with some of these. D is for decisions. If there's ever a decision, then you should record the rationale for it. We've talked about it endlessly on our Tech Radar's decision record systems, but I extend that to business decisions as well, and general decisions as well, so similar format.

Then there's events, so you have a town hall, you have a meeting, all of those are events. You better document them for the benefit of other people, and when I say document, I mean summarize. Sure, you can have a recording or snippets of recordings if they are useful for people, but the summary is the more important thing. Then there's explanations, and I found these very useful in the context of onboarding because there's a lot of explainer material that gets repeated in onboarding, and those are definitely great candidates for documentation.

The last one is proposals. I call that proposals, but really I'm trying to talk about things like ideas. Let's take an example. I want to use this new library on my project. I have a certain rationale for it. Let me write down the thought process. What value is it going to bring? Let me present it to everyone. Everyone has the time to consume it. Oftentimes we go into decision-making with a lot of cognitive load where Ken explains in rapid-fire things that he's been thinking about for the last 15 days, and now I have to consume it in the next 30 minutes and give Ken a yay or nay.

It's really difficult because Ken's done all the deep thinking, I need the time to process it, and writing gives me the time to process it. I can also not give knee-jerk reactions, but considered reactions. Proposals, and that starts to include design documentation, idea papers, any kinds of proposals that you make on the team. That acronym DEEP is a good trigger for teams to hold on to and think about, what is the documentation we are creating in the flow of work?

Now, one of the words of caution there is that an audit trail is only as good as a stop summary. Many of these things are audit trails that you're creating in the flow of work. Somebody new joining your project needs to have a summary that gives them a headline of where the project is. That's why I've always recommended that on projects we have a handbook, which has a reasonable structure, and that structure's maintained by the team.

There's a fairly comprehensive information architecture that we recommend in the book, but that handbook should indeed provide that summary that people can look at and understand this current state, and then if they want to plow through an audit trail, they can always do so if they wanted to.

Neal: Let's say that you have the discipline to create documentation like this. What additional benefits do you get out of this from not just an ability to possibly work remotely, but even for teams who are not working remotely, thinking about information management as if you had asynchronous communication?

Maya: Yes, I would like to comment on that one. If we think about the evolution of a team, we usually think about Tuckman's model. The forming, storming, norming, and performing. I think part of that process is how good we get at making information available when it's needed.

Part of that is, as Sumeet was saying, is documenting things. It makes us much more effective than onboarding new people, for example. Using tools that we empirically or academically know that will work, like decision records for several things, I remember that in the last radar, we talked about ASTERIX decision records. We need to know why things happen the way that those happened.

I've seen that things become high-performant in a better and faster way when information is available for them and for others around because if we have our processes or the outputs of our products and solutions available for example, for other themes that need them and that are working close to us, even delivery management becomes more fluid. I think understanding how we manage information makes us evolve more efficiently.

Sumeet: Yes, yes, absolutely. One of the things which we often don't consider as a benefit, so communication at scale and onboarding, knowledge sharing being those two advantages, of course, look, on this particular discussion, we've got three English accents at play. In a multicultural team, people speak English differently. I came from a family where my mother spoke a different language, my dad spoke a different language, and then we had to default to a link language. One of the link languages had to be English. Many people in my country don't learn English as a first language. That becomes a challenge.

In certain circumstances where you have non-native speakers and native speakers of English, oftentimes, you have this Captain America phenomenon where the most experienced, the most extroverted, the most fluent person usually dominates the conversation. That's not a great thing for inclusion.

Whereas if you look at how tools have evolved, you've got writing tools, you've got spell-checking tools, you've got tools like Hemmingway that make your language simpler. Writing somehow levels the playing field a little bit. If you're consciously trying to be empathetic, then writing encourages you to slow down a little bit as well, where, just because the proposal comes from the most junior person on the team, you're not going to dismiss it offhand. You're going to take the time to read it because you're actively practicing empathy, and then you will give a considered opinion on that. There's inclusion.

I think there are a couple of other benefits as well with going asynchronous. If I can't tap Ken on the shoulder, I'm using that example, all the time, there are going to be times when I'm going to have to take a decision by myself. That encourages a bias for action.

Too often I feel like we create too many gate checks in our process. I will ask this person for that, then I'll ask this person for that, whereas the good thing with software, with all the advancements in continuous delivery is that everything, almost everything, unless you're making a decision to tank the business, is reversible. We should have a better tendency to make decisions.

The bias for action comes into play. You get more time for deep work if you don't have so many meetings scheduled in our calendar. The thing is, now with this remote work revolution that got triggered with the pandemic, we were only able to scratch the surface of the level of flexibility people can have. We scratched the surface in the sense that we got to location independence.

Talent happens to be this big differentiator in tech. If you're able to hire people from just about anywhere in theory, and if they can work with minor overlaps in time, that then becomes almost a superpower in terms of crafting teams because now in addition to giving people location independence, you can also start to think about time independence.

Ken: Question, you touched on it a little bit there. Writing is also a skill. It's a depreciative-- what do I want to say? It's a skill that goes away over time, if you will. You got people at Neal's end that have written, I don't know how many dozens of books, and people on my end that struggle with the first paragraph. You touched on Hemingway, a couple of other stuff. What do both of you recommend to teams where some people just aren't comfortable writing or aren't good writers, or what do you do there?

Maya: In our contest right now, [chuckles] even if I am not as good as writing, maybe even more, if it's not my native language, I'm going to be even worse at speaking it fluently. The process that I have to make to write allows me to then, if we got to have a conversation about that, "Oh, I have some pointers about what I wrote already." I think in terms of how easy or difficult it is, it may be even easier to train than actually speaking because for speaking a second language, or even to publicly speaking, you need more resources, different setups than you'll for writing.

Because we are relying a lot on chat, for example, you're going to do it, even unconsciously, you're going to train the way you write your ideas, you receive feedback very fast, even if it's not intended as being feedback, like, "What did you mean with this? Can you clarify that?" That feedback loop is very, very short. It takes seconds, it takes minutes. That's a good way to put it. Yes, we have to train it, but we are already doing it and maybe we can be more delivery to do things like that. For example, when we have to write actual documentation, for example, okay, let's give it a bit more time and see that we are completely clear. Even then, a feedback loop can be much shorter, I think.

Sumeet: Yes. One of the things I've noticed, especially because many of my colleagues are not native speakers of English, is that there are a couple of ways of getting around the writer's block. One is to tell yourself that you're not trying to write like a novelist. You're trying to write like a journalist, so you'd like to get to the point as quickly as possible.

Your creativity in this case doesn't matter as much as your clarity. That's one thing that puts people at ease when it comes to the writer's block, but that's just a mental thing to a certain extent. Then there's the mechanics, and I've seen some people get through the mechanics in different ways. For example, I've seen some non-native speakers start writing in their native tongue and then use translation tools to get to an English version. Of course, there are certain languages that translators don't handle well.

Then you go through the standard writing tools, like there's ProWritingAid, there's Grammarly, Microsoft Word has some great readability tools built in. It depends on the tools that you're using, which can help you finesse things.

The other thing I've seen people do is speak into the microphone. Just record yourself through your recording into something like otter.ai. Otter does a great transcription, right? Then what you have is your mind dump, so to speak, and then you can start cleaning it up. There are good tools to clean it up. General writing tools, structure it into headings, organize it into tables, see where you can add bullets. When you want to convey some emotion, if you really need to, or maybe you want to get people's attention, start using things like emojis, diagrams, you can start using those best practices.

Again, it's an iterative process. You don't have to get it right first time because the good thing, as Maya said, is you write, somebody looks at it, then they say, "Well, I don't understand this." They give you some feedback. That's a point where you can refine your writing and make it better. That's also an iterative process where it doesn't have to be one-and-done.

Maya: Yes, and actually, I do that a lot. I use the Google Docs one, which has a lot of accents of Spanish, and mine in Spanish is very particular and it gets it most of the time. I still have to refine it, but it works as a brain dump always. What I've been taking advantage a lot of is that I can give another person that raw set of ideas, that raw paragraph for them to let me know in an instant, and they can do that in their time if it's not urgent.

I think now that I say if it's not urgent, made me think like, "Actually, let's classify the things." Sumeet was talking about that at first, I think. If I don't have to tap your shoulder, how do I get the information get to you? How do I ask? What's the best way to ask? When we were co-located, most of the time even then, we had some remote and synchronous interactions, but now I think it's even more important to understand how to prioritize the timing that we need an answer to.

If it's something that doesn't need an answer today, maybe chat is not even the best way to ask because things get lost there. Maybe I have to do an email, maybe I have to write a document and put it on your knowledge base or something like that. Main point of this is that we need to understand, and I think we've been trying to do that empirically to understand the priority of the communication that we need to have for certain things and different points of time and with different stakeholders or peers. That might help us understand what's the best way to communicate that, even the worst to use if we are doing writing or the media that we want to use.

Neal: I ranted about this to the subject way back in 2017 in my book, Productive Programmer, and talked about don't constantly check your email, don't turn on notifications because if you constantly get interrupted, there's no way you can do that deep constructive work. I think that's key. Try to retrain your culture that you don't instantly answer every email, that there should be reasonable amounts of time to answer things.

One of the things I point to is the distinction that was made in a time organization system between things that you can put a matrix of important and urgent things, and important urgent things you should deal with, but a lot of things in your day are urgent, but they're not important. You need to try to filter those urgent but not important things away, which are just interruptions, and try to focus on the sweet spot of both either important or both important and urgent.

Maya: Yes, I love the Eisenhower matrix that lets you classify things and importance and urgency because then we don't have to forget the things that are not urgent, but they are important indeed. I think those are the ones that get lost in the space most of the time. For example, documented things for other teams. Instead of just answering a chat with-- what's the meaning of this field in this contract, for example, something that happens all the time, instead of pointing them to documentation that we update because we don't prioritize updating it because we are so focused on the instant happening of the things.

Sumeet: Yes, I think one of the things that just came to mind when Neal was saying, you can't be productive if you're constantly looking at email and chat, I realize that being able to resist email and chat comes with some level of experience and confidence and security that you have in the team.

For example, after having spent close to 16 years in the company, I can feel confident to say, "Look, I'm not going to look at email and chat," but I noticed that a junior person on the team may not have the same confidence. They're probably looking at email and chat and saying, "Oh, did Sumeet message anything that I need to look at?" I feel like it's always good as a practice to define a team contract and say which channel requires what level of engagement and what speed of response.

Every time we've done that exercise as a team, we've discovered that the only urgent medium of communication, which is a production bug, client needs our attention, or the system needs our attention, or everything's going to fire, the only medium for that is a phone call because if you're expecting people to just keep command tabbing onto their Slack, that basically means you're expecting them to be interrupted all the time. You've got to have phone numbers in a directory and then call if you need urgent help.

Ken: Switching just a little bit, there's a lot of engineering practices that-- I don't want to speak for our guests, but there's certain things that do have to remain synchronous. First off, I guess, do you agree, and what might some of those examples be?

Sumeet: One of the things I shy away from is being prescriptive about which specific practices you want to keep synchronous. What I'd rather ask individuals and teams to think about is what value are you getting from either mode of communication. For example, if you're trying to get speed, then going asynchronous is probably not the best idea because you're going to be writing and it's by nature slow.

In that case, you go synchronous. Similarly, if you're trying to build connectedness, we probably could have exchanged ideas even between the four of us on a Google Doc, but there is probably a sense of connection that we are building even in this conversation where we are able to see each other and experience body language. If I had to prescribe, I would say one-on-ones, absolutely, you've got to do those synchronously.

Those are incredibly important practices to build team connection. Then if you want to cover a breadth of topics and you want to do them again at speed, then that's a great candidate to do synchronously. For example, if you wanted to do a quick health check, you wanted to look at your metrics and you see all of these high-risk code branches, all of these reviews pending, and you wanted to triage them at speed, no harm in getting into a meeting because you'll do them at rapid speed, and you'll get a lot of breadth in a short period of time.

That trade-off needs to be clear to people. If you want depth, you want focus, you want thoughtfulness, you go towards async. You want speed, connectedness, spontaneity, then you go towards sync.

Ken: What about just thinking of software engineering practices like pair programming and stuff like that? How do you deal with those in an async team?

Sumeet: Yes, pair programming is a cornerstone practice for XP. It keeps you honest with your design principles, coding standards. It helps you coach, teach, all of those things. I would say keep that and regard that as deep work. What I would say, however, is that when the team is very distributed and you're trying to pair across geographies, it can become very constraining.

A technique that I've found in teams work really well is this notion of a baton pass where you decide a certain number of hours that you're going to work in pairing mode. Let's say that's three hours, four hours in the day, that works as an overlap for you. Then somebody who starts working solo, you then come and pair for a bit, and then the other person continues working solo, and then you pick up the pieces again the next day.

I found that model to be a happy balance between eight hours of pairing and no pairing at all. When I was doing my research, I noticed tooling being rather neglected because I noticed a lot of teams have Zoom, or they have teams, and they believe a good medium for pairing, and it turns out to be incredibly laggy. I don't know who has paired on Zoom and enjoyed the experience. There are tools like Tuple out there which are incredible when it comes to pairing, and they give you a far better experience. While we say tools don't matter, in distributed work, tools facilitate the work. Don't neglect them. Definitely don't neglect developer tools like Tuple.

Maya: Absolutely. I was going to comment that I've had the luxury of having my teams mostly in the same or close time zones. In that case, pairing has been the default most of the time. Even then, pairing on a call for the whole day is very exhausting. It's absolutely exhausting. What we've done often actually is that we have deep work as a pair, and then we may be split for some other tasks or to complete some other things. We get together mostly for strategy and for the core part of the feature of whatever that we are building.

Also then, I think, practices like committing often, having clear commit messages, having clear name tests are even more important when you have to pass your work to another person because then there's no need for a lot of additional extra documentation, but the code is going to be what tells you what's been done. Yes, I was thinking about that because in other ways, for example, if there was just one commit for the whole day of work or things like that, passing that baton, as you mentioned, will be very difficult because a day of work-- programming is a creative work. A day of work can be a few lines, or it can be half a system.

Sumeet: Yes. In fact, you were talking about those blocks of deep work, and on one of my teams, we implemented it as a forcing function. Where we started off, our entire day used to be littered with meetings, and what we said is, "Let's move all meetings to a specific half of the day and make the remaining half of the day in violet," which means no interruptions, no meetings, it's reserved for deep work and pairing. That worked really well because, again, you're not taking away any meetings, but at least you're giving yourself long spells of deep work.

The next step there was we made Friday's meeting free. The great thing with making Friday's meeting free was it allowed everyone to end their week with a sense of accomplishment because you could get a lot done on Friday without meetings. That was the additional benefit we got there.

Neal: Okay. Let's talk about-- Sumeet has put together 10 tips to go async first. Let's talk about those briefly as sort of a call to action as good advice for people who are thinking about this or currently doing this and want some ways to improve what they're doing.

Sumeet: Right. I can come to something that might seem controversial on the face of it, which is clarifying your process, which is the second of the 10 tips. The reason I put that in is that I noticed two extremes of process. One is a process that just paralyzes you. You can't take the next step because you're no longer a team. You're a tech bureaucracy. Then there is the laissez-faire approach where for every task, you dream up the process of fresh, and that's where you start seeing everyone swarming for every task that you're trying to do.

There's got to be a happy medium in between. What I generally attempt to do on my teams is that we've got our Kanban board, and our Kanban board represents all the stages that work generally goes through. There will be exceptions where we make our Kanban board represent all of those stages. There are no shadow gate checks, no approvals that are not part of the stages on the Kanban board. Then the good thing with some of the modern tools is if you wanted somebody to complete a certain set of steps for them to transition from one stage to another, you could help them remember those steps with the help of a checklist, and you can make that checklist a part of the transition.

Atul Gawande has written a great book about the checklist manifesto, how useful and powerful checklists can be. They're just reminders in the flow of work. When you move let's say a story card to being ready for testing, what should you have done for the story card to be ready for testing? There are some standard things that you will do for every story, and there might be some specific things that you're doing for that particular story. Clarifying the process creates a great sense of calm, and it takes away this idea that everyone needs to get together for every task and create that sense of chaos. That's why I put it in there.

I think the other one was around just reducing the blast radius of communication. This is something that everyone on this conversation will identify with. Oftentimes, you have this big team chat room and every discussion happens in that team chat room. What it does is effectively it's creating notifications for everyone, regardless of whether they need to be in that discussion or not. Everyone's doing it with good intent because you want to be transparent, you want to keep everyone in the loop and all of that, but you're also creating a lot of noise while you're going through the process.

If the discussion only needs two people, can you have the discussion in a smaller group, a slightly more ephemeral group, and then convey the summary in that chat room, or maybe even in a decision record or a meeting minutes document, or something like that? In a similar way, you have this tendency of pinging people and saying, "Hi, Maya." Then you're waiting for Maya to say hi back.

It's always better to say, "Hi, Maya. By the way, I was looking for this documentation and I can't seem to find it. Can you point me in the right direction?" Now you've reduced the number of messages, and again, you're reducing the blast radius of communication. A few empathetic moves that you make where you start to reduce the noise in your teams can actually help calm teams down in a big way, especially when you're working distributed.

Neal: Okay. Maya, you said that you'd like to, before we wrap up, comment on the role of leaders in this process of asynchronous communication.

Maya: Yes. Before, when we were mostly co-located, we would see emerging leadership was very apparent because you would see the person that is, I don't know, that gets up and goes to the board and writes down things and things like that. Making this process asynchronous, I think pushes us as team leaders to be facilitators of this kind of communication and to make them or help teams find the ways to communicate and to work in the ways that are more effective in this setup. I think we have to be vigilant of the things that work.

Critical as well, like, is this working for us? Do we have to change something? There are going to be times in the teams, for example, when a team is starting that we are going to need a lot of synchronous communication. We are going to need to get to know each other. We're going to need to put a face on people from the business side of the problem that we are solving. As we progress as a team, we walk this path, in which we can rely a lot more in asynchronous communication. I think the role of leaders is to trace that path for teams so that we can use the tools that we have and we can make it easier for teams to work in what they do best actually.

Neal: Maya brings up a great point that we had talked about even before the podcast started, that this is not a full-throated endorsement of only doing asynchronous communication because there are always trade-offs to these practices. Maya brings up the great point here that you should be always self-aware at a project, at an organizational level.

When you try these kind of things, does it actually work? Is it making something better, or is it not? One of my favorite things about extreme programming was always the last step of XP, which was fix XP. If you're trying all these practices and it's not actually working, then fix it and you're not bound to it. You should always be self-aware, always look for feedback loops, and adapt, and make sure that practices like this are adding value to what you're doing.

Sumeet: Yes. You make a great point, Neal, because I recently wrote about this. There are a few pitfalls here, and one of the pitfalls is people trying to do this by themselves. This is a "Don't try this at home" type of warning because, look, you get the network effect of any team practice if the team adopts it as a whole. I think of it as three things you need to take care of if you're trying to shift in this direction. By the way, very early on even in the book, I mentioned async first is not async only.

It just means you start asynchronously and you go sync if you need to, if the situation demands it. The three things are, one, your team has to buy in. Your team needs to see some value in it. Any of the benefits that we discussed are all of the benefits that we discussed. Does the team see those benefits as real benefits or do they not care? If they don't care, then you're not going to go too much of a distance.

There's the question of business buy-in because, look, we're talking about shifting your ways of working however slowly, and I think everyone who's tried to change ways of working in any way knows that you will, for a period of time, see a slight dip in whatever productivity measures you're tracking. If the business is saying, "Well, we can't make any compromises on that front," then you're going to struggle to make any kind of change. You've got to account for whatever dip in productivity that happens. It's got to be reasonable, but you've got to have the business buying in.

It's just not enough to say, "From tomorrow, we are not going to do any meetings," because teams have practices, rituals, ceremonies that they go through. You've got to go practice by practice and say, "All right, is there an asynchronous variant of this, or can we include more asynchronous practices in this?" That can only happen at a level of depth, it can't happen at a very generic kind of level. Anyone listening to this podcast, I would encourage you to keep those pitfalls in mind, keep that word of caution in mind, and go practice by practice. It has to be a deep well-thought-out exercise.

Neal: That's a great way to wrap things up. Thanks so much, Maya and Sumeet, for joining us today and providing your perspective. Thanks so much to my co-host, Ken, for helping me co-host today.

Ken: Thanks Neal.

Sumeet: Thanks for having us.

Maya: Thank you.

Neal: Thanks for listening to the Thoughtworks Technology Podcast, and I hope you join us again for a future episode. Have a great rest of your day.