JOHANNA ROTHMAN is a management consultant for software managers and leaders. She is also the author of many books, most recently Agile and Lean Program Management: Scaling Collaboration Across the Organization. She started working with geographically distributed teams in 1988.
Subscribe to the Collaboration Superpowers Podcast on iTunes or Stitcher.
Her tips for geographically distributed teams:
- Consider working from North to South instead of West to East. Architect your team based on the location of the members.
- Share the burden of time zone differences.
- Use a “time zone bubble chart” to visualize your colleagues time zones.
- Communicate often.
Podcast production by Podcast Monster
Graphic design by Alfred Boland
Original transcript
Lisette: Great, and we’re live. So welcome everybody to this remote interview. My name is Lisette, and I’m interviewing people and companies doing great things remotely. And I’m totally, over-the-top excited today. I have a very special guest, Johanna Rothman. And a lot of people in the audience will already know who she is. So welcome, Johanna. It’s really great to talk to you.
Johanna: Thank you so much. I’m really happy to be here.
Lisette: So let’s start with the first question. Oh, let me actually tell a little bit about you so people have some context. I have you’re a Management Consultant for Software Managers and Leaders, the author of many books. That was a long list of books. Do you have a favorite? Is that like picking one of your [crosstalk – 00:41].
Johanna: [Crosstalk] always my favorite [laughs].
Lisette: And the most recent one is?
Johanna: Agile and Lean Program Management: Scaling Collaboration Across the Organization.
Lisette: Wow! This is going to be great. I also have you’re a software engineer starting in 1977, so you’ve seen the [crosstalk – 01:02] really transform.
Johanna: I have.
Lisette: Exciting, I can’t wait to get into it. But let’s start with the first question, which is what does your virtual office look like? What do you need to get your work done?
Johanna: I work alone, Rothman Consulting Group Inc. is a one-person company by design. So I have high-speed Internet. I have my library back there. I have everything I need on my computer. And I also use a number of virtual… Are they virtual tools? Well, they’re real tools, but they help me work virtually. Maybe that’s a better [crosstalk – 01:44]. I also use Zoom. I use Skype, although I’m using it less and less. I use Google Docs. I use Subversion. That’s how you can manage version control of sources and whatever. I have a whole bunch of other applications that I use. But I always want to make sure I’m working on what’s the most up-to-date between the other person and me, or the other people and me, and that I know where everything is. So that’s what I use.
Lisette: I want to ask about working alone because I personally love working on my own. And many people have an issue with it. What is the decision of working on your own?
Johanna: I decided to become a management consultant over 20 years ago. It’s been a long time. I think it was 1994. And what I was realizing then is that the speed at which I wanted to change was too fast for my companies. But that’s a great thing in a consultant. Even if the company doesn’t want it for an internal person, they want it for an external person. So I can go into a little bit of work. I let them catch up to where I think they need to be. I can coach them. I can do anything else. But I’m not there day in and day out irritating them. But instead, I’m helping them. So there’s a very big difference between irritating and helping. And in this way, [unintelligible – 03:29] help. They get to go at whatever pace they can go. I can make suggestions if they want. It’s a very, very different approach to being in there and saying let’s do this today because I’m not ready today.
Lisette: Right, right, so the timing is a little bit more… You can be a little bit more flexible in the timing of things. Tell us a little bit about what you are doing. Management consulting for software managers and leaders, what does that mean?
Johanna: If you have a problem in your software product development, I’m the person you should call. Sometimes it’s about the projects. Sometimes it’s about the management. Sometimes it’s about the project portfolio. Sometimes it’s about my doing the right kind of work in my company. So it’s not just managers who need this. Sometimes these people are called technical leads or leaders or chief idea officers. They’re called any number of things. So I think it’s really important that people say, “I have this kind of a problem. Johanna can help. It doesn’t matter [what – 04:43] I’m called.” I work with people to get their products out the door. So if it’s anything that prevents you from getting products out the door, that’s why you will call me.
Lisette: And what about your work on distributed teams? When did that start?
Johanna: Actually, in 1988. I was running – I believe it was called – the Continuing Engineering Group, in the company I worked for. So I had the test group and this Continuing Engineering Group. And we had continuing engineering in customer support all over the world. We were based on Cambridge, Massachusetts. That was my commute just down the road. But I had to talk to people in Germany, in Japan, in California, in France. Where else did we have sites? I don’t remember. I think that those were the main sites. And one of the problems is this is way before TCP/IP became the industry standard for [crosstalk – 05:55], for transferring information. So everybody had their own networking applications. We had [unintelligible – 06:03] transfers. We still had all the problems with the time zone differences. And I wrote an article a number of years about complementary practices with geographically distributed teams, because when the Germans said, “We have this problem, and we need it fixed,” that meant we needed it fixed now, not a day or two away from now. We’ve already spent two weeks with the customer. We need you to look at this now. Get this to fix in the next two hours so it’s there on our desk in the morning when we come in. Well, that’s not how I was managing the continuing engineering department. So I had to talk to them and say, “What does now mean?” And we had a stage that a bug, a defect went through. So it was in progress, and then it was in review and in verification, and then ready for distribution or whatever it was. And they did not understand why we had four or five separate stages. And it all went back to the culture that they were thinking about. And I had to get them to say, “We have this problem. It might be coming over to you in a week because otherwise, I could not address their need for getting a fix-out right away. So I had people in Cambridge working across the pond with people in Germany. And that was quite interesting.
Lisette: Especially in 1988 when we didn’t have all these great tools for connection.
Johanna: No, we had the phone and we had email.
Lisette: Sounds painful [laughs].
Johanna: It was. It was horrible. We finally figured it out. But it was not easy. [unintelligible – 08:02].
Lisette: It sounds like in addition to of course the tooling not being there and the technology not being there, one of the major things that also wasn’t there is the cultural difference between you and the Germans as I want it now, in two hours – what that actually means when you’re speaking to each other and the undersandings of that. How did you go about resolving that?
Johanna: I had several long conversations with my counterpart, another manager in the German office, because he was the one who was saying, “We can do it ourselves. We can do it ourselves. We can do it ourselves. No, we can’t do it ourselves.” You’ve seen this on the baseball field where I’ve got it, I’ve got it, I haven’t got it. So this was where I said, “We need a heads-up earlier. I need to be able to slow this work [into the – 08:57] work my team is doing. We need to know more than two hours in advance,” because if you spend two weeks with it and you can’t figure it out, chances are it’s a really hard problem. [unintelligible – 09:10] two hours. So don’t set anybody’s expectations like that. Instead, give us a heads-up that you’re still working on it. Maybe we can work with you. Maybe we can ask you are there any kinds of information that you can gather for us now so we can actually do some work on this.
Lisette: So you bridged it with communication, just getting understanding of the problem.
Johanna: Well, how did they like to work? What did their customers expect? [How do – 09:44] we like to work? What did our customers expect? How could we bridge the two? How could we help them understand that we actually had a lot more flexibility in our work than they seem to like? How could we firm up our stuff a little bit? And how could they have a little bit more flexibility over there? It really was a two-way street.
Lisette: Right, it sounds common. [That sounds good – 10:12]. And what do you see distributed teams struggling with today?
Johanna: There are many problems I see in geographically distributed teams. One is that they were originally set up for saving money, to have people who are not integrated into the development team. So we have developers in one location, testers in another location. And the company management did this to save money. And they often went west to east, meaning the testers are east and the developers are west – which is exactly the wrong way for follow the sun if you’re a traditionalist for follow the sun. And especially if you’re doing product development, it’s not about how much money you save. It’s about the speed of the throughput of the features. So managers were all confused – which is the best word I have – about how to organize teams and how to measure the organization of the team. So I see teams like this with one or two lonely testers out in India and then five or six developers in California. That’s pretty close to 12 hours away or whatever it is. I think it’s nine hours from the East Coast to India. Or must be 12 or 12 ½. I don’t remember.
Lisette: It’s like 10 ½ hours from East Coast to India, depending on where you are in India, even more, brutal.
Johanna: Which means somebody is exhausted all the time, and I’m sure it’s not the people in the U.S. And that does not make for a good team relationships. It doesn’t make for a good throughput. It doesn’t make for a good anything, except the managers are looking, “Oh, we saved $20,000 on QAs’ salaries. Well, you didn’t save anything because the time it took you to get the product through the pipeline is so much longer that you haven’t saved anything.
Lisette: Right, there’s definitely a trade-off there. So this is something that you’re still seeing, i.e. teams struggle with and setting up the teams and how to organize the teams this way. Oh, that’s very interesting.
Johanna: So what I’ve seen more often – or I should say more recently – is a lot of these people are now doing north-south. [crosstalk – 12:45] similar time zones or not too many time zones apart. Now you have a lot more flexibility. How do you create a team approach to doing this? How could people work together? Can they have any real-time rituals, at least retrospective if not anything else? Because a retrospective will help people say, “How can we improve what we did? We did this. What do we want to keep? What do we want to add? What do we want changed? What do we want removed? What lessons have we learned?” There are all kinds of ways to do a retrospective. But I think it’s really important to say, “How can we work better from now on?” And when you’re north-south, it’s so much easier.
Lisette: Right, time zones. I think in none of my interviews that I’ve done so far has anyone had a good solution for time zone. And I think simply, time is what it is, and there’s no way to shrink it. You can’t squeeze people together. It just is as it is. Somebody is getting up late and somebody is getting up early, and it’s not what they want to be doing at that time.
Johanna: Yeah. One thing I have done is use a time zone bubble chart. Do you know about a time zone bubble chart? I can send you a link to an article I wrote about that. It’s from Carmel. I don’t remember its co-author’s name. I’m Working While They’re Sleeping. But the suggestion is really great. And I started using that after I read that book. You have every time zone, every location with every person. And you have the difference in GMT, how many plus hours, how many minus hours. And that way, you can actually see. If I send a message, when will this person receive it? Do we have any overlapping time for a meeting? So I really like a time zone bubble chart just to say when are we.
Lisette: Right, to keep it in context with what we’re doing. What have been some of the biggest benefits that you’ve seen that distributed geographic locations have brought to people?
Johanna: I’m working with a couple of clients now who are totally dispersed. There’s a corporate office for [bookkeeping – 15:22] for business, but nobody ever goes there. And the nice thing about that is they can hire great people anywhere in the world. And they can hire great people close to their customers.
Lisette: Good point.
Johanna: So if you have customers in Australia and you’re based in Israel or in California, you can actually have people in Australia working with the customers, doing customer user group things. You can’t do that if you’re based in California or you’re based in the U.K. or you’re based in Israel, and people have to go into the office. If you’re dispersed by design, you can hire great people anywhere. Now they might not want to be marketing people. They might want to be developers, in which case, you might want to add marketing people in that location. But they can do customer interviews. They can ask people. They have all kinds of options for what they need to do.
Lisette: Right. And I want to talk about Agile and remote, of course, with you. I have to talk about Agile and remote. There is the debate of the Agile methodology being applied with remote teams. And a lot of people say just can’t be done. There’s a big debate happening about it right now. And I just would like to hear your perspective on it.
Johanna: I agree with some of the people. You cannot do Scrum. Scrum has too many real-time rituals. You’re supposed to do planning for an iteration together. You’re supposed to have a standup every day. You’re supposed to have planning for the next [unintelligible – 17:10] stories inside the iteration. You’re supposed to have a demo at the end of the iteration, all together, [unintelligible – 17:16] together. Well, if you’re totally geographically distributed and you’re more than 12 hours apart, or even more than seven hours apart, that means somebody is exhausted. So I don’t buy it. I say don’t do Scrum. Do Agile. Just don’t do Scrum. So if you really have to work in iterations, which you might not have to, then use a project manager to facilitate. And I don’t care if you call that person a Scrum master or an Agile project manager. But have that person facilitate the building of the stories with the product owner. And use something like a wiki or some other written documentation to help people understand the details of the stories. So that does not have to be done all at the same time. If you use a Kanban board, you don’t have to walk the board. You don’t have to have a daily standup. These daily standups, when you’re more than six hours apart, just seem silly to me. That becomes a real drag on the project.
Now one of the things I really like is to actually do follow the sun in Agile distributed teams, and that means you start with the east-most person. I don’t care who the east-most person is. If that person is a tester, that person develops automated tests for the stories and manual tests, and then says, “I’m done with my work today. I will hand off to you the next person going west.” So you always start from east to west, and you continue going from east to west, until you’re going round the globe. Now a lot of people think this doesn’t make sense because if you don’t have developers working on the story first, you don’t have any code. I don’t care if you don’t have any code. There’s something called ATDD (Automated Test Driven Development), as well as test-driven development. And if you have the [unintelligible – 19:23] first, you might actually have a better product.
Lisette: Oh, interesting.
Johanna: So this not what other people think of when they think of software development. And I’m happy to [crosstalk – 19:38] a lone wolf in the wilderness because I think it’s really important. If you have this team, and the team actually has domain expertise, people understand what they’re doing, then why not use everybody in the best possible way?
Lisette: I really like your focus on the organization of distributed teams. This is not something that I’ve heard before. Really, in a way, you’re architecting a team based on location in such a way. How would you build it on purpose? How would you have somebody start with that? What is the process that you start with for thinking about this?
Johanna: I prefer feature teams in every geographical place. Okay, that was [unintelligible – 20:33].
Lisette: [I’m doing this – 20:34] [Laughs].
Johanna: If you have people in India, I much prefer that you have a couple of developers, a couple of testers, but you have a four- to five- or six-person team in India. And then you also have a four- to five- or six-person team in California or Boston or wherever. And then they actually collaborate through the backlogs and through running tested features. So I prefer that. But if you have [unintelligible – 21:02]… One of my clients has a person in India, a person in France, a person in New Hampshire, which is the same time zone as Boston, a person in Colorado and a person in California. I did not recommend this to them. But given that that’s what they have, then that’s where you say, “Let’s determine the flow of work.” And if there is a way to have more people in one geographic location, that would be better. But if you cannot, then make the work flow in a way that makes sense. Don’t try to impose a structure that does not fit your team.
And that’s the part I really… I meet a lot of people who don’t really understand the point of Agile. The point of Agile is to limit the work in progress, so that you have faster throughput of the features. Now iteration-based approaches like Scrum say we’re going to timebox everything. Kanban says, “Let’s explicitly limit the work in progress by watching the flow of features through this system.” Now either one, they’re both fine. But I think it’s really important to say how do we get the flow of features through our system? That’s the question we want to ask. And as long as that’s the question we want to ask, then we architect the flow. We architect the team. Architecting the team sounds a little more [not so – 22:48] than I really feel like I do. I have suggested things to teams. I don’t demand that they do it that way.
Lisette: Are teams generally allowed to self-organize their own flow? Is that what’s suggested? Or is there a team lead who does that? I’m not sure how that works exactly. I would hope the team would get to decide for themselves, but I don’t know.
Johanna: The best Agile teams, as in the people who are most agile and able to adapt and manage their change, are self-managing. They might not be self-organizing. A self-organizing team says, “We see a problem. Let’s create a team and fix it. And then we can disperse the team.” So I’m in a self-managing team or self-directed team that says, “We understand the work that we have to do.” A manager probably put this together. That’s fine. But we can manage the flow of our work. We can manage [what done – 23:49] means. We can manage our working agreements. We can manage the membership of our team. And those kinds of teams perform really, really well.
Lisette: What stands in the way of people becoming those kinds of teams, usually? Because it sounds so great, doesn’t it? It just sounds like you go to work and you’re inspired and it’s running like a well-oiled machine. What tends to be the things that get in the way?
Johanna: Management.
Lisette: Oh, it’s amazing. You know? I ask this question often. And it’s swift and unequivocal. Management is the answer. There’s no hesitation.
Johanna: So a lot of managers do not understand how to be leaders. They grew up in a time where you managed with a Gantt chart. Now I’ve got to tell you. I’ve been managing projects since 1983, 84, 80. I never had a Gantt chart. I didn’t believe in them. So I never used them. And I wrote a project management book that has not one picture of a Gantt chart in it. So I don’t believe in Gantt charts. And my experience is that managers who actually believe in the Gantt chart try and exert control over what team members do. They don’t ask for the results that they want and then say, “Here are the boundaries on how you have to provide the results,” because sometimes there are boundaries. If you’re working in a regulated industry, you have to abide by what the auditors are going to ask for. You would be stupid not to. So let’s just make sure that we understand the boundaries of how we have to deliver the work.
But most of the time, managers are so deep into the technical issues that they’re not managing. They’re not leading. They’re controlling. I wrote a series of 36 Management Myths that I’m turning into a book at some point. That might be my next book. I think it is.
Lisette: Sounds like a really good book [laughs].
Johanna: So as we do this to ourselves, we don’t even know that we’re doing it. And I wrote this series of articles because I actually made a bunch of these mistakes back when I was a manager. And I really was trying to be a leader, not a controlling manager. So if I was trying and not succeeding all the time, just imagine the people who don’t know that this is an option. So a lot of managers don’t know. You can ask for the results that you want. You can say, “Here are the boundaries in which you have to provide these results, and then we’ll go from there.”
Lisette: Right, yeah, it’s tough. I interviewed an HR manager once, and he said that lots of people get promoted. They’re great lawyers. They’re great technical people. And then they get promoted to be managers. And they’re just terrible managers. And I thought, “Yeah, that’s true.” We don’t really have management, like going up the ropes of management training. I guess there is, but it just doesn’t seem to…
Johanna: I know. That’s one of the myths, by the way. I must be [FI – 27:05]. I must promote the best technical person to be a manager. I had a great manager from one of my first technical leadership positions. And she really taught me how to be a manager. And if she had not taught me, I’m sure I would have made many, many more mistakes. She was great. But I had a half a day of here’s how you fill up the forms with HR.
Lisette: Right [laughs], administration, [not management – 27:38].
Johanna: Yeah, and that’s not management. And don’t get me started on MBA programs.
Lisette: [Laughs]
Johanna: Well, they don’t talk about the humans. And it’s all about humans. Doing strategic planning is an act of organizing or focusing where you want the organization to go. And the organization is created of humans. So if you were never taught how to handle one-on-one, if you’re never taught how to do feedback, if you don’t know how to coach, if you don’t know how to influence, you cannot be a good manager. You just can’t. You have to learn the skills.
Lisette: Man, the list of questions that I have goes on and on and on. But I’ll sneak in one more before the very last question. In terms of virtual team management, since we’re on management, are there any specific skills that a virtual team manager you think should focus on, that are maybe different than you would have co-located? I’m not sure if there is a difference, actually.
Johanna: I’m not sure that there’s a difference in the skills. There’s a difference in the execution. So the manager needs to find a way to have a one-on-one every single day with every single person on the team, not every day but once every week or two. Now the interesting thing there is if you really have an Agile organization, you might have 15 or 20 people. So you might have to figure out how do I have a conversation once every two weeks with every single person. Now you’re not going to provide feedback to that person because you might not know what that person is doing. But that person might need coaching, might need to build their influence skills. They might have all kinds of interesting career development questions. There are all kinds of things that you can do on a one-on-one. And it does not have to be very long. How you do it is really interesting in a distributed team.
Lisette: Right, how do you do it?
Johanna: Well, we’re using Zoom. I really like Zoom for something like this.
Lisette: Agreed. I think it’s very personal. It’s almost as if we’re sitting across the table from each other. That’s how it feels to me. But I’m so biased. It’s hard for… [laughs].
Johanna: No, I happen to think so too. I think it’s really important to say what is the medium that I want that will allow me the best bandwidth for whatever conversation I need to have.
Lisette: And to really think that through as a manager. That is a great question. That is a great question. So sadly, so sadly, I’m getting to the end of the time. But let’s then end with the last question, which is if people want to learn more, if they want to get your book, what is the best way to get in contact with you and to learn more about you?
Johanna: Everything is on www.jrothman.com. Almost all of my articles are there. In 2015 I got tired and stopped posting all of them. I know it’s already February. I have to get back into the program. The descriptions of all my books are there. And I love to hear from people. What are your questions and concerns? Drop me an email. Send me a line. I’m happy to respond.
Lisette: Okay. And the website is quite robust. You have a lot. You have three blogs. It looks like lots of books. Really, it’s prolific, as we can see by the bookshelf behind you. Clearly, a prolific person [laughs].
Johanna: I do like reading. That helps when you want to be a writer.
Lisette: Indeed, kind of goes hand in hand. Well, thank you so much for your time today, really a pleasure to talk to you. And I really appreciate it.
Johanna: Thank you so much. I really had fun, thanks.
Lisette: All right, until next time, everybody, be powerful.
