EP049 - How to collaborate async-first remote teams with Sumeet Gayathri Moghe at Thoughtworks
About the episode
This episode focuses on async-first collaboration techniques within remote teams. Our guest, Sumeet Gayathri Moghe, is an agile enthusiast and a published author of The Async-First Playbook. He blogs weekly on his site, Async Agile, and helps software teams collaborate better at Thoughtworks.
About the guest
Sumeet Gayathri Moghe is an agile enthusiast, product manager, and design nerd at Thoughtworks. He’s worked with a variety of clients over the last few decades, building software products and helping them improve their engineering effectiveness. During his time as a consultant, Sumeet has exposed himself to various domains such as retail, travel, telecom, payments, healthcare technology, education, and more. That, in turn, has helped him generalize his experience across industries.
He is a published author of The Async-First Playbook: Remote Collaboration Techniques For Agile Software Teams.
You can get his book with a 35% OFF discount by applying the code “ANYWHERE” during the checkout HERE.
Sumeet lives in Pune, India, with his wife and two kids. When he’s not at work building software, you’ll probably see him looking through a camera’s eyepiece, photographing wildlife or a scene in the wilderness.
Connect with Sumeet on LinkedIn or visit his website or his photography project.
About the host
My name is Peter Benei, founder of Anywhere Consulting. My mission is to help and inspire a community of remote leaders who can bring more autonomy, transparency, and leverage to their businesses, ultimately empowering their colleagues to be happier, more independent, and more self-conscious.
Connect with me on LinkedIn.
Want to become a guest on the show? Contact me here.
-
Welcome everyone on the Leadership Anywhere podcast. This is a very special and also a little bit more personal episode to me. And let me give you a little bit of a background on why. A couple of months ago, almost a year ago, I started to do some research on asynchronous leadership. Mainly for my book Leadership Anywhere first But also because I practiced asynchronous leadership tactics for a while, but I didn't know most of the practices were intentional and also organic through my journey and when I did the research, it was really hard to find like minded people online who also created like the same content with the same agenda with the same takeaways. And that's when I found today's guest Sumeet Moghe from ThoughtWorks. He's written a book about asynchronous leadership as well. But before the book which is, I'm not sure, not live yet, but we will see it and then hear it from Sumeet personally. Before that, he also contributed to a website called Async Agile, where he created a lot of practices, templates, and all the goodies for people who were introduced or wanted to learn more about asynchronous leadership. And that was pretty rare at that time. Now it's a little bit more prevalent, a little bit more popular but a year ago, it was truly a unique concept. So a very special welcome for Sumeet and thank you. Thank you for joining the podcast.
Pleasure as always, we've never met synchronously before. This is our first sync. So everything that we've done was asynchronous. Yeah, I'm really glad to be talking to you, man.
Same, likewise. We actually been in touch for more than half a year or even more so I'm really glad that you are here. Just a first question. Quickly prompt you how did you start in asynchronous leadership? How did you end up in remote work? Tell me your journey.
Yeah, so like some of us who are more big proponents of remote work these days, I started remote working far ahead of the pandemic. My job is in consulting. And so at the time, a few years before the pandemic, I was consulting for a client where most of the team was in central and eastern Europe. And I was the only person sitting out of India. And before that, I used to go to the office. But at that point, there was no incentive for me to be in the office because my entire team was working in a completely different continent, completely different time zone. And at that time I was working remotely, but not as asynchronously to start with. But you can imagine once you start to have to straddle time zones, then doing everything synchronously becomes painful.
Yes.
And you've got a few people sitting in Ukraine, a few people sitting in Belarus, a bunch of people in Germany, some in France, some in Belgium, and you yourself in India you either take a toll on everyone's personal lives, or you make the adaptation, right? So that's how I took to working asynchronously during that time. And then, of course, the pandemic happened. And what I noticed was that if you've been a consultant, you realize that you're always serving a client, right? And we work in all sorts of situations. So there's clients in India. We're in the same time zone, slightly easier to collaborate with, but we also serve clients in the U. S., for example. So if you now start imagining winter in the U. S. and you think of San Francisco. And you think of my town, which is Pune, that's about a 13 and a half hour time difference.
Jesus. Yes. Yeah. West coast is always the worst in terms of time zones when you need to work with them.
There's no overlap time. Yes, there is not. Look, you're in Europe. I'm in India. So there is overlap time. Between those two, at least a little bit. Yeah. Yeah. But between those two locations, there is no overlap time. So it basically means that people are going through sleepless nights. And while people will do it because they enjoy the work or they feel about the client's mission, it burns them out. And I saw that with remote work and the life and work boundaries getting completely blurred, it was starting to take a toll on people's lives. And that's where, so I observed this for a year and a half which was 2020, and then somewhere at the end of 2021, and I started going with the idea of we need to write about these practices and one of the things you will note from your experience as well, because your book is a lot about leadership, right? And operations it was amongst the books that I read as part of my research writing my own book the gap that I saw was that on software development teams, we follow a lot of practices, which over the years have become increasingly synchronous.
Yes.
So you need a big sprint planning meeting where you get everyone together and you decide what you're going to do for the next two weeks. Then you do a sprint review where you decide, have you done the right things? Then before every requirement gets played, a bunch of people get together to figure out, Oh, have we written this requirement? Have we understood it? All of that stuff. And before you know it, these little meetings, they start to add up. And when you start doing these across time zones, they add up even more. So my idea of writing the book was to say look, we've got to get down at the practice level, a little more hands on. So in principle, everyone understands less meetings better, but how do you make it happen at the practice level? How do you do sprint planning better? How do you do brainstorming better? How do you do decision making better? And that's why the book that I wrote was more in the format of a playbook. You don't need to read. end to end, you feel like you want to improve one practice, just go to that chapter, read that one chapter and you're done.
Sure.
And that's the idea. It's more a reference book, more a playbook, you pick out techniques and strategies that work in your context.
Yes, it works pretty much the same as your site Async agile which hosted, you forgot to mention that because it's super important by the way, but let me pitch that to it's a collection of templates and resources which people can, and it's and all of them are a hundred percent practical and tactical on how people use that. But before, before we talk about that I think it's super important that you said that because you said that time zone and location in remote work burns people out if you need to work on, I don't know six or eight hour plus of of time zone differences. And it's the same argument that I always hear that the office burns you out. So that's why you switch to remote work, right? But you can actually get burnout from remote work if you do a lot of time zone differences in synchronous work. Why do you think we do, why do you think we still have so many synchronous additions into the remote work aspect, why people do prefer working synchronously a lot and not asynchronously. Is it a knowledge issue? Is it a leadership issue? Or how do you see that?
It's a bunch of a few of it's a bunch of different reasons. So let's unpack them, right? And this is my theory. And you can tell me what your theory is. My theory is there's a little bit of an inertia and hangover from the office era. In fact, there's a lot of it. At the time of recording this episode, when we are having this conversation, you're seeing the entire return to office push, right? Because... Somewhere at the back of people's minds, there is, at least at the back of some leaders minds, there is this feeling that, oh no, the office was the paragon of how we used to work. Now, when you start thinking of that as the holy grail of how you worked, then you model every piece of work that you do around that style of working. So in the office, what would you do if I needed Peter? I would just tap him on the shoulder and say, Hey, Peter, tell me what you the answer to this question, right? It didn't matter to me that Peter might be heads down trying to get some writing done. It's just that I have Peter right next to me. I can disturb him. No problem. I didn't even think of it as disturbance, right?
Yes.
This is exactly what a lot of leaders talk about that. You have access to everyone and then you can shout in the middle of the office and everyone will have your attention. They don't think about the cost of disruption. So there is some of that naivety that exists around what effective knowledge working looks like. And the fact that deep work and focus is important. And so you can't be disturbing people. So one is the inertia and the hangover from the office era, which we still haven't gotten over. The other part of it is that we lack hands on leadership. What I mean is that a lot of people who are, for example, pushing for return to office, they, let's accept that they're doing this with great intentions. They want their companies to be more successful, more productive, et cetera. But when was the last time they actually sat down and created anything? Most likely it was in the office era, some 10 years back, right? So the model of collaboration that they know is that model of collaboration, right? hyperactive, highly interrupted. So it's a combination of a couple of things, inertia and lack of hands on leadership, in my opinion. And you'll notice in contrast, a lot of startups that, and new companies that came up during the pandemic who started off remote. They didn't have the baggage of, we used to have an office. They just started off as native remote and many of their leaders are hands on and they have been hands on during the pandemic. They don't think that way because their thought process is remote native.
Yes.
And remote native and async go together.
Yes, let's switch to practical. I agree with everything that you said, by the way. One quick addition, I think it's also the knowledge. Is that most of the, yes, most of the companies that started in during the pandemic, they are remote first. Therefore, they are more receptive to asynchronous practices. Although most of the founders usually people do have a a stereotype of a founder, which is like a 25 year old kid straight out of college and whatever. That's usually not the case, obviously given to every stats that we see, usually it's a 40 something person. Doing something that's a product that solves a problem that he saw or she saw in in an enterprise setting and couldn't solve it within the enterprise. So we see, or she started a startup company around it, but anyway that person. has the leadership baggage obviously, even though they start remotely as a company, as a new company. So I think there is a knowledge gap as well. That's why your book and your work and my work as well, and everyone else's work was doing and talking about this topic is super important because it feels the knowledge gap. But I think aside from the knowledge gap, there, there are some practical. I have no idea how to do that things. So let's talk about an example. I think both of us truly and utterly hate daily meetings and daily standups. Sorry about that. sO how you should do a daily meeting a standup meeting synchronously and asynchronously. I think we should tell the example as well. How Usually people do it synchronously because, that's most of the listeners will be familiar with that. But let's give an example of how to do that in async work.
Yeah. Before that, let's do you mind if we just set a little bit of context?
Yes, please.
So if you think about these daily standup meetings. It's from a time when time when you didn't have online task boards.
Yes.
You did not have instant messaging. There wasn't any of that stuff available, right? So the easiest way for a team to get a sense of status was to gather around a physical task board and say, okay, here's what I did. The task board just had little post its and index cards. You couldn't write too much on that.
Yes, the whole Agile concept, by the way, is coming from the 90s I think the 90s, end of 90s or something. Or even earlier.
Yeah. So the agile manifesto was written in 2001. There was no IM. There was no zoom. There was no electronic task board at the time.
Yes.
So you have to give them credit for doing the best in their time. But what's happened ever since is the tools have become very mature, right? And we've learned a lot more about what makes us productive. You also need to understand that particular manifesto, while it was a great manifesto, which was written in 2001, which talked about these agile practices, was written by 17 white men in a ski resort.
I didn't know that.
The industry values diversity a lot more. And you and I both know that when you start putting in restrictions, like you have to be here for this particular meeting, and you have to speak in this language, it starts to create restrictions on who can be part of your team and who can't be part of your team, right? The industry values diversity a lot more today, wouldn't you agree?
Yes, of course, especially when you think about remote work people can work around Side note here, when we talk about divers that always want to Highlight this one because it's truly unique In the sense that you are from india. I'm from europe and I think We think diversity a little bit differently than, for example the, in the U. S. So in the U. S. It's mostly faith, race and gender question. For us, at least for me it's more like a culture question. And when you work remotely obviously you have different races, different faiths, their genders and whatever, but you also have different cultures from different nations. And that's actually, I think it's harder to properly integrate into a team structure because people are just so freaking different which is okay but that's through the diversity for me when you do have a team That is globally distributed people are in india in the philippines in belgium in germany just imagine the situation. These people are utterly different in terms of culture. And how to make them work together productively, I think that's one of the key questions and also one of the best things of remote work. Because that's true diversity.
And I think the listeners will appreciate... No, I think you, you've hit a really important point because the listeners of this episode will appreciate the fact that you and I also speak English differently, right?
Yeah.
Then you start extrapolating this across all of those cultures that you talked about in my country. I was very fortunate to have an English education. I spoke English as a first language, almost all throughout my childhood. So I'm reasonably comfortable in English, but not everyone in my country has that same privilege, right? So even if you looked at a team that you assemble all in India, Everyone doesn't speak English the same way. So now, let's take everything that you said and put all of this into a Zoom stand up. The same stand up where you could lip read, you could see body language just because you were actually standing up, the meeting used to be shorter, because it's uncomfortable to stand for anything more than 15 minutes. Now you're doing the meeting sitting down, trying to make sense of accents.
Yes.
Of different places of a hyper distributed team. It never ends in 15 minutes. It's a 45 minute tooth pulling session. See when you stood in a circle in front of a wall, you knew whose turn it was next. Here you've got to endure a few moments of silence where somebody says, Oh, okay, I will go next. I will give my update next. And that's what slows the whole meeting down. So I've rarely seen online set stand up meetings being anything less than 30 minutes, right?
And sorry to shine the lights for everyone on this, because you are truly practically seeing everything, right? That yes. If you do have a global team, I've been in in this situation many times. If you do have a global team where you have people from Europe, people from the US and people from Asia when the Eastern European or the Asian people start to talk, everyone else tunes out from the meeting. I'm sorry. Because it's so hard to listen to the accent, so hard to keep focus. And sorry, but again let's be real here most of the leadership is in the U S or in Western Europe anyway. So they listen to each other, but when the others are standing up and giving the status report, they easily tune out because it's hard to listen. It's hard to understand. Sometimes and we don't even go into the technical details and shit like that I don't know, internet is lagging screens are frozen, and so on and so on and so on. And I think that's, these are like small details but these small details immediately add up into from a 15 minute session to a one hour tooth pulling session. Easy.
Correct. Correct. And that's the thing, right? The one thing that we both missed is think about this. I'm sick. I missed that standup meeting. Two days later, I see a result of a decision that was taken on that standup meeting. And I'm confused because I didn't go to that meeting. And then I'm told, Oh, but Sumeet, you know what, we discussed it in the standup meeting. This is an undocumented meeting, right?
Thank you for letting me know.
So these are some modern day problems with running remote teams and trying to do the same thing that we did in an office with a much smaller team, much less diverse team in a more remote, more diverse setting. So what would I do? For example, on one of my teams, I didn't have access to get a lot of these Custom built tools, right? So there's Parabol, there's a bunch of other tools that help you do automated standups if you wanted to but let's say you just wanna do status updates, right? So on one of my teams, Trello has a feature called Butler, right? And if you're using Trello as your task board, you can use Butler for automation. So what we do? Every morning, Butler would create a standup card. And it would email every member of the team saying, Hey, time to add your standup update into the comment section of this card. Everyone would come in, you would have their comments as a standup update. And you could consume them at some point that was convenient for you in the day, right? So that was the way we used to do stand up updates on one of our teams. There are multiple different tools. But now, if you ever wanted to go and see what did we discuss on the 14th of September? What were all the updates? You can always go back there, right? But the bigger thing is that a lot of your updates have to be in the context of the work that you're doing, right? For example, if I have a story that is related to a piece of code, Now my task board is Jira. My code repository is Git or Bitbucket. There are ways to connect these. So every time I make a commit, and if I have a reasonable commit message, I can have that be the update in the Jira card, right? So what is the standup at the end of the day? It's an update on work in progress. So anyone who wants the work in progress update can even go to the Swimlane that represents, okay, all the tasks in progress. And you just go and look at what the updates were. What was the last commit on each of these cards, right? So there's a lot of automation in place. You don't even need. One of those manual updates to happen. And I think that's the thing that a lot of leaders also need to explore. How many of these things can you automate and take out of people's lives? That's leadership, right? Where you simplify people's lives and take out the drudgery.
Yes. Yes. One of the, I love the Trello example, by the way, because I personally also use Trello and use the Butler with my own team. And I also sometimes just recommend for those who are just starting out in this, just to just simply have it zoom has, I don't know what it's called now. It's not here anyway. It's an AI transcription tool. Built in just simply record your meeting, transcribe it automatically give them highlights, put it somewhere in the company hub and that's it. People can see, read what the heck happened during the decision making of the meeting. Obviously it's not for the standup, but there are other longer meetings as well. In coding and in developer work there is the shared state of the code. And I think that's the same thing that everyone should aspire to as a workplace, there should be a shared state. Anytime I log into my workplace which is, even weirder to say that in the whole sentence, log into the workplace, you're not commuting, but logging into the workplace. You should be able to tell what's the shared state of the entire workplace within five to 10, 10, 10 minutes, just reading through stuff.
And you make such a beautiful point when you say workplace, because It reminds me of something I was discussing with one of my colleagues a week back. Look, when everyone, when we used to be back in the office, used to pay so much attention to the design of the workplace: how are you gonna lay out the tables? Yes. How are you gonna lay out all the whiteboards? Where are the task boards gonna be? Now, if you had to think about your digital workplace, why do we so think so little about it? We need to think about that as well. And the digital workplace needs to be as accessible as possible. As streamlined as possible. The great thing is the possibilities with the number of tools that we have and how much of. The functionality is built into some of the standard tools, like you mentioned Zoom, right? And I mentioned Trello and Butler that's built in for automation. The possibilities sometimes can be infinite. You just need to look under the hood.
Yes. And by the way it's getting even better and better with AI, especially with automation. So you can save a lot of time. Most people think that documentation takes us so much time. No, it doesn't, because we do have AI tools now. You just need to set up the processes and then you're good to go. Let's talk about the challenges a little bit because so I'm working really in the trenches. And so I teach others how to do that. But most of the questions I get are around proactivity. In order to be able to function asynchronously as an employee, not as a leader, just an employee as an employee, you need to be highly proactive. You have to be self aware to understand what you are doing, how you are contributing. What is your work and what is the goal of your work? And where you are at with your work. That's how you can actually give a proper status report, right? Now... And probably most of the Agile coaches will go mad after the statement. But the reason why we sometimes we do employ Agile coaches in the office is that they help facilitating that lack of proactivity from the employees, right? My main question is that if you've switched to async, do you need to hire only proactive people? Or can you teach somehow or set up processes that somehow I wouldn't say enforce, but create a more proactive setup so people can actually become more proactive organically to be self reflective because that's one of the biggest setbacks I think for because not everyone is proactive. Not everyone is working like an adult.
Yeah, so you definitely need a critical mass of proactive people. If everyone is passive, then there are no role models to learn from, right?
Of course.
And this is where, like they say in the aircraft, right? Wear your own mask first before assisting others. So leaders need to demonstrate that proactiveness in their own behavior. To a certain extent, because that's how people follow. But that apart, I think there's a little bit of an element of design in there. So let me explain what I mean by that. This is something that Cal Newport talks about. He references Peter Drucker. So what he says is that Peter Drucker came up with this Idea of autonomy work autonomy that nobody should be should have a manager standing on their shoulder saying this is how you do the work, right? What he says is we've mistaken autonomy to being autonomy on workflow and work execution. And he says, autonomy, on the other hand, should be limited to work execution, which means that if I'm designing a screen, I don't need my manager to tell me, Oh, use this color or round your button this way. I'll handle that. Thank you very much. But what the team leader needs to do is define the workflow, which is what are the steps that any piece of work goes through from starting to end. And then I know that when a piece of work comes into my bucket, that's when I need to bother about it. Otherwise, what happens is everyone is bothering about everything and you have what he calls the hyperactive hive mind. Writing down the process. For example, this particular team that I'm on right now, the first thing I did was I wrote down the ways of working? I wrote down a delivery process. I got everyone to agree on it. It wasn't top down, but I at least took the first stab at writing everything up right. Now do I write everything up from scratch on every team that I lead? No, I've got a set of templates that I just keep reusing and then I modify them to purpose depending on the team, right? So I did that, but the time that I spent right at the beginning, getting everyone on the same page resulted in, you won't believe it, Peter, four development cycles. And we've delivered 31 projects during that time.
Wow. Just a little bit more time spent on the context of refinement.
Yeah. How do we work and what's our process, right? So that's one part of it. The other part of it is skills, right? And you mentioned this at the start, and I think there are some key skills that we cannot ignore if you want to be a distributed organization or a distributed team.
Which are?
So number one, if you want to work asynchronously, and if you want to not have your day consumed with meetings You need to know how to write.
Yes.
Some basic writing skills. You don't need to be a best selling fiction author. You just need to be able to do journalistic writing. Write down the facts in a dry, boring fashion. That's fine, right? But you should be able to do that. The second, there's no point writing if nobody will read. So you have to have the capacity to read what others write. Yes. Okay. And by the way, I'll come to that come to the whole conclusion in a second. Then there's working independently, right? You should be able to take charge of something, work on it independently. If you get stuck, you should be comfortable going down a rabbit hole to learn something, to struggle with it for a while before you ask for help. And sure, if you really are struggling, you can ask for help, but that should be something that you do when you feel like you're at a dead end, right? And you should be able to take something to conclusion. It also means that you own decisions, right? Some decisions will be wrong. Some decisions will be right, but you take that in your stride.
Yes.
And the last thing is distraction blocking. One of the reasons why we work remotely is because we get the ability to focus, but it doesn't come for free, right? There's Facebook on the side.
That's the hardest part, or at least for me, but yeah.
Yeah. So how do you keep yourself from looking at chat, looking at instant, looking at email, looking at LinkedIn, all of that. And the good thing is none of these are skills you cannot learn, there are tools to help you with everything you can write better these days with the help of generative AI. You can give your initial text to generative AI and say, simplify it for me. So that others can read it easy. You can take some texts that somebody else has written, give it to generative AI and say, can you just give me a gist and sum up? Yeah.
So you can get better at it.
You can practice 10 minutes of reading every day and improve your own comprehension skills. YOu can start using those comprehension skills to learn things by yourself to help you when you're stuck. And then, of course, there are tools like Freedom. I use Freedom all the time so that I'm not distracted with all of these tools that are out there to capture my attention when I'm focusing. So there are tools to help you with that. But those four skills are essential. And you want to at least have a critical mass. So when I say critical mass, what do at least 25 percent of your people need to be adept with those skills. Then they'll be the role models for everyone else.
So you believe in, I like it by the way, you believe in the fact that people can learn that's for sure. And and also people can learn proactivity from others so they can be mentored. Yeah.
And I believe it starts with leadership. You have to be the change you wish to see in the world.
Also, by the way, in terms of focus, just a quick Response you said is that first about, for example, the do your own research. I don't know it's 20 years ago when I had when I had an agency in office, everything. But I had a saying that Google first, ask second, and that's like the autonomy that I always wanted to have in the team so they can, just use Google first to answer any kind of question for themselves. I think that's a good habit to have anyway. Now I think I would say that as the AI first and then ask me whatever. Also on the on the focus side, I think how you set up the communication channels, that's also super important.
Designs.
It is, it's by design, an intentional design on how you communicate with each other. And I think whatever you do in terms of that design, the one and only advice that I can give to you, always design communication channels and collaboration workflows by keeping in mind that your number one goal is to reduce friction and distraction.
Yeah.
And increase focus, because if you discuss everything on Slack, don't get surprised that most of the discussions will lost in the dark history of Slack chat messages. So you just need to, design the workflows based on intentional.
And you need to be cautious about Slack, man, because the thing is if you're trying to discuss stuff on Slack, then you're in a bad place already because something in that case, you might as well get onto a meeting because the same thing that can be a 10 minute conversation becomes a full day meeting on Slack. One person pings, then another person pings back, then another person pings back, and this is going on for five hours in the day. If that's happening, just get onto a meeting.
Yes totally. When to get to the meeting? That's also a big question. So I think one of the other big questions that I always get that, okay, you are teaching how to do asynchronous stuff and whatever, but there is a value in the meeting. Oh, I see. So when one should have a meeting? What are the best use cases that you think?
That's a balance question, right? Asynchronous is good when you're not under time pressure. For example, there's a big escalation from a client or let's say there's a production issue which you need to solve immediately. Do you really want to go through the slowness of async at that time, or do you want to douse the fire? And if you want to douse the fire, asynchronous won't work. At that time, you need to get all hands on deck and you need to solve the problem. So if speed is a consideration, go for sync. If a breadth of topics, like right now, you and I are going back and forth very fast on a broad range of topics. If that's the kind of discussion you want to have. By all means, go sync, right? The other thing is, there is some value to you seeing my facial expressions and I seeing that you're nodding and you're understanding what I'm saying. And there's a level of connectedness you get from that, right? So you want to build connectedness? Do it. We meet in our team, I do one on ones with everyone. And the reason I do those one on one video calls is because that helps me build my connectedness with my team, right? Yeah, I would say those are the kinds of places that you should continue to do your synchronous meetings. And then there are some of those thorny decisions, right? You've done all of the information gathering asynchronously, but now you believe that you want to just get people together and feel comfortable with the decision. You have all the information. You need one last round of to and fro debate. Around all of that information to make the decision, go for the meeting, no problem, just make sure you record your decision for everyone's benefit because everyone's not going to attend that meeting.
Of course, let's these are all good tips. Let's talk about the performance, for example. I think it's totally different tracking performance when you work 100 percent sync. Because that. If you do most of your work synced, it means that it's hard to track a little bit. It's hard to track a synced conversation. It's hard to track a synced workflow. I do believe that if you do have asynchronous workflows installed in the workplace, tracking performance will get a little bit easier because everything just, it's on the cloud written up and that's it. Yeah, so how an async manager should track performance. What do you think what is performance? Anyway, I think that's even a better question.
Yeah, and you know in software development, it's a bit tricky because It's rather difficult to measure the productivity of an individual developer, because many of the standard metrics of performance aren't really that great. Like, how do you measure a developer's productivity? Do you measure it by lines of code? Because I could write far more elegant code with less lines, right? And then that wouldn't be the measure of performance. Then what do you measure it by? Do you measure it by business outcomes? Business outcomes aren't within my control, right?
Of course.
Now, what I have realized after many years that performance discussions are finally conversations, right? But those conversations need to be on the basis of certain pre agreed goals. One of the ways I do, and I'd love to hear what you do with, people you're coaching and mentoring and that kind of thing, what I do is right at the start of any performance cycle, we discuss, okay, what are we going to try and achieve? Now, some of this doesn't need to be, imagined every cycle, right? I know what a good developer should be doing, they should have a certain level of coverage, they should be out there designing their code in a certain way, et cetera, et cetera, right? So those are standard expectations for any developer. But then there might be certain responsibilities that you're taking up for the project, which is to say that I will own this feature end to end. Great. Let's put that in your performance expectations. I will lead this community for the client end to end. Cool. Let's put that in your performance expectations. Now there's another part of it, which is what support are you going to need? Because you can't just have performance expectations and say, the company and the team is not going to support you in any way. So you write that down. And then the question is tracking how somebody is doing week on those goals, right? So that's where the one on ones come in, which is to say, okay, how are we doing on these goals? What help do you need? How can I support you? Do we need to change anything? And you do that enough week on week on week. And you have enough coaching opportunities. Six months down the line, when you're doing a performance review, none of this is going to be a surprise, right? The person who you're appraising knows what their performance has been like. They know what support they've got and nothing that you write is ever going to be a surprise. So there is a little bit of synchronicity, a little bit of asynchronicity, but we need to also understand that. In software development, gauging performance isn't really the easiest thing to do given how many variables there tend to be.
Yes, totally. And also, by the way, the time frame is totally matters. I don't think that short term performance should be or can be tracked anyway. I know it's like controversial to say, but still most of the performance metrics that we tend to use should reflect long term goals. And by the way, most of them should be tracked on the team level because everyone needs everything. It's really hard to achieve some sort of like a performance on their own without helping each other. It's a, come on, A workplace is a group of people working together to the same goals. Why would you want to break that down into individual level and so on. By the way, how I do that, so I'm coming a little bit more like from a science background. I studied sociology a lot and stuff in the uni. And in most of the stuff that they do is that they have a hypothesis and they test that hypothesis later on is it working? Is it not working? It's the same in the business world. So you should have a goal. This is the hypothesis that you have. You should have the goal for every individual and test all the time. If they are meeting that goal, if they are meeting that goal it means that the performance is great. But again sometimes the variables are too many and too much. And you sometimes forget that, it's a team effort to create something really unique, but certainly it's not the output that you want to track, as you said for example for coders, like how much line do you write, Jesus I honestly hope that no one tracks that at any companies. Let's talk a little bit about a little bit about and maybe that should be the one of the last questions because you're time restrained a little bit. Sorry how should one start? What should be the first steps if you are Currently working mostly synchronously and you want to do a little bit more Asynchronous work. What would be the first steps that you need to take?
Yeah, I'll say, let's add a step zero and recognize that you can't do this alone because if you're working in a team, it becomes very difficult if you're the only person who wants to work asynchronously and everyone else is working a different way, you'll stick out like a sore thumb, right?
Of course.
Yeah, can't do this alone. You need the network effect. Now, the network effect where I would start is working with your team to figure out Yeah. Okay. We want to go async. What is the value we are seeking to get? Are we seeking to improve how diverse we are as a team? Are we trying to get more time for deep work? Do we want to make knowledge sharing onboarding easier etc. So figure out what is it that you want to get better at. And then what I always recommend is to do a little bit of a baseline in terms of your maturity at any of these practices. So I have a very simple, straightforward survey that helps you gauge maturity for a software development team, right? And you can get a sense of what does elite look like and what might you look like and where do you have a gap? Now, remember, we said we want to look at what is the specific value that we want to get, right? If you want to improve onboarding. Then you start looking at the gaps in onboarding and you start fixing those things first, right? If you want to make more time for deep work, then you look at what is stopping you from getting that extra time for deep work and you fix those things first. And I would say once you, the reason why I say connect it back to value is because that's where you will see most payoff and that's what will make you happiest as a team. Once you finish that, there is no end to improvements. There's the long tail of improvements and you can make that for the next 10 years, if you like, but focus on the value and address those areas first. And if I could add a bonus for team leaders, I would say your job is to be in service of the team. And being in service of the team means that you focus on team design which is that when it comes to writing things up, say, all right, I'm going to write down how we make decisions. You take the onus of doing that, right? So that you create the document, float it amongst people. Does everyone agree? Great decision made. You need to decide the workflow. Take the onus of doing it. Take the first step. Be ready for criticism, right? Be ready for people to push back, give you feedback. If people are pushing back, that's a good thing because they finally, yes. Because if people are not saying anything, that means they don't care. And so that's the responsibility of the leader, that you take that step to design, right? Based on whatever value that you're seeking. So that's what I would say. Figure out the value. Figure out the gaps and then start making changes that change the value that make change in the direction of the value that you are seeking.
Perfect. And you cannot start alone. Meaning if someone wants to get a helping hand, where can A find you, B the book is coming out. Not sure when, but you will tell me where can people purchase it and get it? Okay, so I have news. We are talking right now in September. So yes, the book releases in the US on 21st of September. Nice. And there's going to be a special discount code for all the listeners of this podcast, you can use the coupon code anywhere and we can share the link to order it from so regardless of where you are in the world, you can get the ebook at a massive discount. And if you're in the US, you get the book at a discount with free shipping, right? And then there are different release dates for different parts of the world. So India, it releases a few months after and then the UK and then Europe, et cetera, et cetera. But the first release happens in the U S on 21st of September, if you have to reach me, I'm on LinkedIn. Just search for my first name and last name, or you can reach out to me on asyncagile. org.
Perfect. Are you planning by super congratulations on the book, by the way, I gave an official testimony or something to the book. So rooting really for you. Are you planning to release it in different languages maybe later on?
At some point, at some point. Yeah. So I think English is a safe language to start with, but I'd love to do like a Spanish version at some point.
If you are listening to this show again, this show has been recorded on the middle of September, but probably we'll go live middle of October by that time the book will be live please visit anywhere. consulting for the podcast or just for the podcast, anywhere. show. There will be a a special URL for this episode. And within that, that post, there will be links to the. to The book where you can get with a discount and also links to Sumeet and the AgileAsync. org. Again, thank you. Thank you. It was a blast. I love that you come thank you for your time. And it was so great meeting with you finally.
It was great talking to you, Peter. Thanks for having me.
