Distributed Teams with Johanna Rothman

Brett Harned:       Hey, welcome to Time Limit. Today my guest is Johanna Rothman. Johanna is a consultant and coach, and you may know her as the pragmatic manager. Or maybe you've read one of her many books, which range in topics from management, to Agile, to hiring, and so much more. Well, I invited her on Time Limit to talk about a topic that I think is really important to a lot of professionals these days, and it's distributed project management, or remote project management. You know that thing where you work in one spot and your teammates work in other spaces? It's that. And there's a lot to it. And Johanna actually explains how to define your team in the interview itself.

Brett Harned:       We also talk about her book, From Chaos to Successful Distributed Agile Teams, Collaborate to Deliver. But if you're sitting there thinking, I'm not Agile, that's okay. I think you'll find this interview is full of helpful and practical advice to manage remote teams, regardless of your methodology. After all, the challenges aren't about process as much as they're about people and communications. And we'll dig into that, too. So check it out.

Brett Harned:       Johanna, welcome to Time Limit. Thank you so much for joining me. How are you doing today?

Johanna Rothman:    I'm doing very well, thank you, and I'm so delighted to be here.

Brett Harned:       Awesome. Well, I'm really excited to speak with you. I think our audience should know that you've written several books, which they can find on your website, I'm sure they're on Amazon as well, but we'll have a link in our show notes so that they can check all of that out. Those books and topics are really helpful for project managers, and I think even more generally leaders. But I think the one book of yours that I want to focus in on today is From Chaos to Successful Distributed Agile Teams, Collaborate to Deliver, which you wrote with Mark [inaudible 00:01:54], right?

Johanna Rothman:    Yes. We wrote it as a distributed Agile team.

Brett Harned:       Yeah. So you told me a little bit about that, but I was hoping maybe you could talk a little bit about kind of the impetus for the book, or why you two decided to write it.

Johanna Rothman:    So, I was in Agile, I think... It must've been 2017. Going to the last session on Friday morning, and I saw Mark, and I've known Mark for many years, and I said, "Did you see anything interesting about distributed Agile teams here? Or is it all the same old same old, which is don't do it?" Which is really not very helpful. He said, "No, I haven't seen anything about it." I said, "Well, I've been working as a remote coach. I have all of my executive clients are remote for me. I don't do any work with them on site. I would like to write a book about distributed Agile teams. Would you like to write one with me?" He said, "Yes."

Johanna Rothman:    The way he says it is he hesitated for about a nanosecond. I actually think he hesitated just a little longer. Because we had not written together. We had never. So this is a really, really big ask. I said, "I have a lot of experience, some of which is quite negative. And you have a lot of experience, which is mostly positive. So if we can bring all of that experience together, we can then explain to people when this works and when this doesn't."

Brett Harned:       Absolutely. That makes sense. Having the experience and knowing that it's a topic that basically the entire workforce at this point is related to. Everyone's going Agile, or trying to go Agile, and a lot of companies are trying to go distributed or remote. So it makes sense, in terms of a topic. I know at TeamGantt we're actually distributed, so we have some folks in our office and headquartered in Baltimore, and then everyone else is kind of all over the country. So it's a hot topic for us and it's something that we really like to talk about.

Brett Harned:       But I kind of want to dig into the book a little bit, and kind of talk about some themes around it. The first chapter is titled, Distributed Agile Teams Are Here To Stay. I'd even go as far to say that distributed teams are here to stay, and I think you're probably implying that. But if it's okay with you, I'd like to talk about Agile teams, but more generally I kind of want to talk about just managing remote teams as well. Managing distributed teams. Does that work for you?

Johanna Rothman:    Oh yeah, yeah.

Brett Harned:       Okay. Let's start at the top. So one thing that I notice is that there's actually a lot of language around this topic that I want to clarify, because I even feel like myself I'm using them interchangeably and probably in the wrong way. You've probably noticed that already. But can you talk about the difference in the terms or the things that our listeners should know? For instance, what's the difference between distributed, remote, and co-located?

Johanna Rothman:    Okay, so let me start with co-located. Co-located teams all affiliate around one purpose, and they are physically inside of 30 meters. So most of our listeners are actually not in co-located teams. They're all in one building, they might be on one campus. They have remote people from each other. Not everybody is literally co-located. So when Mark and I were doing the research for the book, I actually came across the Allen curve, and it's really... 30 meters is the absolute outside for a co-located team. I know, I know.

Brett Harned:       I didn't realize that.

Johanna Rothman:    It's just kind of funny. So it turns out that if you are not willing to stand up and walk over to a person to ask a question, because you perceive that the cost of asking a question is too high, you are probably not in a co-located team. Back when the Agile movement started, we had all this thing about team rooms, which was wonderful. Everyone would get inside of one room, we were shoulder to shoulder, we could pair, we could mob, we could swarm, we could do whatever it is we needed to do as a team. Let me just say, I think none of my clients ever implemented a team room. I would say, "This is a great idea," and they would say, "Yeah. Go ahead. Yeah. You can have that as a great idea for somebody else, not for us."

Brett Harned:       Sorry to interrupt you, is that because there's no space, or they just didn't want, culturally it was something that felt not right?

Johanna Rothman:    It was a combination of we don't have space for a team of people. Where would they sit? In a conference room? That's not a good answer. We need conference rooms. I would say, "Well, if they were all sitting together, do you really need any more conference rooms?" Well, yes, they did. Okay. And then, I have a lot to say about architects who design space in corporate offices, none of which is particularly lovely. I am only five feet tall on an extremely good day. So the cubicles are often 5'3" or 5'4", so nobody sees me coming. And if the cubicles are lower, then the noise is even higher. So you have the worst of all possible worlds inside an office with cubicles. This large, open area with cubicles, it saves the company a ton of money in terms of space per person, and it's quite bad for collaboration and teamwork.

Johanna Rothman:    Okay, so if your entire team is within 30 meters, it's cross functional, you have all the people you need to do the job, you affiliate around one person or goal, that's a co-located team. Now, distributed comes in several forms. When you have a distributed team, at least one person is remote from the other people. I don't like to talk about remote teams. I don't actually understand what that is. But if we think about, one person is not co-located with everybody else. That one person is remote. You now have a distributed team.

Johanna Rothman:    Yeah. And then there are several kinds of distributed teams. When I first started working with distributed teams, there were be the bulk of the team in one location and one person off here and one person over there. That's a satellite team. Then there's the cluster team, where you have two or three people in one location, this is often developers, because I'm a software person, developers in one location, testers in another, the requirements person, the product person in the other third area. And you might all be in the same physical building, but you are not co-located.

Brett Harned:       Right, you're farther than that 30 meters.

Johanna Rothman:    Right. And so then there's the dispersed team, where everybody is remote from everybody else.

Brett Harned:       Okay. So that's completely, everyone's working from home.

Johanna Rothman:    Yeah, or working from some location that is not even close, necessarily to any other location. Everyone is in their own unique location.

Brett Harned:       Got it. You can slice this so many ways, I can tell.

Johanna Rothman:    Yeah. So we offer this way of thinking about the teams as co-located, everyone inside 30 meters, satellite with the bulk of people in one location and a couple of people remote, or at least one person remote. Cluster, several people in several locations. There are two or three co-located here, two or three co-located there, et cetera, and then the nebula, which is dispersed.

Brett Harned:       Okay, got it. So dispersed, satellite, cluster, nebula, all new terms to me, but all completely makes sense because there are so many different ways that you can structure a team location-wise.

Johanna Rothman:    Yeah. You can even have a nebula team in one physical building if everybody is on different floors, or separated.

Brett Harned:       Yeah, I can think of examples of all of those, whether they're case studies I've read, or teams that I've worked with who were in all various different set ups. I'm wondering, do you have a preference for any of them? Do you think there are advantages to any set up versus another?

Johanna Rothman:    Yeah, I really like the nebula. Mostly because we are human. Out of sight, out of mind. The satellite team, I wish I could say I'm such a great person, I never forget the people on my team. No. They're not there. I forget about them. So if everybody is remote, if everybody is dispersed, then nobody has in a sense the advantage over anybody else. There's no headquarters in other, there's no way of forgetting about people if you don't have all the people on... We happen to be using Skype, we could use Zoom, whatever it is we choose to use. If everybody is not on the same meeting tool, we don't have our entire team there. I actually prefer the nebula because it makes me go through, oh, do we have Andy? Do we have Brenda? Do we have Cindy? Do we have Danny? Do we have, right? Let me go through all the people on the team and make sure they are all there before I get started.

Brett Harned:       Yeah. So the nebula pretty much puts everyone in the same exact situation, in that they're in their own location and there's no feeling of the core team and then the people who are on the fringe, kind of thing. I know I've been in work situations where we had two offices, and the second office was determined the second office because they were brought in, that team was onboarded, merged with the company. So that team ended up feeling like it was us versus them, and that was never a great feeling. So you start to see the effects on culture, right?

Johanna Rothman:    Oh, yeah.

Brett Harned:       Absolutely. What are your thoughts on benefits, just in general of managing distributed teams?

Johanna Rothman:    There's several benefits for the manager. Let me start there. You might be a literal people manager, you might be a project manager, scrum master, facilitator for a team, but the nice thing about people being away from you is that you cannot micromanage them. That actually frees you up as a manager to go and do the stuff you need to do.

Brett Harned:       Wow, what a great point.

Johanna Rothman:    Yeah. I think that people forget about that. Yeah. It's not that they mean to micromanage, but they can not micromanage. And then, for the people on the team, aside from the benefit of not being micromanaged, that's actually a big benefit. The team gets to figure out, how do we work as a team? Now, I happen to think that every team needs facilitation help to understand how to work together. I have not been a part of too many teams that just came together all by themselves. No, no, no, they needed to do some, the forming, storming, norming business, and they might need some facilitation, especially if they're going to try and be an Agile team.

Johanna Rothman:    So I find that a facilitator of some sort is really helpful. But that means when everyone is dispersed, everyone has to use the same tools, and if you don't have all the same tools, you don't really have a team. Then you have what you talked about before, which is the insiders and outsiders. All that stuff is quite bad when you don't have equalness. Equalness is close enough to a term.

Brett Harned:       When you mention facilitators, I just want to be clear on that, is that for you a scrum master or a project manager, or someone on that level, or is it someone who's even outside of the core team?

Johanna Rothman:    I really like it when an Agile project manager or a scrum master takes that on. For me, that's really important.

Brett Harned:       Same. Okay. Good, I just wanted to make sure. Because there are different points of view on that, but I think a lot of organizations probably wouldn't even consider that because, an outside facilitator to pull a team together. But what about with-

Johanna Rothman:    That might be nice for a retrospective-

Brett Harned:       Absolutely.

Johanna Rothman:    But I think that for the day to day work of a team, no, you need somebody who understands. What does the environment need from this team to deliver? Let's focus on that deliverable.

Brett Harned:       Yup. Okay. Well, so what about Agile teams specifically? Are there any different benefits for distributed Agile teams, other than kind of what you've mentioned so far?

Johanna Rothman:    I think it's harder and it's easier at the same time for a distributed Agile team. Let me talk about the harder first. In a co-located team, and I'm talking about inside of 30 meters, preferably inside of eight or 12 meters, people can turn around, they can look at each other. You can see if my head's down and busy. You can see if I'm sitting back in my chair thinking. And you know, based on what you know of me, whether or not I'm interruptible. You have all kinds of visual and audio cues that you don't have when you're remote from people. The reason I like Agile distributed teams is because of the focus on collaboration. How do we as a team finish this next small chunk of work? So it's the Agileness that makes the team move, you can't see my hands. You might hear it. That help the team really move through the work. I find that that's... I don't remember the last time I did not work in an Agile way. So that's partly my prejudice.

Johanna Rothman:    I know that back in the early '00s, I tended to use something that looked like scrum. Even before then I used iterative and incremental approaches, never waterfall. I think once I discovered personal [inaudible 00:18:16], I realized that I actually work in flow with a cadence of planning and a cadence of retrospectives.

Brett Harned:       Okay. That makes sense. While we're kind of on the Agile topic, I guess I'm kind of gathering that when it comes to Agile, the focus on the principles is really critical for our team, no matter where you're located. But getting that kind of buy in I know can be really difficult when you're located. It's all in one spot. Is it tough to get that buy in with distributed teams?

Johanna Rothman:    Yes and no. My experience is it's more difficult to get a buy in for a video always on than it is for almost anything else. We happen to be recording this with just audio because of the limitations of the tool. If we had turned on video, our computers might say, "Oh, let's be a memory hog." So we are using audio only for our recording for a specific reason. But often in the workplace people have excellent internet access. They're not working on whatever it is I have at home, which is pretty good, but not the same as where most people work. What I find is if you leave your video on, you are much more likely to understand, or allow people to understand you, and you can understand them.

Johanna Rothman:    In a co-located team, even in a team where we might not be co-located but we're all at the same place, there's always video on. People can go walk over. It might not be easy, but we can walk over. My experience is, it's not so much that the Agile part is a challenge, although there are plenty of Agile challenges. It's the video that's a huge challenge.

Brett Harned:       Yeah. I guess the video kind of, to me in some way, it's a communication challenge. It's setting the expectation that the way that we communicate is via video, not just voice. But I also think that if we dig into some tactics a little bit, communication on distributed teams is really important, but it also can be kind of difficult. Especially as a team lead or a project manager, if you're working with new team members, people are being onboarded, some people are working in really large organizations where there's kind of just an unlimited number of resources and people that can be pulled into teams, so it can be a little bit more difficult if you're remote, or distributed, to kind of get to know people from afar. I'm wondering, do you have any suggestions for building relationships, solid communications, trust? Anything around that that people can kind of hone in on or zero in on to get better?

Johanna Rothman:    Well, I think the first thing is to assume good intention, which is one of the principles in the book. I think another piece is if you are a leader in your team, why are you not pairing with a new person? I am a huge proponent of the buddy system. So if you have a new person starting in your team, you might need a buddy system with an existing team member and the new team member. This does not have to be a senior junior relationship. It can be a peer relationship, but why would you not ask a person who already understands how the team does it's work to work with a new person? And if you are a facilitator, leader, Agile project manager, something like that, why would you not have a one on one with everybody on your team?

Johanna Rothman:    Now, there's the issue of a people manager one on one, and if you are an Agile project manager and you also have one on ones, that's maybe not the right thing. There's a limit to the amount of one on one's any person should be expected to have. And I freely admit that. However, if you are the facilitator of a team and you are not doing some kind of team based learning every week, I wonder about that.

Brett Harned:       What do you mean by team based learning?

Johanna Rothman:    Back when I was a dev manager and a task manager, I facilitated a weekly meeting. We had a team meeting. We were not the team, we were actually a group, but we had a meeting every week where we learned something together. You can think of that as a community of practice, because we were all one function. However, in a cross functional team, like I'm expecting these Agile teams to be, why would you not learn as a team something every week? Go ahead, it sounds like I interrupted you.

Brett Harned:       No, no, I was just going to say, so is that through a retrospective? Is that kind of what you're getting at there?

Johanna Rothman:    I think of this as different from a retrospective. I am one of those wacko people, I will freely admit this. In my experience, technical people who focus on one project at a time, who work with a team who are collaborative can only get about maybe five and a half or six hours of technical work done a day. We fool ourselves into thinking it's an eight hour day.

Brett Harned:       It's so true.

Johanna Rothman:    We can do email. We have to go eat lunch. We need break during the day. We have more email. We have meetings. So if a team has done five or six hours of intensive, collaborative, focused work during that day, they have done more than their fair share of work. And what I find is that if you say to the team, "What do we need to learn for either next week, or next sprint, or this set of features that are coming up? Do we need to understand something about some part of the architecture, some part of the database, some part of something?" They will say, "Oh, yes. We really need Fred over there, because Fred has been doing this for years and years. Fred is now 64 and is ready to go to Fiji for a rum punch drink."

Brett Harned:       I want to be Fred.

Johanna Rothman:    Yeah. Yeah I kind of would like to too. And if we don't get Fred now, we are not going to be able to do that. One of the things I've seen in organizations is that as a result of all those waterfall years, we have all these experts in the organization. The team, this cross functional collaborative team, needs help from those experts. The way I like to do this help is when the experts come and say, "Here's a brain dump of 20 minutes of everything I know." You cannot absorb more than 20 minutes at a time.

Johanna Rothman:    So if you think of the kinds of things an Agile team does, the team plans a little bit for the next chunk of time or the next bit of work, that's getting the stories ready in the backlog. They start to do the work, they recommit to each other, they walk the board, they do something about checking in with each other fairly often, at least once a day, if not more often. They might prepare some stories for the next chunk of work, depending on how they do that. They always have a demo and a retrospective on a regular cadence.

Johanna Rothman:    If we think about the kinds of things that the team needs to learn, you might say in a given retrospective, what kinds of learning do you want us to plan for for the next week or two? That's different than what one thing do we want to improve on for the next week or two? This also gives the team a break from feeling like they're a feature factory. One of the many problems in the Agile community right now is that project owners finally get stuff out of the team so they treat the team as if the team is a feature factory. Feature, feature, feature, feature. Yeah, that does not work. The team might say, as part of the retrospective, "We are not doing enough infrastructure work to support our future development. That's one thing we want to work on." And they might decide that they want to learn faster ways to do it. And that team over there seems to understand faster ways to do it. Can we get some of those people to talk to us?

Brett Harned:       Mm-hmm (affirmative). Okay. What about communication on a day to day basis? Things that are not kind of structured. I'm not talking about pairing or one on one's or full team check-ins or team learning. What about, do you have any tips around best practices for how you should set an expectation or structure for how the team communicates?

Johanna Rothman:    So one of the things I really like is a dedicated team back channel that's text based. I am a member of many Slack communities, you might say possibly too many Slack communities.

Brett Harned:       Absolutely. Same here.

Johanna Rothman:    Yeah. Yeah. And I value the learning from it, but I'm not part of any... I am part of several teams, but not in the same way as when I would work in an organization. What I find, and I'm using Slack as an example, not that Slack is the best, it's just a useful thing right now. I think that my husband used a Microsoft Teams thing.

Brett Harned:       Sure. Yeah, they have a chat platform.

Johanna Rothman:    Yeah. Okay. But it's a dedicated chat back channel for this team. So if I discover something interesting, I could put a message on this chat back channel and say, "I just discovered this, blah, blah, blah, blah, blah. Did anybody else know that? Did I somehow miss it?" And then all the other people might say, "Yes, JR, you did miss it. And here's on our project wiki where we had talked about it a year ago when maybe you were on vacation," because they were giving me the benefit of the doubt.

Johanna Rothman:    This is the kind of thing. Or they might say, "Oh, no, that's really interesting. We did not think of it that way. We did not understand it to be that way. Let's address this as a team, either in a Kizen, in a little 20 or 30 minute retrospective today at 4:00, or let's put this on the list for our next retrospective. Thanks for finding it." So the business of the back channel is we can tell each other what's going on. "JR, did you remember our meeting?" "Oh, yeah, yeah, yeah." Did we learn something? Did we see something that's a little suspect? All this stuff. This is where the more we have ways to communicate that are not specifically in real time but allow people to catch up, the easier it is for all of us to actually understand what's going on. So the text back channel is mandatory for all distributed teams. And I don't even care if they don't have enough hours of overlap. If you have people who are not located with you, you need to somehow have a way that everybody can see this particular set of conversations.

Brett Harned:       Yeah. I agree.

Johanna Rothman:    That does not require email. Yeah.

Brett Harned:       I even think that, I've been in organizations where everyone's in one building, in one small office, and there's still a lot of communication through Slack. And at TeamGantt we use Slack, and I think we use it in a pretty amazing way. The reason I say that is because I've worked in organizations where there's constant flow of chatter in Slack that is not useful and can be distracting. TeamGantt, we use it in a way that you're not bothering someone. You're giving people the productive time and space to get the work done that they need to get done, and you recognize that if you're asking a question, you might not get an immediate response because you're respecting that time and space.

Brett Harned:       At the same time, I think that it's nuanced. It's a challenge. Communication when you're all in different places, and sometimes things get heated and you need an immediate response, it's hard to figure that stuff out. But I do think that even though it's riddled with some challenges, I think it's probably having that kind of what you call a back channel absolutely is necessary.

Johanna Rothman:    Oh, yeah. And then the teams all need to be able to have full access to all the tools that everybody on the team needs. If you have developers, they need to have access to the code, so do the testers. The testers need to have access to the testal, so do the developers. And everybody needs full access to the meeting tool, everybody needs to be able to start audio and video, and everybody has to be able to use all of the same tools.

Johanna Rothman:    A long time ago, and I really hope that this is not the case anymore, although some of my colleagues tell me it is, a manager, a well meaning manager who really wanted to manage the cost of the tools said, "Well, since we're offset by many hours, your job at the end of the day is to relinquish your license to this particular tool. And then the next person could take the license." Yeah, yeah. That lasted about three days before somebody left the building and forgot to relinquish their license, and all the people who were to the west of them said, "What are we, chopped liver?" Yeah. So don't skimp on licenses for tools. They're so cheap these days.

Brett Harned:       Yeah. I wish you could see the look on my face right now as I'm nodding no. That just doesn't make any sense at all, especially with a remote team. But when you're in person... It's just a bad thing, no matter what.

Johanna Rothman:    It's a bad thing.

Brett Harned:       It's a bad decision. But you see those things often in your career, right? I want to talk for a minute about collaboration, because collaboration is huge, as you well know, in Agile projects. Also a really kind of a hot topic among just other non-traditional projects or non-Agile projects. When you're all in one office, people rely on things like war rooms and whiteboards and meeting space and conference rooms. A lot that's done in person. And collaboration is done really well in person. I can't tell you how many amazing brainstorming meetings I've been in with full teams where we're sketching ideas that turn into a product really quickly. And I'm curious if you've got any recommendations for how you do that kind of high touch collaboration in a distributed way?

Johanna Rothman:    So the first thing is to turn on video, and the second thing is to have a document in something that everybody has access to. One document. I wish I could tell you I had a really good suggestion for a whiteboard tool. I do not. However, I have had several good results with Google Docs, and again, Docs does not work for every single organization. So choose the right tool that fits your security. But find one place where everybody can contribute to the document in some shape or form. I don't actually care what that is, as long as everybody can contribute to it. That's really the big thing.

Brett Harned:       Okay. So I have one more question for you. You know that the title of our show is Time Limit, kind of giving a nod to the fact that we're all busy human beings, professional people, trying to get a lot done with limited time, and sometimes limited resources as well. So given the chat today, I'm curious if you've got any time saving tips for the distributed or remote project manager? Are there things that someone could do to save time and make managing a remote team and projects a little bit easier?

Johanna Rothman:    Yes. I have actually I think three. I'm hoping-

Brett Harned:       Awesome. Love it. Please do.

Johanna Rothman:    Okay. So the first one, never make a distributed or remote meeting longer than 50, five-zero, minutes. Always keep it under an hour. Always. Always, always, always. The reason for that is that people will start to look at their phones, they'll start to look at their email. They're not engaged, so don't do it. If you can keep all your meetings to 30 minutes, that's even better. So yeah, keep the meetings short and sweet.

Brett Harned:       That's a good one.

Johanna Rothman:    Now, the way you do this is you always have small stuff. One of the big problems we have in just the general software community is we envision big products. We have this big idea. We see the big feature sets. And instead of how much can we do, think about how little can we do, and that how little thinking translates into smaller amounts of WIP, work in progress, and shorter cycle times. I would recommend that the team itself, maybe facilitated by this project manager, scrum master, whomever, measure their cycle time and say, "How long on average does it take us to finish something? I don't care what the thing is, how long does it take us?" If we cannot finish one thing in a day, what do we do so we can finish one thing in a day, and work on that problem. That problem will help you finish small chunks of work faster, and you don't have to be Agile to do this.

Brett Harned:       Absolutely not, yeah.

Johanna Rothman:    Right. But it allows you to do work in a way that makes sense. And then my third thing is to work with a product owner or whomever gives you requirements and say, "If you could only have one thing, what would that one thing be?" Because my experience with all these distributed teams is again, we have all these big ideas, we want all this stuff. How do we focus the team on one feature, one feature set, something small so they get stuff done. If you as a project manager could do that for your team, wow, you would be way ahead of the game.

Brett Harned:       Yeah, I think you'd be way ahead of the game. I never thought about this. This is really interesting. I think you'd be way ahead of the game, and I also think that it would help your team to get better on a lot of layers. I can picture your estimation getting better, I can picture the collaboration ramping up and getting better because you're really focused on one challenge or problem or feature, whatever it might be. It feels like, yeah, I really like that. There are a lot of benefits to that one.

Johanna Rothman:    Yeah. And I really like cycle time for estimation, because even if we know it takes us a week to finish something, we know that. So if we're using scrum and a two week sprint, we look at two things. We don't have to look at 15 things.

Brett Harned:       Yeah, there's more focus.

Johanna Rothman:    Yeah.

Brett Harned:       More focus, it's easier to figure out what your role is and what you need to do. What are my marching orders? Really good one. Thank you so much for that. And Thank you so much for joining me on Time Limit. I really appreciate you making the time and scheduling this and really coming through. I think it's been a lot of fun, so thank you.

Johanna Rothman:    Well, thank you. I really enjoyed it.

Brett Harned:       Awesome. Have a great rest of your day.

Johanna Rothman:    You too.

Brett Harned:       All right, folks. That wraps up this episode of Time Limit. I wish I'd continued recording this after we stopped the interview, because that last bit of advice about focusing your teams in smaller chunks really got me. I think there are some pretty serious benefits to think about there. Also, I think my head is still spinning over the several definitions or setups to working remotely. The last thing here is, there are certainly a lot more topics within managing distributed teams that we absolutely couldn't get to in a 30 minute, 40 minute episode. If you've got ideas of practices to share, please get in touch to be a guest on this show. Just email podcast@teamgantt.com, and we can chat. Until then, please share the colleagues, please, and give us a nice review wherever you listen to your podcasts. And come back for episode 26 where we'll explore an up and coming branch of project manager, which is design ops. Thanks.