Read along you will

Shane: Welcome to the no nonsense edge old podcast. I’m Shane Gibson

Murray: And I’m Murray Robinson.

Bruce: And I’m Bruce Taylor. And thanks for having me,

Murray: Yeah. Thanks for coming on Bruce. So we wanna talk to you about working effectively with offshore teams today. But let’s kick it up by getting you to explain your experience in the software development industry and your experience with offshore teams.

Bruce: So in 2002 onwards, I was working with lonely planet as lonely planet went from working in waterfall to working in agile. That was really my introduction to agile methods. Worked there till about 2010. When I moved to Aconnex as part of a group of people being bought into Aconnex to do an agile transformation there. [00:01:00] I was there for about three years and then was asked to come and work in the Bangalore office, as Aconnex was setting up a Bangalore development center. Moved to Bangalore, worked there for four years. And after that moved to Malaysia for a year where I worked with a company called IFlix a startup in Malaysia, and then recently back into Australia, where for the last four years I was the lead agile coach, and delivery lead with RM O T online delivering online courses . And for the last two and a half months, I’ve been with Everest engineering, working with the company there while we are looking at both working with our customers in Australia and our teams based in Australia and India, as well as exploring, setting up new locations for development. At the moment we’re looking at places like Malaysia.

Murray: So a lot of companies these days are getting quite a lot of their development and test work done in India or Vietnam. [00:02:00] Malaysia, Philippines, places like that. You see this a lot of the big telcos, the big banks, and the driver is nearly always cost. So I can hire a contract software developer in Australia for say a thousand dollars a day. But if I go to emphasis, I can get somebody with, three or four years experience for $500 a day. And if I go to Vietnam, I can get them for $250 a day. When I hear managers talking about it, it’s always about cost and there’s an assumption that. Developers are the same everywhere. So why would you pay four times more for one in the local market when you can get one for, a quarter of the cost from offshore? So what are the benefits of doing the work offshore and what are the economics of it?

Bruce: Yes, cost was a factor when AConnex decided to set up in Bangalore. When we hired comparable [00:03:00] engineers, in Bangalore, there were roughly about 50% of the cost that there were in Australia. So that was undoubtedly a factor but it wasn’t the sole driver. One of the other drivers was access to talent. There’s a lot of competition for people in Melbourne who are skilled in the kind of engineering practices, agile XP practices, or the languages that we’re looking for. In Australia the competition for the types of engineers we were looking for were Envado or Atlassian, those type of companies. We were competing and as a consequence salaries were being pushed up or people were being drawn to other companies, cuz maybe they had a sexier technology or a sexier company culture or whatever it was and as you say, cost was definitely a factor. But it was also, a struggle to find engineers in the time we needed them.

Murray: So I said it was because it’s cheaper and you said it’s because of the bigger talent pool. But I’ve never had any problem with getting, enough developers and [00:04:00] engineers in Australia, it’s just that you might end up paying more for them than you thought you would. So I don’t buy the talent pool argument and I hear that big companies always arguing for the talent pool, but really the talent is there. If you’re willing to pay the current market rate.

Shane: Yeah I’m probably gonna disagree with you Murray for a change. So I agree that there’s definitely a lot of cost focus and offshoring, but I think there is a pool problem in a lot of countries. And I think right now it’s worse because of the VC funded pyramid scheme. The idea that there’s these hundreds of millions of dollars going into software startups, where they can pay ridiculous salaries to get, the top people in that talent pool. As well as offer a whole lot of benefits outside of dollars. Especially in New Zealand, we are seeing, companies like zero, like Trademe that have a bucket load of money and a great brand, just taking all the good engineers. And if you are bootstrapping, like we are for our startup, you just don’t get a look in, even if you could afford to [00:05:00] pay the ridiculous salaries that they’re offering. So I, think there’s a balance there. I think definitely cheaper hour rate. Shall we call it? Cause I’m not sure it’s cheaper all up cheaper alley rate for offshore, but I think actually access to a pool for the ability to people who want to come and work with you is definitely a small part of it.

Murray: Okay, So access to a pool, of people that you can afford is maybe a reasonable way to put it. Cause in Australia, we are not paying, $500,000 for a software developer. I have never seen anything like that here. And even that it’s only the top 1% of the top, 1% of the top, 1% that get that.

Murray: I wanna explore the economics of it a bit more. Is it cheaper at the end of the day to get your work done offshore with a team in a developing country. What do you think Bruce?

Bruce: I think if you’re just trying to spin up a quick and dirty proof of concept over three to six months. I actually think, yes, absolutely. You could do it cheaper offshore. Because you’re not necessarily looking at [00:06:00] those engineers being on that product long term, you’re not looking at scalability. So I would be more comfortable using a quick shop that will, get you proof and concept relatively cheaply.

Bruce: Once you go, okay, we want to be a product company. We wanna productize this thing now. And we want to build long lived product teams who own the product. Then I think it starts to become a more level playing field because there’s things like building the company culture in the new location. And you’re not just working with an offshore Consultancy, who’s doing the work for you very quickly, spinning it up burning fast. You want to build a stronger work culture and you’re investing in more things there and you’re gonna invest in offices and invest in, cool places people want to come and stay.

Bruce: With Aconnex, we were probably 40% of the cost of the similar team in Australia. So, we spent a lot of effort on finding the right people. We were prepared to pay them well. So we were told you can get an engineer for 10% of what it costs in Australia. It was bullshit. We could get [00:07:00] ’em for about 40%. And the gap is closing, but we hired really strong engineers for that price. We made sure that we put in place processes and structures that allowed those teams to thrive, local product ownership, ownership locally. There are some bits that you have to invest heavily in and that’s communication technology, and you gotta invest in some of the travel, but still all in all. It was probably at the most 40% of the cost of doing it in Australia.

Murray: I have heard people from another company say that you can get the sort of benefits you were talking about, but it takes a few years. They told me it took them four or five years to get their teams in India, working as well as the ones in Australia. So is that what it takes? It takes that long term investment.

Bruce: I think it does take some investment for sure. I would’ve thought, two years on, we were a strong component of the, Aconnex engineering department.

Bruce: it’s interesting because at the beginning of this conversation, we talked about cost, and a large element of that [00:08:00] is that the companies or the organizations you’ll go to that are possibly more expensive than others are there because for example, ThoughtWorks or Everest or other more mature agile organizations have invested heavily both in hiring the right people.

Bruce: And all of that stuff comes with cultural questioning, all of that cultural fit stuff at the beginning, and then onboarding and training these people in the way they work. So there’s a lot of upfront investment in making sure that the people they bring in from the start are the types of people who are comfortable with asking questions or putting their hands up or working in a collaborative way.

Bruce: Whereas some organization, they may be cheaper but they don’t necessarily have the upfront investment in the organizational culture or the agile cultures that we Familiar with and know, and love.

Shane: when I look at remote working and outsourcing development, I see two different patterns. So there’s the pattern that I have [00:09:00] a bunch of development work I need to do. And I’m gonna use a company that’s offshore. They’re gonna do the work for me. And then there’s the other pattern, which is, we’re having somebody that’s working with us. They’re part of our team. They just don’t happen to live anywhere near me. What do you think.

Bruce: Yeah. absolutely. You could engage with an organization that you go, we want you to build this. We’ll give you the spec, you go away and build it, or we want you to be part of our teams. And the organizations that I’ve worked with in the past consultancies like Thoughtworks, and currently with Everest, one of the things I like about those. The intent is to be part of your organization as much as possible while still being a consultancy. So buying into your organizational culture being part of the team and making sure that those people that you work with, aren’t just people you throw work over the wall to, but that for all intents and purposes, they’re part of your organization.

Murray: So you went to Bangalore to set up the development team for a con X. What was that experience like? [00:10:00] And, what were the cultural issues you dealt with? What were the recruitment issues you dealt with?

Bruce: In the early days when we were talking about going to set up in Bangalore, one of the recruiters said to us, in Bangalore, you shake a tree and a software engineer falls out. There’s hundreds of thousands of software engineers. You go over there, you won’t have any trouble hiring. And so of course, we struggled really badly for the first six months, cuz we labored under the impression that , software engineers are the same anywhere. They’ve all got the same skill set and it’s totally not true. We went through the same interview process and the same selection process we had in Australia for finding software engineers in India. And it took us a long time to get even the first two or three people through the door because we wanted to make sure that the team in Australia was gonna be happy with these people working alongside them and in their team. we gave our engineers the right of a refusal in the interview process.

Bruce: Lot of hard work and a lot of stress in that first year, me going in maybe overconfident. I was actually really [00:11:00] lucky in that when I joined my engineering manager that they’d hired, there was a guy called Abdul awesome guy. And he and I spent a lot of time talking and getting an understanding of Indian culture, Indian engineering, working practices, that sort of thing.

Murray: What sort of people were you looking for and how did you get those right sort of people.

Bruce: There’s personal traits that we look for in engineers when we are trying to put them into small self-managed agile engineering teams of five to eight people. They’ve gotta be good at collaboration. You don’t want those brilliant dickhead in your teams who are gonna break your teams up and piss everyone else off. And so you’re really looking for very specific types of personalities and working styles as well as skill sets. And they were, and continue to be very hard to find in the market.

Bruce: So we wanted to ensure that they were really comfortable communicating with myself who was obviously gray head white man. And we have a junior in there and we often we’d put a one [00:12:00] of our female engineers in there as well. So it was like a quite diverse interview panel and just see their communication style and whether it was a back and forth conversation or whether they just constantly waited for you to ask them questions. And we tried that first interview to be open and fun and friendly so that we could get a free flow conversation. We just looked for someone who we would like to work with seemed like fun and seemed interesting, and was able to hold their own in the the types of conversations, they might find themselves in with teams in Australia. The second round they went through code challenge. They put together a sample set of code, answering a particular problem, and we’d examined that for testing and all these other agile practices.

Murray: did you find that there was a problem with people exaggerating their technical capability or technical education?

Bruce: Yeah, absolutely. But we caught that. There were lots of things that we learned along the way, like you cannot trust CVS. It was quite common to buff your CV with grades or universities. There would be [00:13:00] what looked like someone had done three years in an organization doing engineering. My context for that in Australia was you’d be hands on code. You’d be pretty experienced with doing the things that your CV said, but a three year engineer in India might have just been doing testing for free years and manual testing at that.

Bruce: There were companies to validate CVS and make sure that they weren’t crap. And we had the code challenges. We had pair programming as part of the interview process, we got them to do whiteboard sessions. We caught that, but definitely yes, definitely. It was a common thing.

Murray: I have heard people say it’s difficult to fnd people whove got more three to five years of hands on experience.

Bruce: Exactly cause they move into management and that’s the culture. the traditional culture is to be the person who oversees others. And there’s a strong peer group pressure and family pressure to be in those kind of roles with fancy titles. This is obviously a generalization, but when you’re in [00:14:00] a company like Infosys, your career track is 2, 3, 4, 5 years engineering, hands on keys. And then you go into management. And you’re no longer hands on keys. In a, traditional cliche, Indian office, as a manager, you get a cabin and you sit there and you look out over the team, and so you’re the layer between yourself and the customer. We hired specifically for people who didn’t give a shit about that. We tested for that. And we asked them that specific question. What do you want to do? Are you comfortable being an engineer? Is that the thing that gets you excited? We don’t have managers here. What do you think about that? We had maybe two engineering managers, but they did code as well. So slowed us down on hiring because there were unicorns to an extent, but we still managed to hire and hence why our teams were successful.

Bruce: We did a lot was work with our lead recruiter, really awesome guy, PR up. But we basically trained him and he trained us, but we mostly trained him on how to sift through CVS. And when doing questioning on the phone screen what we want and what we’re looking [00:15:00] for., and the first thing we did was did I have Infosys down as their first job that they did out of uni? If so, delete.

Bruce: So for a long time, we were just turning people away, partly because the head hunters or the agencies were contracted to in India were just sending us tons of CVS from people who had been in places like info or TCS or the big consultancies. It took me going and living in India and being involved in lots of interviews to find out how those big companies hired and why there were so many people with one year at info emphasis or one year at TCS owned SUV. They’ll go to the big universities in India and scoop the top 10% and then churn freedom in that first year. of the top 10 that they scoop they’ll keep top 10% and the others drop out the bottom and then they’re out looking for jobs elsewhere. We ended up rapidly going well, actually, if you’ve got info this on your CV we don’t actually wanna talk to you. We are looking for different types of engineers to [00:16:00] that.

Murray: Why was that though?

Bruce: We knew that people who had been though Infosys had been for an organizational culture, which was really hierarchical. When we interviewed them were very differential. Waited for questions. Only answered exactly to the question you asked. Didn’t venture outside of it, didn’t offer opinions.

Bruce: We want highly, opinionated software engineers, who are not gonna be afraid to speak their mind. And every single person I interviewed with those types stamps on their CV was a similar cultural trait. And in the end we just went, okay, give this up. Don’t even bother.

Murray: I don’t think agile works well with very hierarchical people, teams with lots of novices. It requires a level of expertise and willingness to be able to pick things up and work on them and learn about them and ask questions. I’m wondering if there’s a incompatibility between what agile expects people to do and the hierarchical culture of some [00:17:00] of those big offshore companies. It feels like there is.

Bruce: You could argue that’s true in Australia. We’ve seen struggled agile transformations in large corporations in Australia. It takes a lot of effort. There’s a lot of entrenched hierarchies and a lot of entrenched positions in any of these large organizations. India has a country culture, which is much more hierarchical than Australia as well. So you’ve got those two things.

Murray: And what you did was you recruited for shared culture, shared understanding opinionated, people who would speak up and experienced people that would work well in an agile team, wherever they were. It didn’t matter that they were in India. They were the sort of people you needed and you got them and , sounds like that was critical to your success.

Bruce: We failed a few times, I hired an engineering manager and in the interview was all of those things that we thought we were looking for. And then in practice, under pressure resorted to command and control [00:18:00] styles. You still get caught out…

Murray: Unfortunately, I’ve found that the agile practices we normally use, like the daily standup, where people are asked, what are you working on? What blocking you and, the sprint planning and retrospectives where we ask everybody to participate in planning and estimating aren’t working.

Murray: I’ve had some experience recently with an offshore team in Vietnam where we treated them exactly the same. There was no barriers between us and the engineers and the testers, invited them to all the retros and everything. Constantly asked them questions and how you’re going and all that sort of stuff and had one on ones as well, even with tech leads and just had very serious trouble getting people to, talk to us and even say, I’m blocked. We’ve had the situation where people will sit there trying to work out how to look into Jenkins for five days, instead of asking somebody who can tell them in 15 minutes.[00:19:00] It’s quite a big problem. And it seems to happen all the time with most of the people in the offshore team.

Murray: So what’s behind this is. fear? Is it hierarchy? Is it not wanting to let people know that , your English isn’t very good, or that you don’t really know how to solve the problem? what’s the motivation for not telling you?

Bruce: When we first started working with a partner business, when I was at a connect before we set up there, we were working with another company based out of India as well. And we had similar things. we sent someone over to business. They were in HBA and they spent three or four days there doing a bit of due diligence assessing whether they’re at the right company to work with. And then we said, okay, cool. Let’s go. We’ll set up a team. And it was across located team. So we had three or four engineers in Melbourne and there was seven or eight in HBA.

Bruce: And similar things happened where we started to notice that there was one person in the other office who would answer all the questions. One person would take the work and [00:20:00] pass it to the team. But then someone would’ve been blocked for a couple of days and we didn’t know about it, whatever reason it was, it might have been that they had a problem with their machine or whatever, and we the same sort of scenario we didn’t know about it.

Bruce: I haven’t really worked with Vietnamese companies and what Vietnamese company cultures alike my experiences with Indian or Malaysia. But I can imagine that there’s probably a hierarchy of the way questions and concerns get raised. Maybe there’s a fear of admitting that I dunno how to use these tools could have been, English. My gut reaction would be okay, how can I get, or build that trust? What tools can we use to build, understanding and trust. That admitting mistakes or admitting when you’re stuck is not a sign of weakness, it’s a strength, but that it’s an expectation.

Murray: So I really like the idea of a one team concept. I think that’s fits well with agile, this idea that it doesn’t matter what country you come from or where you’re located we’re still [00:21:00] gonna treat you the same.

Bruce: Yeah.

Murray: Do you have any other ideas for meeting techniques or for changing their agile practices to, get this more collaborative communication that we are looking for?

Bruce: One of the things that really worked for us was we bought some of those engineers over and spent two weeks with our team. And we said, you will pair with this person for two weeks and you’ll form that strong relationship.

Bruce: There was AMA and so we had two or three of their engineers came. They spent a couple of weeks of our engineers and those two, then we made them also pair online when they returned. And we sent our engineers over there to learn a little bit more about what was their office like, how did they work?

Bruce: And I went over as well and I spent a week in their office just sitting and talking with people and running workshops, but just observing who was, the leader of the crew, and the one who was doing all the talking and just trying to get my head around how that office culture worked, because it’s not just, a country culture, it’s an organizational culture as well.

Bruce: And we were fortunate that we could visit each other. And we worked really hard to maintain those [00:22:00] relationships online after we came back and we made sure that we did a trip either to their office or to ours every three months, it might have been a longer cadence than that, but it wasn’t over a year. It was in much more repeated patterns. The key day was building trust and building the ability for people to know that they can go to someone else. Who’s not the manager, but lower level, like they are so that they can have a conversation with a peer rather than with a senior member.

Murray: Yeah, that’s a good idea. I have tried pair programming and sending people offshore and it’s worked. it was helpful. The problem for us, is we are just not doing enough of it. An hour, a day is better than nothing, but it’s not as good as four hours a day. I think that has a lot of potential to really help a lot with the teams I’ve worked with. you’re building trust, but you’re also building competency and competency leads to confidence and confidence leads to people speaking up. So it’s a combination of the human factors of trust and relationships. And also [00:23:00] it’s just a very effective way of transferring Knowledge.

Bruce: totally agree. Sending people offshore, not as easy recently, but pair programming where you could. cause pair programming, is about building trust as much as it is about anything else. Obviously there’s the technical shared understanding but you develop trust in that way too. And that’s one of the really key benefits, I think, especially with your or your offshore team.

Murray: How often were you pairing? Was it, one hour per person every couple of days? Was it half days? what percentage of time was it like XP constant pairing.

Bruce: So sitting alongside each other at the keyboard all day, there might break for an hour here and there if there was something they could, solve easily on their own, or if there was something they just needed to set up and run off a single machine, but pretty much a hundred percent of the time. We mostly had pair programing as the standard practice, not as the exception.

Murray: What about between onshore offshore [00:24:00] pairing?

Bruce: Yeah, we did that occasionally. We optimized locally. If we needed to onboard someone that it required someone in Australia, at the beginning we made sure that they were in the same office. We took someone from India over to Australia for a month. So we tended to default, whilst we could have teams in two locations we tried as much as possible to give them isolated bits of the application and a started off being a monolith and we slowly built services and microservices in, and we stripped out bits so that teams in Bangalore could own a bit of it. Teams in Melbourne could own a bit of it. There was still integration stuff to do. And we did that by intense pairing where we. But we tried to optimize for a single time zone location.

Shane: I still struggle with using scrum when the teams are remote. I find that using more of a flow based set of patterns seems to be more suitable for teams that are remote. [00:25:00] My co-founder and I only work remotely. So we’ll catch up for a coffee maybe once a month. And everything else is done remotely. In our development flow when we do research spikes, we do them collaboratively together. We’re in the same time zone. And we know we are dealing with a really complex problem we haven’t dealt with before at a technical level. So we will work remotely using slack and Google meet and all that. And we’ll communicate collaboratively, multiple times of data to try and nail that problem. When we get to the design of the app we have a design led process. So our designer, Chris does a lot of the, work and figure, so there’s a not a lot of specification but when we hand over to Thomas, who’s our app developer, he gets Figma spec, because the way he likes to work is he likes to see the layout. He’s got a specification that he’s coding to and that’s the way he likes to work. So we’ve front loaded, a lot of the design work, and then he just becomes a machine and pushing it out. And that’s our workflow. Now, if we bought in a different developer for the app, Who wanted more freedom, then that early design upfront with [00:26:00] Figma to pixel perfect wouldn’t work and we’d have to change the way we work. One of the challenges we have is time zones, because none of us actually work apart from our Nigel work in the same time zone, we cannot work collaborative together. We have about a one hour window where we can all hop on, assuming some people wanna work late and some people wanna get up early. So we have to build a way of working that is not scrum based, is not this idea of in person retros and in person planning because yeah, we’re not set up to do that.

Murray: So you’ve got some people who are good but then they’ve gotta learn about your product. So a Iconix is product is quite big and complicated and it could take quite a long time to learn. And people are just not gonna be very effective until they have a pretty good understanding of the code base, the technology. What did you do to get people up to speed more quickly?

Bruce: Initially we bought engineers out to Australia for a month at a time pair program, constantly pair [00:27:00] programming was just something that was a standard practice at air connects. We bought the seniors out pair program was senior engineer in Australia on the apps. And at the same time, we made sure we had BAS and product owners in India, but they would pair up with their equivalent in Australia. And they’d come out to Australia. We had them have good product knowledge from the user perspective. So basically investing in both engineering and product in the Indian office. But also lots of shared video chats with each other shared pairing online. And just doing it until we got it right.

Bruce: One of the things we discovered in Bangalore was Retention was super important. if you didn’t give them a home and an organization that they believed in you’d churn through your engineers. They’d be jumping job to job and get a 20, 25% pay rise. And so you had to build all this other stuff, as well as getting those people to deliver software.

Bruce: So we built a really strong culture. [00:28:00] We made sure we paid well. And that we made sure that the work they were doing was fulfilling.

Bruce: The first team we put in there, we called SWAT. And they were a team that was basically working on refactoring and fixing old bits of the application that the team in Australia didn’t wanna do. But the team in India, what the guys said to me, look. I’ve been in a SWAT team somewhere else before I know what a SWAT team is. It’s a bug fixing team and this is not something an engineer’s gonna find purpose in. It’s boring. And we lost people. Cause they were like I’ve come in to fix bugs or I could go to flip card or I could go somewhere else. And I could work on really cool products. We’re gonna have to give them something useful and meaty to work on which we ended up doing. other things that we did in the retention was make it a great office, have a really good culture there non-hierarchical et cetera, which was quite unusual in a lot of Indian workplaces at the time. Some people didn’t fit into that culture as well as others, but the ones who did loved it and thrived and we hung onto them for a long time.

Murray: So when you are [00:29:00] working with people Who think that hierarchy is very important. They’re differential. They wait to be told what to do, and then to be given a lot of detail and then just to do exactly what they’re told. Maybe you just have to accept it and say, all right if that’s the way that you are comfortable working, then maybe we do need to appoint technical managers in your team, in your country, if that’s how you want work. Cause you don’t always get to pick the sort of people you are talking about. If you have to work with people who used that very hierarchical culture, maybe you have to accept it and work with it.

Bruce: Yeah. And that, is the old adage of inspect and adapt. And look at what does it look like working with this organization? Do we want to continue doing it? And if yes. Okay. What are the things we are gonna need to change the way we work to come to the way that they work.

Bruce: And we’ve got all sorts of tools and techniques that we use in forming agile teams that you could potentially use in forming your ways of working with the new organization. [00:30:00] to have a conversation about what do we call ’em team norms or social contracts or whatever as a way of going, okay this is how you do things. This is how we do things. What are the shared ways that we are gonna agree to work together? And it could be that actually our team is more comfortable working in a way where we have a technical manager here, who you communicate with. Now, you’ve gotta make the decision as an organization, whether your organizational culture can manage that and can handle the fact that you’re gonna be working this way, whether you wanna work in that way as well. You’ve got decisions to make based on what you learn about how they work and how you are gonna have to optimize to work together, like you don’t have to work with these co organizations, but Maybe it does come down to cost.

Murray: Maybe it’s decided for you by somebody in the executive team.

Bruce: Maybe it’s decided for you. And so you’ve gotta go. Okay. So what do I understand about the way that they work? And where’s a common ground that we can build, How do we build trust? How do we build those ways of working [00:31:00] that don’t totally break my team.

Murray: So I did a lot of work for a large telco with emphasis and I found that there were a lot of layers. So there was a project management and account management layer in Australia. And then there was a project management and account management layer in India. And we found it very difficult to get communication with the developers. So back in 2010, I tried doing an agile approach with team in India and it worked pretty well, but one of the big problems was getting the communication . One reason I went to this agile model was because we were being told, what they thought we wanted to hear, which I’m just gonna say was lying. That’s the way I interpreted it. So the project managers and account managers in India would tell their compatriots in Australia, what they thought they wanted to hear. And then they tell us what they thought we wanted to hear. One project, we had 45 people that was supposed to be in India. [00:32:00] We could never track them down. They’d give us names and we couldn’t find them or talk to them or see evidence that they’re working for us. one stage we were having incredibly serious problems with quality and defects and defect resolution. So we brought the offshore test manager on shore to sit next to me in the office, which helped a lot. But then he started telling me that there are all these problems in India that they’d been hiding. He told me that they’d been given times to test. You have so much time to test so many things and If you don’t do it, just say it’s passed and send it to Australia. Cause they’ll find it in user acceptance testing. And that will give us more time. So there was a culture of bullshit and deception when dealing with account managers and project managers in India. And I’m wondering if you have any insights on that.

Bruce: If you’re looking for my advice on how to work with someone like infas, my advice is don’t. I have avoided working with large[00:33:00] offshore out sourcing companies. And whenever the opportunity arose I have turned it down, and therefore my advice, don’t do it.

Murray: So I can definitely see value in having a, strong technical leader with strong communication skills in an offshore team. If they’re, a more traditional type of team. wouldn’t want to have project managers and account managers in the offshore team. Cause I have so much experience with them, bullshitting to me about what’s going on and getting in the way. But I think technical leadership could be a good thing to do.

Bruce: And I would pair them up with your local version. So that you build that trust between those two.

Murray: Yeah. So I have had the experience where offshore teams have said what we really want is a very detailed specification for the entire product from beginning to end with very detailed architecture and technical design. Put the stuff that you want from your requirements into that story, and then we’ll know how to work on it cause we can go and read all of the requirements and all the [00:34:00] architecture and all the design to give us context. So, I’m not quite sure how much of that is just that people have been brought up in a very traditional way of working. And now we’re trying to ask them to work agile and it’s a shock to the system. And, how much of it is that there’s just such a big Gulf in understanding that they just basically wanna be spoon, fed little things to do.

Bruce: yeah. That’s certainly something that will happen. A lot of times when you’re working with a lower priced offshore consultancy you can save money by giving them something that is much more of a well defined spec. It’s three months worth of work. It’s pretty well thought out by you when you go to them. And that’s where you can get cost saving in my experience.

Bruce: I also think it depends on the agency and how they’ve worked with people in the past, because one of the things as an agency is, rework and change requests, all that kind of stuff. If you’re working to a spec and it’s very clear what the spec is then [00:35:00] when something goes wrong, it’s much easier to be able to go actually that’s not our fault. That’s your fault because this is what it says on the spec.

Bruce: We don’t tend to work in that way. We’re going actually, you are part of our team. We all take responsibility for the outcome here, but that may be a difference between work to a fixed contract versus time and materials. And it might have just been how that organization has worked in the past and they may have been burnt once. And so they go that way.

Bruce: So one of the things we tried to do when we went into the world of agile was the empowerment of the individual engineers to make decisions on what am I gonna do next? Or how am I gonna respond to this goal. You’ve put a problem in front of me in the form of a customer story or whatever it is. And I know the product well enough and I’m close enough to the customer so that I can actually come up with the solution . And if you’re far removed from that, you’re gonna ask for that to be presented to you.

Bruce: If we as the home country or the company that are hiring the [00:36:00] offshore team fall into the trap of being more transactional cause it’s an easier way to do things because online meetings are hard, et then that will just exacerbate that behavior.

Murray: I think that people go to that transactional type of behavior because they’re not getting the collaboration and outcomes and output that they expect from the offshore team. So for example, if there’s an engineer in my team, even if they’re working remotely these days, I can give them something, ask them to do a story, and they’ll ask me some questions. They’ll, understand what’s going on and I’ll do it in five days. But if I give it to an offshore team member, I might find after three weeks that there’s been almost no progress and there’s been no questions. And then we have to do a lot of digging around and finding out that they were blocked by all sorts of things .

Bruce: Yeah, we’ve hit those walls in the past and one of the things we did, which was really successful in this situation was we put product ownership [00:37:00] in that team. We put a BA in a product owner there. We made ’em sync up with the product owner in the local team. And we said, you own this now. We’re gonna give you access to the customer. And we let them own the product from go to work.

Murray: So tell me, how was the product design different because you had people in Bangal or working on it with you.

Bruce: I think one of the, one of the obvious things that we did was originally, it was all for iPhone or iPad and it was like hang on. If we were trying to build this for countries like Bangalore. Hardly anyone has an iPhone or an iPad, but we’ve got a shit ton of Android devices. And so that refocused that priority, it was definitely in the backlog, but the prioritization of it came up because the team in Bangalore all, we, and it wasn’t that was targeted for countries where iPhones and iPads weren’t common.

Bruce: It definitely wasn’t, but it certainly in terms of the the thinking around, not just the product that we offshore there, but other products that a connect was [00:38:00] developing were well actually, how does this work in a country where maybe the internet isn’t as quick or the spec on computers that stand in computers aren’t as high.

Murray: What about with your ways of working? Were there any improvements and changes to your ways of working that came about because of this increased diversity?

Bruce: I think one of the things that my cohort Abdol and I had talked about was Australian society is very individualistic and Indian society is much more collectivist. Sometimes people are actually more comfortable with a more senior person being a decision maker. And you’ll probably notice that with teams that you’ve worked with in Vietnam. For instance making sure that you don’t default to, everybody must have an opinion all the time, which we tend to do in Australia. Whereas in India, it’s actually okay for you to defer to someone more senior than you, because this is what you’re comfortable with.

Bruce: My method of trying to run a workshop and trying to get decisions made was [00:39:00] ensure that everyone had a say, but some people might talk to you about it afterwards, but in that meeting room, they might not wanna do it. So being aware of cultural norms and what people are more comfortable with is really important.

Bruce: One benefit I had was I really liked that when I was working with the team in India, that everyone almost every day had lunch together, and people didn’t sit at their desk and eat lunch. Lunch was just a collective experience. And food was really important whether you went out to a restaurant or whether you shared it in what we called the pantry, which was the kitchen that collectivist mindset meant that you formed friendships really easily and people were much more open to you in group situations than you’d expect. It was something I really found rewarding.

Murray: so lets go to summaries. What do you think Shane.

Shane: Righty. So we had a good conversation about why would you offshore. And my view is yes, there is potentially a cost benefit. At least the hourly rate, I always question whether the total [00:40:00] cost of development is less.

Shane: But for me, it’s still about getting access to a bigger talent pool. So if you are struggling to get the right talent and where you are, then there’s some benefiting, going other places and finding people that are good.

Shane: I picked up this idea that for software engineers, at least they’re not the same everywhere you can’t think. That the way a software engineer works or behaves in a certain country is gonna be the same overseas or different places. So you need to bring that into mind.

Shane: Another really interesting one I picked up with is, as you said, it’s not just about a country culture, so there’s also a company or an organizational culture. So in my head, I would look at a country like India or Malaysia or Vietnam, I wouldn’t have looked at the variation in corporate and company cultures within that country. So I think that was a really good point.

Shane: I like the idea where you said you still have to understand the hopes and the fears of the people you’re working. Even if they are two steps, away from you. So it’s about building trust. It’s about providing that context, the context of what you’re doing and why still [00:41:00] counts. And if you are working with remote teams and remote people, you may want to adapt a different way of communicating that context.

Shane: And regardless of our teams are remote or with us, we should focus on being close to the team. And an agile we’ve learned to try and remove those layers with the people we’re working with. So we shouldn’t adopt that layer just because the people don’t sit in the same office with us.

Shane: So that’s the things that I picked up on.

Murray: Okay. So first thing, is it worth doing my experience with a lot of companies over a lot of years is that there are no cost benefits to outsourcing your work to another company for it to be done in India or Vietnam. And the reason is that you end up having to have a lot more people than you would locally. So there’s all sorts of extra layers of management. The team is much slower to onboard and you need to spend a lot more time with them. For example, when I was working with Infosys if I had a [00:42:00] team of 10 here, they would have a team of 30 in India with all of the extra project managers account managers architects and technical leads and with a huge number of, novices.

Murray: So these countries are very young and there’s a lot of people in the technical community who are quite inexperienced, And when you throw in the challenge of a different language, different culture different technology it Can make things extraordinarily slow and inefficient, and it just means that you need a lot more people to do the same amount of work. So when I’ve looked at the economics of it before, didn’t add up. When you look at the end to end cost total team, there was no real cost savings. And there were also a lot of challenges with communication and getting what you want and quality too.

Murray: So the next thing we talked about was software developers aren’t all the same everywhere. Because of this youth, because of [00:43:00] differences in, culture or behavior, difference in standards of education and so on.

Murray: But when it’s a really big market like India, there are always the right people available to you. And with enough effort you can get people who loved to program and don’t wanna be a manager after three years. And who are really good at it and who are opinionated and questioning and speak up. So we’re such a huge market. There is the potential to get the people that you need on an agile team.

Murray: So I really appreciate you sharing your experience with us. You don’t often hear that voice of, hands on experience. There’s a lot of theoretical stuff and a lot of wishful thinking.

Murray: So how can people find you

Bruce: I’m on LinkedIn Bruce Taylor and Everest engineering .

Murray: And do you have a blog post where you’ve talked about your experiences in this?

Bruce: Yes, I do [00:44:00] actually. I will share it with you and we could put it somewhere. There’s a few posts that I put up on LinkedIn, and then I did a longer one on medium a while back that has been updated. I wrote this blog post with my colleague Abdul. And then I added some of the stuff I learned when I was in Malaysia and I’ll probably edit it again as a go.

Murray: I think that’s one of the best posts I’ve ever read on offshoring.

Bruce: Thank you.

Murray: So thanks for coming on. We appreciate it.

Bruce: Thanks for having me.

Exit: That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact Murray evolve, that’s evolve with zero. Thanks for listening