HUGO MESSER is a distributed Agile expert with more than ten years’ expertise acting as an intermediary between companies in the Netherlands and employees in India and Ukraine. He is the founder of Bridge Global, an IT solutions provider, and Ekipa, an Agile training and coaching agency based in India and Indonesia. He has coauthored six books on “lessons learned in offshoring and nearshoring.” The most recent, Book 6 of the Art of Managing Remote Teams series, is How to Manage People in Your Remote Team.
(http://www.bridge-global.com/, www.ekipa.co and www.ekipa.co.id)
Subscribe to the Collaboration Superpowers Podcast on iTunes or Stitcher!
His tips for working with offshore teams:
- Focus on hiring the right people.
- Outline your communication processes.
- Capture feedback from clients and staff on a regular basis.
- Measure your output and communicate progress.
- Accept that there will be cultural differences and organize around that.
- Spend time in each other’s countries when possible.
Podcast production by Podcast Monster
Graphic design by Alfred Boland
Original transcript
Lisette: And now we’re live, great. Welcome everybody to this Hangout on Air. My name is Lisette and I’m interviewing people and companies doing great things remotely. And today I’m very excited. I have Hugo Messer on the line. And perhaps I mispronounced your name. Maybe we should…
Hugo: Oh, that was correct, yes.
Lisette: Okay, good, welcome. Hugo, you are the author of The Art of Managing Remote Teams and also the CEO at Bridge Global IT Staffing. And you caught my attention because of an interview that you did with InfoQ. And when I read that InfoQ article, I just knew I had to know more. So welcome.
Hugo: Thanks.
Lisette: For anybody watching, if you have questions, then go ahead and you can tweet your questions to hashtag #remoteinterview now or in the future and we’ll get those answered. So Hugo, let’s get started. Tell us a little bit about yourself and your story. It was very interesting on the website.
Hugo: Thanks. Well, you talked a lot already. So I’m Hugo Messer. I’ve written several books. Let’s start with I’ve been managing remote teams for the last nine years and I’m managing software development. I started out with the idea of helping Dutch companies to outsource their works to initially Ukraine, because that’s where I started, and later on India. My company was an intermediary, so I had a lot of teams in Ukraine where I would work with projects from Internet agencies and software companies in the Netherlands and then outsource it on a fixed price to the teams in Ukraine. Danish company helped worked up to a certain level, and then I learned a lot about how to not do it on a fixed price, how to do it in another way. In 2008 I set up Tristar. In 2005-2008, I set up my own office in Ukraine together with a company that I already worked with for the two previous years. And I also went to India to set up our office over there. So I lived in India for just one year and then went back one year to Holland and again half a year in India because I love it so much. And that’s how I got into India. I’ve been doing this for nine years. And based on my experience, I also wrote several books about how to manage remote teams with experts from all over the world who shared their experience on what to do and what not to do. That’s the short story.
Lisette: Let’s start then quickly. There’s a lot here. We’ll dive into that. But let’s start with the books because I’ve read that you crowdsource. It’s a crowdsourcing project. You wrote the books as a crowdsourcing project. Can we talk about that for a little bit? Why do it that way?
Hugo: Somebody coined the term crowd writing. So maybe that’s… I don’t know. I think she was the first one to name it that way. I wanted to write a book for a long time, and I had it as this big thing in front of me and postponing all the time. So then I thought, okay, how could I do it more easily. So I thought what about define the chapters, defining the theme, and then finding office from all over the world who know more than me, probably, who could write something about their experiences within this area of managing remote team. So then I decided to spread it up into six different books around the different theme within managing the remote teams, and then specifically for software development. And then I started contacting people in my network and through LinkedIn who have experience in this matter and also if they will be willing to write an article of about five to seven pages each. And about 90 percent of the people say yes.
Lisette: How did you come up with the topics? Were they the sort of obvious topics from your experience?
Hugo: I’ve been blogging for a few years, so I always think about what are the main themes. And based on my experience, I decided that it should be people, communication, culture, process and organization. And then we had two introductory books. One is How to Get Prepared and first one was How to Not Screw Up when managing a remote team, as a kind of introduction. And my longer-term idea is to gather all these topics on one big book with a sort of framework that people could actually use as a kind of blueprint of how to manage a remote team in the area of software development.
Lisette: When I saw the books series, I thought, oh yeah, this is fabulous. These are great topics, of course, communication, culture, process, and organization. We’ll get into that. But the first book, it really screams to be asked more, how not to screw up.
Hugo: I thought of a provoking title that would draw attention.
Lisette: It was good. So how do we not screw up?
Hugo: That’s a good question. I came with the topic also because I do think that a lot of people do screw up because a lot of people think I’ll just take my projects, pack it into some kind of Word documents, send it to a team in India or Google for that team in India. And then have something like a cheap team or whatever. And then I’ll send the requirements. They’ll give me an offer and a date, and then hit it on that date. And I think that’s where things go wrong. There are a lot of things, of course, that you should and shouldn’t do. And I think there is also not really an approach to do it right or wrong. It’s more of a mentality or methodology that you should practice and understand to make this work. But if I would have to pick two things that people need to consider is first of all most important starting point is to get the right people, get the right team because if you Google for any company somewhere in India or wherever they are on the planet, it’s not easy to work with just any company. So I think you want to make sure to find the people that are going to run the project within that company. So you interview them one by one and get a feeling of the actual work. I also think if it’s a bigger project, you might go to the front and speak to the management how to get the work, etc. And the second thing is the communication process. If you ask people why did your software project get derailed when you work with a remote team, it’s always communication, secondly it’s culture but I think it’s related to communication or the other way around.
Lisette: Yeah, you never hear, oh, we communicated too much. That never happened. Everybody always says we never communicated enough.
Hugo: And the problem is communication is a very vague notion because what is communication? If you say communication is a problem, then you need to draw a line. You need to figure out what is underneath it. It could be culture. A lot of things. I think it’s process. When we organized [inaudible 7:13] for this where you have all these areas [inaudible 7:23] before you’re starting the real work. [inaudible 7:28] for example, the software development process and how are you right now [inaudible 7:38] on how you’re going to work instead of getting [inaudible 7:48].
Lisette: We’re talking a lot about people who are going to different places. [inaudible – 00:07:50 – 9:48]. All right, how is this?
Hugo: Now it’s perfect.
Lisette: Okay, well, we’ll just continue like this then. Strange, I think it’s the microphone, oddly enough. So we’ll continue like this. So I was saying that people are going to different places to find teams to work on their software development projects. Why is that happening? Why are people going to different places? Is it that they can’t find people locally or the teams are cheaper in other places? I think this is where we start to get into the topic of offshoring and nearshoring. Am I right?
Hugo: Yeah. Of course, there’s a variety of reasons. And I believe the best reason is to find the right people for your project. So I believe that if you, as a company, are able to… It doesn’t matter where people are from, where they are working from, then you’ll tap into the biggest pool of talent that you could ever have. Of course, it takes time to get that but that’s I think the shift we’re making. My vision is also that this will be the direction we’re moving. Offices get less important when people work remotely. And once you are able to let your employees work from home, for example, the step to engaging people from another country is as big. So gradually, I think we’re moving there. So the main thing is to get the right people. And for Western Europe, and I think it’s the same in U.S. It’s very hard to find skilled programmers. There’s a big shortage. And in India and Ukraine, for example, there’s a big supply of people who have to work for your company. It’s getting tight over there as well, but that’s the main reason. And then, of course, as big multinationals are saying we’re doing it for cost reasons – which I think is also an important part – but I think it shouldn’t be the main driver. And the two main things that people decide on – am I going to take some team or company or individual nearby, which is called nearshoring. So for West Europe, it will be East Europe, and for U.S., it will be Mexico or Canada or somewhere.
Lisette: Okay.
Hugo: How do I take this team offshore, which is typically Asia, from either U.S. or Europe? Personally, I think it doesn’t matter that much. The thing is if you believe that nearshoring is easier… because that’s why people do it. They say it’s easier because people are closer, nearby, so I have less trouble time, which makes sense. So if you have to travel often, that could be more convenient. They also say because of the cultural proximity, it’s easier to collaborate. That’s the thing that if you believe that could be true, it is. My experience shows me that in the end, if you behave in the right way and if you’re open to making it work, it doesn’t really matter where they are.
Lisette: So if you want to make it work, you’re going to make it work. That’s the bottom line on this. But if you want to put the obstacles in the way…
Hugo: If you get the right people… Of course, there are lots of obstacles. You should do the things right. You need to get the right people and you need to get the right communication process. And that’s not done overnight depending on how you work.
Lisette: Right. But in Jim Collins, in his book From Good to Great, he always says you’ve got to get the right people on the bus first. After that, things solve themselves once you have the right people. I can understand that. So time zones, that is of course one of the challenges, I guess, for offshoring would be. And I’ve noticed it myself. I work with Jurgen Appelo and he’s currently in Melbourne and has been in Australia for the last week, week and a half. And I must say, our communications, it’s harder that he’s so far away. I’m used to having him somewhere in Western Europe. So it is harder. Are time zones a real issue?
Hugo: For me, it’s not really an issue. But if somebody is in Australia, or China, I can imagine it is because your overlap is less. With India, for example, from Western Europe, you always have a half-day overlap. And I think that’s enough to make everything work because you adapt your process to it. But if you have no overlap where you need to squeeze out one hour overlap, it’s probably harder. I have not tried it. I think that’s a challenge.
Lisette: I think you’re right. I think half a day overlap is okay because you get enough time of being together that it’s not too much of a delay.
Hugo: Exactly, and as long as you have time to communicate and adapt and make sure your project is on track and answer all the questions, it works.
Lisette: So something that keeps coming up now over and over again in the conversation is the issue of culture. And I haven’t been able to talk to a lot of people who have dealt with this successfully or have even really defined what the real issue is with the culture. Can you tell us more about it? Maybe some stories about culture where things have gone wrong or culture where things have really worked or where it hasn’t mattered, what should we be aware of?
Hugo: I think it’s about awareness, as you say. My pick on this is that in the end it doesn’t matter what culture you work with. You just need to get used to it. So if you get a new colleague in your own country, in your own office, and you need to start working with him, you need to get used to that person because everybody has his own characteristics and you need to adapt. Oftentimes, you’re wrong also in your hiring. I think with another culture, you have a few factors that add to the complexity, because if you don’t understand Indian culture, for example, you first need to learn how that culture has an impact on the person. But having said that, I also think that some people overestimate the influence of culture because in the end, it’s just people working together and you could blame everything that goes wrong and every miscommunication on culture, but I have miscommunication with my Dutch colleagues as well. So I think the main thing to do is to accept that there are differences, and from that point onwards, try to devise ways of organizing to manage around those cultural differences.
Lisette: Can you give some examples of a difference, maybe from working with people in India or people in the Ukraine, something concrete? I’m trying to think that where this culture really plays, because I really mostly work with Western Europe and the U.S. which is very close to my own culture.
Hugo: Okay, so I think I’ve got two interesting insights. One is you hear that often Indians can’t say no. You hear that about the rest of Asia as well. But in India, I’ve got my experience. So I have learned that it’s true and they say yes and they don’t say no. They don’t have that within the symbols or movements. So it’s rather tough as a symbol for them to say no. And also if you’ve got a superior, it’s hard for them to just tell somebody in his face – no. And a client could be a superior as well. Because I’ve lived 1 ½ year in India, I actually don’t even notice this anymore. It doesn’t appear in my brain at all anymore. I think it’s because of the guys that I’ve worked with, because I’ve got 40 people in my office in India and they are all used to working with me and Dutch people. So I think that this matters a lot. From both sides, you learn to adapt because the Dutch are very blunt and they would say anything, while the Indians easily get insulted when I say something blunt.
Lisette: I was just going to say that this is really the perfect culture clash here with the blunt Dutch-ness and…
Hugo: Yeah, absolutely.
Lisette: Because it’s true. The Dutch are blunt. I love it [laugh].
Hugo: I actually started getting more resistance to that notion after I spent time in India because I personally believe that it’s nicer to be nice to each other than to just be blunt sometimes. People can be really blunt. But before I went to India, I actually never really thought about this. I thought it was cool to be blunt because I grew up in Rotterdam which is probably the most blunt city in the country anyway. I think that by spending time with the other culture, you’ll learn to adapt. You learn how to work. You even start seeing your own culture in another perspective.
Lisette: And how many people actually spend time with the other culture? What if you can’t or what if it’s just too far? If you’re a U.S. company and you’re working with a team in India, it’s really far. Is your opinion it’s worth going and meeting everybody in person before you start working together remotely? Is that a necessity?
Hugo: Again, good question. I still believe it is possible to collaborate without having met each other, and I’m always trying within my company to develop something that makes it possible. So what we’re developing right now, for example, is a platform where we match software teams from all over the world with projects or clients that need a dedicated team. So there we try to map the right team with the right method based on location, technology, and the main knowledge to match them together. And we’re also trying to build inside this platform as a toolbox that you can use to collaborate because there are a lot of tools you can use to work with teams or people remotely, but it’s all scattered. So you need Google Hangouts, you need Jira, you need GitHub, you need Google Docs, and there’s nothing integrated. How did I come to this? So that’s what we’re trying to build with this platform.
Lisette: We’re talking about…now I’ve forgotten too, which is crazy. I’ll look back and go, oh yeah, we started with culture and the difference is in culture. And then it was that do we have to meet? Do we have to meet?
Hugo: Oh exactly. I think it is possible, but I think it’s better that you move to the country you work with for a while. So if you start working on a six-month project with three developer in India, for example, I recommend go there for a week or get the project lead to U.S. or Europe so that he can spend one or two weeks in Europe company to understand how you work, how you think, how the system works etc. So it helps a lot. After you’ve met each other, it’s much easy to collaborate. Somehow, something changes. If you went out for a venue, have a beer together, it works more easily, which is human nature, I think.
Lisette: Yeah, that’s weird, the extra senses that you have of actually being together just enhances it. I also have the opinion that it’s not necessary. I always think it’s better if it can happen. But if it can’t happen, we still have to find a way of getting the work done. And I think it’s possible.
Hugo: I think so too. And it’s harder also. It makes the challenge bigger. And people think… For example, in a software project of six months, even if it’s with two or three people, it’s quite a lot of money. And then you always have a chicken and egg problem. If you try it, you think, okay, I’m going to try the six-month project. And if it works, then I’ll go to India to meet the team. If you do it the other way around, it’s probably better. And it doesn’t cost much to take a trip and go there for a week.
Lisette: Right. Considering how much you could possibly save by having just been there, all the problems in the communication. So you’ve given us one example about a cultural difference, and I wanted to see if you remember what the second example was.
Hugo: The second would be for Ukraine. I think it’s hard. I don’t like generalizing about cultural differences, but the thing, for example, with Ukraine – and I don’t know about the rest of Eastern Europe – is that they are by nature more open and proactive. So people in Ukraine have no difficulties telling you that they believe your idea is not the right one and they have a better idea, whereas an Indian does have this challenge in the beginning if he doesn’t know you. So they are more proactive and that’s why clients like nearshoring because they think they will tell me more easily what is right or what is wrong, how should the process in certain problem in software development. The flip side is that they can really put the heels in the sand. I’m not sure if this is the right English.
Lisette: Yeah, yeah, I think the same.
Hugo: That’s a culture where they like discussions. So that’s the term they also often use. Dutch also like it but I think you can do more. They like to discuss a certain thing. And sometimes they take a certain stance on a topic and they won’t move. So you spend a lot of time trying to convince and that it could also be different. And for me, that’s a typical thing in Ukraine.
Lisette: Okay, interesting. So it’s more a matter of if you know that these are the challenges, you can find ways of working around this. It’s just a matter of knowing the culture, and that requires really learning about your team and not just hiring anyone. When you say that you should get the right people on your team, is it common for people really to send out a set of specs and then just expect it to happen? Is that common?
Hugo: In my experience it is, although it is changing now. I’ve been doing this for nine years. So I think initially, nine years back, that was the only way that people worked. And I see now in the market space that a lot of companies work under a model that we also use more of a dedicated team structure. So in a certain project, you need a team of three developers [inaudible – 00:23:50] user interface designer and the client knows every team member and you try to make kind of a one team between client and the remote people. But if you have a sites like oDesk, which you probably know, oDesk tries to open it up a little bit. They say you pay by the hour, but still a lot of stuff is probably going on fixed price, more projects where you agree on what needs to be built within a certain delivery date. I think it still happens a lot. But I also see in a bit. That’s the bottom of the landscape at the oDesk projects. I think the average project in oDesk is somewhere in the range of $700 to $1,000, so it’s all very small. Then you’ve got those multinationals that do it. And what I see here is that they all try to solve the problem of alignment between the cultures and the distance to get Indians over here. There’s a big insurance company and they work with Tech Mahindra [inaudible – 00:24:57] and they have about 200 people in India working for that insurance company, and 80 people additionally in the office of the insurance company. So by sending a lot of people back and forth they solve it and that’s how the big companies do it, which obviously can work but it’s an expensive solution and probably also not the most convenient for a lot of people.
Lisette: Interesting. So it seems to me this model… And this phrase keeps coming up a lot. It’s the phrase of organizations are becoming more “liquid”, which means that they are building the teams that they need for a project and then taking another team or morphing the team as needed depending on the project, which allows them to not necessarily have 40 full-time employees that they need to keep track of all the time. It’s more liquid. They can shrink and expand according to the work that’s coming in. You’re nodding your head, so it sounds like that is something that’s happening.
Hugo: That’s true. I think that’s the main thing. You get electricity in your home. You can hire people as you need them. I think that’s also how the other big companies like Apress and TCS all do it as well. They get into a big contract with companies. But what I hear, for example here, is that even those big contracts go to smaller subcontracts. For small projects, the project managers within the client company also say I need a team of three people to do this project for the next three months and I would like you to make a bid for this. And then they make an agreement within the larger contract to do the smaller project. So it’s all about flexibility. I think especially after the recession of the last five or six years… I don’t know how long it took but companies need this. They need more flexibility. In Holland and I think also in U.S., it’s more common to have freelancers, and a lot of people move from being an employee to more flexible engagements. And I think engaging remote workers is almost the same, basically.
Lisette: Yeah, it’s interesting because I was just thinking today, while I was on a walk. I was thinking that remote work really gives the worker freedom, but also it gives the companies more freedom because you’re not tied down to a certain number of employees busy and all over the place. It seems like the overhead of managing employees versus freelancers is not really that much. I don’t know. It just occurred to me that the freedom goes both ways here. And I think that it’s good.
Hugo: That does make sense. I never thought about this freedom concept, but yes I think it makes sense. I think also that it’s viable for any size of company because we work also for some startups in Amsterdam. They started a boot camp and incubate or accelerate. And those are smaller companies. They have lack of funds, lack of technical people to build a minimum viable product with a prototype. For this, we can easily get a few guys who are going to work for the project. If they finish the prototype, they stop the contract and get their first client before they continue the development. So this flexibility can help well because the alternative is you hire an expensive freelancer in your own country, which is really expensive. Or you hire employees. But you can’t just tell them after three months when the prototype is finished to go and come back in three months. Yeah, you could, but you still have to pay them. For the bigger companies, managers also like to save cost and be flexible if recession comes, like cancel some contracts.
Lisette: Right, so the flexibility going both ways. I think it’s going to be more important. And do you think this makes the average employee a little bit more entrepreneurial? That we’re not just going out and… It’s not just I have a job and I’m going to do this job and I’m working for this company and they’re going to take care of me as long as I do this. It seems to me, but I don’t know because I’m steeped in this world, so it could just be that the people that are on to me are more entrepreneurial. But in the wider world where this is new, is this happening?
Hugo: Maybe we shouldn’t get into a philosophical discussion, but I think that from being an employee to becoming a freelancer – you could call that entrepreneurial, but I think it’s just another way of structuring the agreement with an employer because in a lot of cases, people start as a freelancer and they are a little bit more free but they still work 40 hours for the same boss, or they have two clients and they work. So it’s still kind of employment-based. What I also see is that, for example, oDesk, it’s all about freelancers. I think it’s a really huge movement. What I heard is they have about $750 million of projects going over the platform because they just merged with Elance. So it’s really a big thing. And they say it’s the top of the iceberg. But this is all on the smaller project thing. I think the moment you have, for example, a big project for an insurance company or if you’re developing a software product that you’ve got 50 employees in Holland, then I don’t think the solution to scale up your company or become more flexible is hiring freelancers. I know some companies do it. But to have five people, for example, from different locations around the world, I guess that’s hard to match. If you have a team of five people in one other location, then you’ve got two locations and you can more easily manage this. That’s my vision on this. I think in the future, companies will also look more to having teams of people on another location work for them and let that collaborate because if you have five people and you want to have five more, it’s a lot easier to walk them in. You can hire five more for a certain project… I think the notion of freelancing… I think there is a limitation to it. I don’t see a lot of other people saying this. I might be the only one, but that’s my vision.
Lisette: So there’s a limitation on the freelancing. It’s interesting that there are $750 million going through oDesk/Elance, the combination, all in $700 to $1,000 chunk projects.
Hugo: A massive amount of work, yeah.
Lisette: That’s a lot of people looking on Elance and oDesk for work.
Hugo: Yeah, exactly. I think it’s a big ship. That’s clear. It moves from employment to freelancing. I just wonder how big the shift is because yes, it’s about freedom, but the biggest and the largest scale teams can get more work done, and you still need teams to… I mean one individual is not the same as five people working in a team and joining their brains.
Lisette: Especially five people that really like each other and have worked together before and know how each other works, and they’re just kind of a machine already. So once they get a project, they just put it through their own processes. That, for sure, is way more powerful, I can imagine.
Hugo: Which could, of course, also be done with five freelancers that have worked together, so it’s not black and white.
Lisette: Right. There’s a middle. The one thing that I think of when we’re talking is there’s a company I interviewed in June called StarterSquad. They’re actually also located in the Netherlands.
Hugo: I heard of them, yeah.
Lisette: They started exactly the same way. They were a group of people that were working on a project for a client, and the client work ended and they thought we don’t want to stop working together. This is a magic team. So they started their own company together, brilliant.
Hugo: But then you have a team that does work for several companies and they are virtual. I just saw the website this week. Somebody else mentioned it. So yes, I’ve heard about it. I think that can work also. I mean the difference between a company and such a team is not that big. The only thing is that as a company, they’re organized differently. They have people in different positions. But they have a structure of working together and producing results for certain clients. I think that’s a different notion than hiring five or eight people through oDesk that don’t know each other and they are working from different locations.
Lisette: Totally. [inaudible – 00:33:26] work but one is harder than the other.
Hugo: I guess so, but then again, I don’t know if you’ve heard about the atomic case, the guys who made WordPress. They have 220 different people from 200 locations all around the whole planet or something.
Lisette: On the other hand, they do get together. They are encouraged to get together as teams for their projects. So they spend like a month together in Greece, for instance, like with Scott Berkun, what he did to write the book and doing all of that. So even they are encouraging face-to-face.
Hugo: Yeah, but still the work is done usually from whatever location somebody is living at the moment.
Lisette: Indeed. It’s interesting. The model of the way businesses are structured is changing. And I’m really starting to get into this with Happy Melly Network which is encouraging businesses to organize themselves more as a network instead of this hierarchical structure. And I think that’s exactly what you’re talking about here. You’re building the team that you need and there’s no top-down management. There’s always somebody in charge, of course. You have to have a coordinator or a ringleader or a product manager. There’s always somebody who is coordinating. But the structure of it is really changing from the old school model.
Hugo: I think so too. It’s maybe not even how you organize the people because there are also these websites were you can post a scientific problem and then get a reward of $50,000 for the guy who gives the best solution to this. So that’s a totally different perspective from just thinking that you have a few people in a certain location to work for me.
Lisette: Right. That’s actually the reason why I got into this whole thing. I worked for somebody who wanted to end the problem of ageing. He didn’t want to die. So he built an online project management tool so that longevity scientists could talk to each other and share data. I’ve got to solve this. These people are not talking and I have to solve this. And I thought wow! What a cause! Think of what we could do? If you could solve ageing, we could solve everything.
Hugo: I’ve never heard about that one.
Lisette: [laugh] Yeah, that’s another thing. The product is called QTask. I’ll send the link to it. They no longer exist. Sadly, it had a fatal end, but brilliant tool, brilliant man behind it, everything. Not everything was… but let’s talk about, before we run out of time, I want to talk about this issue of scaling and the bigger companies. Some of these things that we’re talking about, these are small teams – 3 people to 10 people to 30. But if we start to get into these big multinational companies, how does the remote work scale? How does offshoring and nearshoring help? I know that’s not a simple question.
Hugo: I think they are also struggling. I speak to a lot of people in multinationals and they are all trying to figure… I met a guy at Tele2 a few weeks back, which is a telecom company here. It’s a Swedish company but they’re established in Holland also. I was really impressed by the way they organized. When I walked into their office, there were I think people from 20 or 30 different cultures just walking around there. They had all these scrum boards and everything is distributed, or Agile. They even call their contracts Agile contracts. Everything is Agile. What he told me is they have about 40 teams, and I think an average team is somewhere between four to seven people as a typical scrum team. And 40 teams all around the world with different suppliers with their own people. And they mix this between the people also. So they could have a team of seven people that consist of two employees of Tele2 and three guys from Serbia, consultants from the Netherlands, and then two more guys from India, for example. That’s a team that works together. But that’s a company that, in my opinion, is very far ahead in organizing this – whereas there are still other companies that work more in a waterfall way. So somebody comes with the requirements and it’s sent to some big manager that might be an Indian guy that is in a Dutch office, and the guy makes ubiquitous back office etc. There are various ways of doing this, I think. What he told me in Tele2 case, he said last year we scaled up from 20 to 40 teams. But once you’ve got this structure of Agile collaboration in place and you have the contracts, procedures, the rules defined and it works, it’s probably rather easy to go from 20 to 40 because the structure is kind of similar. And the important thing is to get the right people in those teams.
Lisette: Interesting. Dr. John Carter wrote a book called Accelerate. In an interview he said that actually the hierarchy is not bad. The hierarchy is really good when you have something that works, set up a hierarchy and repeat. But the network is there for the experimentation, like in the research and development and the innovation. So you need both. Essentially, we need hierarchies but within the network structure. So it sounds exactly like what this guy did. When you find something that works, you repeat it as a hierarchy.
Hugo: I’m just thinking of hierarchy matches with Agile development. I guess it’s right what you’re saying.
Lisette: I don’t know how the two bind because it’s changing things. The Agile thing is changing things. But something that I hear all the time is Agile and remote don’t go together. I want to ask your opinion on that. I have a very strong opinion but I’m going to try to keep it to myself until I hear it from you. You always hear that with remote teams, Agile was not meant… Even though lots of people are doing it, Agile is kind of shunned by the remote, or remote is kind of shunned by the Agile movement.
Hugo: Yeah, because I think one of the things in their manifesto is that it’s better to sit together or something. I’m not sure if it’s in the manifesto but they say you need people to be in a room. But I do think that if you compare Agile or Scrum with traditional way of building software, it’s a hundred times better in a remote setting. Nobody would argue that doing work with software developers being in one office is harder than having people distributed. It’s always easier to sit around the same table. But if you do stuff remotely, I think Agile is really helping you. And one of the reasons why this is the case is that Scrum is the method that most people use for software development. Agile is more of a manifesto and way to organize the software could be something else. But in Scrum, you have a lot of meetings, pre-structures. So you’ve got a spring planning meeting. You’ve got a daily standup. You have a demonstration at the end of the sprint, you have the retrospective. And because this rhythm is there, you establish fixed-time intervals to discuss stuff with your remote team. And if you integrate those meetings, you make one team. So the people in the U.S. or the Dutch people do the meeting together with the guys in India and discuss everything. It becomes clearer. The black and white situation as in waterfall model, somebody in Holland would devise, would think of a software, a screen, for example. I’m going to write a requirement on a certain functionality. So I make a screener, I describe every single detail of it until I spend three hours to think about it and write it down. Then I send it to the guys in India and they should understand because I already spent three hours and then they should program it. And I’d rather have no questions because you assume that you have devised everything, whereas in Scrum you would say I’m not going to spend three hours describing what I need. I’m going to describe it in one minute. I make a user story and then I’m going to discuss with my team what it implies. And it could be three hours but then it’s in a discussion. So everybody is thinking about how this user story can be built, and then everybody already understands it. So you don’t have this transition point of I’ve thought about everything. Now you read it and study it. And if you have any questions, you can contact me. But you spend all the hours together and there is no need of more explanation.
Lisette: When I’m thinking about this, I’m actually giving a presentation next week at the Tools4AgileTeams conference in Germany. And I was thinking because I know this issue is going to come up of you can’t do remote and Agile. But I think to me, Agile shows us how remote should be done.
Hugo: Exactly, yeah.
Lisette: It kind of gives us the guidelines for how to work in shorter sprints or timelines and to become more results-oriented and to have regular retrospectives in the planning. To me it shows us what the process should be, at least how we should start. You always have to massage it to your own team. But it didn’t make sense to me that they wouldn’t work together. I feel really strongly that actually Agile shows us the way.
Hugo: Because you’re doing a workshop also and the communication rhythm, I think you call it, right?
Lisette: Yeah, because to me I found and actually I wanted to ask you about this because it’s one of your books. But I found that there are certain protocols with communication that become really important – even very simple things, even keeping your email subject pertinent to what’s actually in the email. So you don’t have this long 40 email train, but actually the subject changes every time the topic changes if you’re still using antiquated email. Lots of teams are doing it, simple things like that, or not using the words “only” or “just.” Can you only do this? It will just take a minute. These kinds of things where you assume somebody else’s time for them; very simple communication protocols. But also you touched in the beginning of the interview was taking the time to establish what your communication protocols are going to be.
Hugo: I think that’s a very important way, because people tend to just start and get going. I thought we will work. If you step back and do three or four hours of brainstorming with your team on how you’re going to work together and how you’re going to communicate, it saves you a lot of trouble.
Lisette: And it’s surprising the different ways in which people do it. I worked with somebody who was an email fanatic and I happened to hate email. And so they were using email as an instant messaging system. And I thought why don’t we just use instant messenger? It would be so much faster than my email box. So it was even just a slight communication difference like that that in the end caused big problems.
Hugo: Yeah, email was probably fatal, maybe in organization in general, but specifically if you work with the remote teams.
Lisette: Can be. So you say that I’m curious. What other tools do you recommend? How do you organize your communication with your teams?
Hugo: The way of communicating, collaborating for software development, and at the same time, of course, I’ve got a ccompany and I’ve got managers. So I have an office in Odessa, one in Kiev, then in Kochi. My sales guys in Holland they’re also working from homes. And we’ve got an office where we sometimes sit but not always. So we’re actually, on the organization side also, full of virtual, although I don’t really like doing virtual because it looks like I’m working with a robot. So people are working from where it suits them. In the beginning when I started that and I had managers in different locations, I didn’t really have a method. And after a few years I came across the Rockefeller Habits. It’s from U.S. guru Verne Harnish and he wrote a book about this. It’s a methodology for growing companies. One of the central elements is a meeting rhythm for managers. So he says, okay, you make up, you make plans for 20 years. You make plans for five years or three years. And then you make a full strategic plan for one year. You take quarterly goals, weekly goals, and daily goals. How do we organize this? We’ve got a Google sheet where we have all these things. So one sheet is up until the year, and then the other sheet is about top priorities for the quarter and the week. So every quarter we do a session with all the managers where we define the two to five main rocks for the quarter, and every rock is assigned to a specific manager, and each manager also makes a plan with two to five priorities for himself. And every week, everybody makes a plan and we have a weekly meeting of about an hour on Monday, one hour. And we discuss those rocks from the previous week that every person has and the plan for the coming week. Every day, also, we have a short meeting of about 5 to 10 minutes where we discuss what did you do yesterday and what are you going to do today, like with Scrum, and are there any issues that you’re facing. And by doing this every quarter, every week, every day, you get a certain rhythm that makes collaborating much easier, because if you don’t do this and you don’t speak on a daily basis in a fixed time interval, people might be stuck on something, and then a week or two weeks later, you hear something and you thought I could’ve prevented that very fast. So you’ve actually lost two weeks. So by meeting more, you actually get going faster. That’s on a management side. If I would recommend anybody how to organize virtually, I think for the management side or organization in general, not software development, you take the Rockefeller Habits, and then for the software you take Scrum. That’s a good starting point.
Lisette: Right, and you can massage it. The details can be massaged for every team as needed as you go.
Hugo: Yes, yeah.
Lisette: So you bring up something that you have people set their own goals and you said your two to five rocks for the quarter or even the rocks for the week. How do you evaluate performance on a virtual team? Is there something special that you do? If somebody is not meeting their KPIs after a long period of time… Have you been in that situation? And what do you do when that happens?
Hugo: Again, I think it’s important to make a distinction between general management and software development. What we do in projects that we run for clients is every week we asked a client how satisfied he is with the collaboration on a scale of 0 to 10. And we do it both sides because a client might also be unavailable or describe requirements in a wrong way, and we might as well. So we do it back and forth. And then for the productivity of programmers, that’s a tough one. There are a lot of books written about this. If you use Scrum, I think velocity makes most sense, and especially velocity over time. Velocity is how many user stories does the team get done in a certain sprint, which is typically two weeks, and you look at how this evolves over time to get more user stories done in each sprint and it goes the right way.
Lisette: I really like the idea of having the work velocity every week. It made sense to me when I first learned about it. I tried to apply it to myself every week with, okay, you know you can only get these three things done. I have my own point system.
Hugo: So for your normal work, not software development?
Lisette: Yeah, I just do it for myself, just to see, just because I’m overenthusiastic. I tend to overdo what I think I can do. It gives myself a reality check. A friend of mine termed it as Scrum of one. I thought that was a great name.
Hugo: And back to your question, on the management side, we have KPIs for the role that a person is in. So we have two or three KPIs for the operational stuff. For sales it’s how many opportunities do you have in your pipeline. For operations, in our case, for example, the KPI for our operation manager is the average score that we get from the clients in the weekly monitoring, so the collaboration rating. Over each role we have the KPI indicates if he’s doing his responsibilities well. And then every week they also report in the progress on their rocks, top priorities for the quarter. So you can see what they worked in a week. But the main thing is each manager should keep the rest of the team updated on how much progress he’s making. If he’s stuck, what he’s going to do to make this rock anyway, because the most important thing is to make that rock for the quarter and how he does it is his responsibility. So I think everything needs to be about output. You need three goals and a way of measuring it and communicating progress. And actually that’s it.
Lisette: Yes, sounds simple, but there are a hundred tools to help you do each one.
Hugo: That’s right, yeah.
Lisette: So I got a question from somebody watching it, which is a very broad and general question. But maybe it’s a nice way to end the conversation. He asks what makes it worth it? And maybe a different way to phrase that, why do you love this way of working so much? What makes it worth it for you?
Hugo: It’s a broad questions but it’s an interesting one. First of all, I really love working with other cultures. On Saturday, I’m going to India for two weeks. This is something that I think enriches my life. I love India. I love spending time there. I love Ukraine as well but India a little bit more, especially now as they’re shooting each other in Ukraine. So I think every day you talk through Skype. And I’m still sometimes in person. I’m sitting behind a monitor and I’ve got all these employees or colleagues everywhere in the world, and we collaborate and work together – which wasn’t possible 10-15 years ago. So that really inspires me. The reason why I set up this company also is to make this remote global collaboration work for more companies, to facilitate this global collaboration. I believe, especially in our sphere, it brings some kind of balance to the world. So that’s my personal motivation. When I was in India, I saw a lot of poverty and I thought what could I do about it. I wanted to start a company and I really wanted to do something commercial and not start a charity or something. So I thought how could I do that. On one hand, you help companies from Europe or the U.S. to find people that could add value to their company who are hard to find in their own country because there’s scarcity of talent. So you help the companies grow and become more profitable by adding the people and that also at a lower cost. And you also create jobs in another country which is more poor and you help them develop. In India, I see it with all my colleagues. They buy cars. And guess where they are produced – in the West. They buy television. It’s usually Philips. So there’s a big spinoff. Every research about this topic also shows that the equation is actually positive for both sides. I think that’s a long answer to that question. That inspires me. So both the cultural and creating balance in the world.
Lisette: I like that when done well, it’s a strong win-win situation for both sides of the remote working equation. I agree to the idea that you get to talk to people from all over the world every single day. I think it’s very exciting. Today I spoke with Moscow, Buenos Aires, and now you. And I think wow! I’m just sitting here in my apartment and I’m talking with people. I just think it’s great. I learn a lot.
Hugo: Yeah, I think so too. I couldn’t imagine having a job going to the same office locally every day.
Lisette: Yeah, I call it day prison [laugh]. So one final question, which is if people want to learn more and buy your books and get in contact with you, what’s the best way to be in touch with you?
Hugo: If you Google Hugo Messer, you’ll find all my contact details, I think. I’ve got a URL hugomesser.com. Everybody could send me an email h.messer@bridge-outsourcing.nl I’m on LinkedIn, easily findable with my details in it, Facebook as well.
Lisette: Okay, so there’s no excuse if anybody wants to get in contact with you. They have no excuse. You are all over the Internet.
Hugo: And there are not so many Hugo Messers, as I found, so it should be easy.
Lisette: Okay, good. All right, thank you so much for the time today. I think we had some really interesting things come up and I’m really looking forward to putting this up in the blog post first and then of course I take the most valuable gold nuggets and place them in the book. Until next time, everybody, this is Lisette. Be powerful.
