71. Growth Hacking for Remote and International Developers – Part 1

Rich: In episode 71 of Mobycast, Jon and Chris discuss lessons learned while working with remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. Let’s jump right in.

Jon: Welcome, Chris and Rich. It’s another episode of Mobycast.

Rich: Hey, it’s good to be back.

Jon: Good to have you back. Today, I think we’re just going to jump right into it because today’s episode is less talking about details and more about some storytelling. We want to get into some of the transition that Chris has gone through moving through his career and starting to work with Kelsus, starting to work with remote and overseas teams. Rich, you’ve been looking at some of our analytics more than I have, but I think a lot of our listeners are from overseas and maybe work remotely and this is the audience we are talking to. I think we want to work directly to you today. Is that right, Rich?

Rich: I actually don’t know. I can probably find out as we go through this but that’s a good question.

Jon: Okay, maybe I have been paying more attention to analytics than I let on. It’s true.

Rich: Okay.

Jon: Hello, international listeners. Thank you for listening. I have done my career largely working with international team and that started in 2001 at a company called StorePerform. We had a US-based team which is a really high-performing team. Some of the people at that team are now CTOs at major hedge funds that you would have heard of, they’re Chief Architects at Nasdaq. These people were excellent.

One of them is a Chief Architect at Twitter, really good developers on this one team that I worked for in 2001. While I was there though, the leadership of the company was Indian and that guy […] decided that he wanted to have a team in India because that’s where he had come from and he just felt like he wanted to pay back a little bit from where he had come and I volunteered to go there and hire a team.

In 2001, that was really early for doing that in Bangalore. When I visited, I didn’t see other people that were on that trip doing the same thing that I was doing and it was very easy to find people. I went back two years later in 2003 and it was not that way at all. I haven’t been back since, but I imagine that if I were to go there now, I wouldn’t even recognize the place. It would just be a Silicon Valley of India.

Anyway, I don’t want to make this too long of a story about myself, but the point I want to make in that is, after I hired that team in India, what we found was that we had two entirely different teams. We had one high performing team and one very performing team. I’m not blaming the team in India; it was just a fact. We had a good one and a bad one.

Since then, I have worked with different teams all over the world. I’ve worked with teams in Nepal, teams in Thailand, teams in South America, and I’ve finally landed with Kelsus and building a team that I have been working with for the last 11 years that I would claim as a high-performing team. They’re a very good team. Chris came to this a couple of years ago with an entire careers’ worth of working for a high-performing […] and managing high-performing teams.

It was a journey for him, switching from working inside US teams to working with a remote team, and he’s been instrumental in taking the Kelsus team from mid to high to extremely high-performing. Chris, I just want to talk to you about that experience, about switching from working in the US-based teams to working with Kelsus. I guess, let me start by asking a question, what did you expect when you first joined us? What were your expectations coming in?

Chris: Just the TLDR would be, I expected the unexpected, really. I really didn’t know what to expect and that this was a new experience. These two ways: one was completely virtual company which was somewhat new for me. I had worked in completely virtual company before. My bootstrap startup was a virtual company, but that was all with folks that I have worked with in person before, so it’s a little bit different.

Jon: Do you even work for Kelsus, Chris? We are not a completely virtual company. We have an actual office with people that show up every day in Resistencia, Argentina and another office in Corrientes, Argentina.

Chris: It’s virtual to me. From my perspective, right? It’s just a matter of what lens you’re looking at. But absolutely, yeah. We actually do have leases and physical office space.

Jon: I’ve just bring that up because in my own experience, I’ve been to those offices twice now, I think. It just blows my mind when I go there. It’s like, “What? This company I founded 11 years ago have offices?” Okay, I guess we have offices. It’s always surprising. Go ahead.

Chris: That was one major difference being a virtual team and then the other part dealing with non-US developers. I’ve had some experience with that, but more tangentially, like I said. I worked with a couple company positions. I worked for a mobile software development company and it was on the larger side for me. It was probably about 600-700 people when I joined, it did recently go public. They were still a pretty young company but kind of growing quickly. Engineering team was probably 20-30 people big when I joined at their offices that I was at, but it turns out that we actually had a whole offshore development team in India and actually growing that but for me it was a bit of black box. It was always a mystery.

Jon: That was so typical. So often companies just keep the teams separated, “Oh, yeah. There’s that darkhorse team somewhere else that’s overseas,” or in the Eastern Europe, or India, or […], or some other place China and the developers in the US don’t even know what to do. I think that’s sort of terrible.

Jon: Right. It was not a good experience for me. It didn’t give me a high degree of competence in that model just because I didn’t know what they were doing and why they were doing it and then they were working totally different hours. It’s like, I would come in the morning and see the result of what had happened the previous night and now the build would fail. Just major spelling errors in the code and it was just like, “What’s going on here? Are we really paying for this? This doesn’t seem like a really great deal.”

Jon: Just to interrupt you again, that was my initial experience at StorePerform too. Even though I went in Creative Team, I think people within the company that were above me that were VPs of engineering or CTOs or whatever were trying to take care of the feelings of US developers who didn’t want that team to exist and were pretty vocal about, so they were just like, “Yeah, Jon. You do the Indian stuff and make sure it doesn’t impact the US stuff very much. Just keep them separate.” That was my job. I could tell that it just wasn’t working and that’s already a lesson learned. If you’re going to do this, creating us versus them situation with your remote teams is a good way to fail.

Chris: Yeah, absolutely. I think definitely hitting a very real issue there and it goes with the industry itself especially US developers. There’s this feeling of, “We’re the best in the world. We’re the only world-class developers out there and that we’re worth the most money. We have the best salaries, the highest rates.” If you go and hire a remote team or an international team, offshore, nearshore, or whatever it costs less and it’s not as good.

That whole mentality, I think, like what I said, what you’re describing there is like dealing with that, right, and managing. There’s management’s perception or fear that the US-based team is going to have some morale issues, just perceptions issues with this work that’s being done by these other teams. There’s not an integration. It’s trying to build that wall between them. It’s almost like, “Don’t worry. There’s nothing going on over here.”

Jon: Exactly, which is not how the business sees it, so it’s incorrect.

Chris: Right.

Jon: That kind of leaves a bad taste in your mouth. Then another experience I specifically recall with you is when we were working together very early on where your company is a client of Kelsus, not directly. Kelsus was subcontracting for a different company that I shall not mention. You and I were working together. I remember specifically you sent me an email or a message that said, ” Hey, what’s up with this code?” And it was a code I got that still works with Kelsus and in fact I have written. It was like  100-characters long on a line of lots of weird node checking or something and it was just ugly to read. I just remember being like, “Oh, Chris is reading our code. What’s going on with that?” That was unique for Kelsus. Can you remember that?

Chris: Yeah. I think it may have happened a few times. My role there was, I was the primary interface with you and that team. I was writing most of the backend services, the API, and your team was building the mobile client, and so at the end of the day, I was on the hook for making sure the whole thing works end to end, right? Part of that was just I was doing a lot of testing and using of that app. Getting the new builds of it, looking at it, of course, we have access to the code base. Until to this day, I do code reviews of all the codes that’s coming through, but definitely looking at […] even just really quickly.

Jon: You’re like the TSA random signaler of Kelsus.

Chris: Yeah. It’s one of those things where there’s certain things that just always stick out. In that particular case that you’re talking about, I think that was actually a bug that was causing a problem, and then I went and looked at the […] and when I saw, I was like, “Oh, come on. This is not good.”

Jon: […] five years ago. I just remember seeing that and being, “Whoa.” Because (a) I knew you were not an iOS developer so I really didn’t expect you to be looking at the iOS code. The other thing was sort of like, “Ha, I wasn’t even reviewing […] myself.” I was just doing some testing, some black box testing, but I was not looking at its code. It was like, “Come on, Jon. You know better. You should be helping that […] and the other people in the team are looking at their code and giving examples of what to do.” In my prior experience, I had seen that whenever I write code or there’s another guy that we worked a lot with Kevin Barnes, whenever he would write a code, all of a sudden, the code of the rest of the team will start to look a lot like mine or like Kevin’s.

I was like, “Okay. The team is learning by example.” All of a sudden, Chris jumps in and he’s a like new example and shocked me with his quick mastery of Objective-C which is a pretty opaque language. If you’ve never looked at Objective-C and you look at it for the first time, it’s hard to tell what function call even is. First was his quick mastery of that and second was he was really paying attention to our quality. I knew we could just wing it with Nick and Chris on the team. That one moment led to eventually Chris joining Kelsus. If you had not done that, I don’t think we would have ever worked together.  Isn’t that wild?

Chris: Yeah. For sure. You never know the path you go down and what with the background and what not.

Jon: Right. It was you doing some feedback and ended up creating this great respect. Chris is really with it. Then you joined us, and as you said already, you knew to expect the unexpected. I think your first experience really working with us was actually meeting everybody in person. How did that impact you? What was your takeaway from that?

Chris: Timing worked up pretty nice. I joined in January, I had a couple weeks of getting settled in the team and networking on the virtual team and really interacting day to day via video calls with this team that’s down in Argentina, but then about two weeks or three weeks later, we had an offsite in-person, but we all met down in Uruguay and I got to meet everyone face to face and spent a week down there with folks, getting to know them and their families, and whatnot. From a timing standpoint, very fortuitous. It helped establish does bonds and relationships, understanding some of the nuances, the cultural differences, and whatnot. It was just a great experience for me, for sure.

Jon: I think one of the things I recall you telling me, maybe you were just being nice to the new boss because that was the beginning of us working together. You said to me something more or less along the lines of, “I haven’t really had the experience where I’d like spending time and being around my fellow colleagues before.” Can you elaborate on that?

Chris: Yeah, I was totally lying. No, I meant it. I think this really goes to the really great advantages that I’ve come to appreciate working with international teams and especially our team in Argentina is the cultural differences. Here in the US, I’ve worked on very stressful, high-performing, high-demanding teams where it’s kind of you are competing against your fellow developers. There’s very real money on the line. Your career is on the line, stock options, bonuses. You are stackering against each other, so it really creates this culture of pitting you against each other. You’re in that really high-stress, frenzy environment. The last thing I want to do is go hang out with these kinds of people right at the movies or something like that. It kind of discourages those emotional connections, the empathy. It very much dissuades that.

Jon: Right. The real players in a team like that, do you create the close bonds and then undercut each other.

Chris: The backstabbers. There’s all that, right?

Jon: Yup.

Chris: You can play the politics game and I’m not just good at that. It feels so wrong to do that. With the coming of speed, mainly in the team in Argentina, the thing that really struck me is, “That’s not the culture they have.” It’s a we instead of an I type of philosophy. They love being just being with each other and working together and the wins are celebrated as group wins not as individual wins. They don’t see each other as adversaries. They truly see themselves as a group of people, and to a huge extent, friends come first then work. Not to say that they don’t work hard or they’re very much high-growth mindset. They love to learn and collaborate. It’s just a different cultural feel to it.

Jon: You just mentioned something about celebrating wins as a group wins, and literally today, I was just talking to […] and I was like, they were doing a direct messaging feature for ZooPix which is going to be awesome. It’s going to be so cool for people in ZooPix to be able to just have conversations with each other outside the public view, but it’s been a bare and I just know it’s been a drag for everyone so I was like, “[…], when you finish that, maybe you should have a celebration for the team.” Then it just occurred to me, I was like, “Oh, maybe you should just include everybody else in the company too.” […] was like, “That would be awesome,” and then it was like, “Yeah, of course, you have to include the whole company because that’s just how it works.” You can’t have the ZooPix team have a celebration off by themselves. It’s a company win.

Chris: Right.

Jon: Okay. I realize I interrupted you, and I don’t remember exactly the point you are trying to make, but we are on this thing of your first impression of meeting the team and the group mentality that they had. I want to rewind with my first impressions of meeting the team because I met the core members of the team all at the same time just many years before you did. I just want to tell that story really quick because it was a similar story for me.

I was an individual contractor living in Uruguay with my wife. I had come from doing business development and product management at startups and before that development in Denver. We are spending a year in Uruguay just for fun, and I got asked by my client Tasks, which no longer exist unfortunately, but they asked me to go over to Argentina to hire a team. Actually, I’ll be very specific. Roshan Cholas who is still on the team was the sister-in-law of one of the founders of […] and she was moving to Argentina from San Diego to live there. She was going to marry […], they’re married to this day, and he was going to be a seat member of a team in Argentina and software developers for […] and they were going to do Flex, Adobe Flex.

Then Kevin was like, “Jon, go to Argentina and hire a team of Flex developers,” because Roshan was a civil engineer and didn’t have the skillset to be able to hire a team. I flew from Montevideo to Resistencia, Argentina and […] had put a position description into this university, this National Technical University in Resistencia, and said that I was available for doing interviews.

The first ever person I interviewed—maybe not the first person—but I think Federico Tukey was the first person I interviewed. I was just like, “Wow, cool. This guy is really enthusiastic. He has the fundamentals needed to be a software developer.” Of course, he doesn’t know Flex and his work experience was this awful, terrible Java program that he had been working on for some company or government entity. It was so bad. It was like, “Whoa, I have not seen a software this bad since college.”

Then Fede got all his friends to interview too. There’s […], Raul Herrmann, Rodrigo Bechara, and Jonathan Diaz. All of those people interviewed. […] is no longer with Kelsus because he moved to Ireland. Got this really cool job in Ireland working for one of the biggest conferences in the world, but everybody else—Johnny, Raul, and Rodrigo—are still with us. Actually, I didn’t choose Rodrigo at first. I could tell that this was really hurting Fede’s feelings that I didn’t pick Rodrigo and it was a mistake because Rodrigo is one of our best people. I just wasn’t seeing his dedication and passion for software development come through that interview so I decided not to go with him and Fede’s like, “No, Rodrigo is one of the best. You should hire him.” Later we did.

You just talked about how this group seems to care about each other and really, I hesitate to say family because there’s a sort of a negative connotation, especially in the US of saying your team is a family, that’s against the rules in the US, but that’s sort of the vibe I got.

Chris: Yeah. That’s definitely the vibe that I got in meeting them in-person in Uruguay. Little things just blew me away. Like sitting at the dinner table and someone noticing that someone’s glass is not full and refilling the water in their glass. Just watching over each other, that was just mind-blowing to me.

Jon: Right on. We’ve established that there’s this different culture in Argentina in particular maybe just even the northern part of Argentina and maybe just this particular group of people, but I think the key is that different places have different cultural aspects. At the end of the day, there’s still a need to be a high-performing software development team that has specific requirements. There are certain things you have to do to be a high-performing software development team despite or your culture doesn’t really matter to that. You still have to do those things.

Chris: Right. It definitely wasn’t all roses, right? It’s like some of those initial impressions that I had of the differences between US-based teams versus international teams was true. There are a lot of great positive aspects that surprise me. Assets, strengths to be leveraged, but then also looking at the tools and technologies, the processes that people are using to develop software’s, it definitely wasn’t at the level that I was used to. Definitely some challenges there is like, “Okay, how do we level up? How do we marry the best of both worlds?” Become a high performing team without being a bunch of ego-centered jerks better in a doggy dog world.

Jon: I want to get this point in to because I think this underscores why were even talking about this. It’s been my experience and it’s our theory I think that time spent in a high-performing team is the best indicator of software skills. It’s more than what university you went to. It’s more than what your GitHub Repository has in it. It’s more than what Udacity and Udemy courses you got in. In fact, those even maybe even make you worse sometimes. The best indicator of whether somebody has a lot of skill in software is how much time they’ve spent on high-performing teams. Agreed, Chris?

Chris: I think it’s definitely a very good indicator because by nature, high-performing teams, if someone is underperforming or is just not at the same level, they’re going to get weeded out pretty quickly, attrition will happen. If you are part of a high-performing team and you stay there, it means that you’re probably a valued contributor and you’re performing at that same level. If you’re not, if it was a hiring mistake or you’re just not able to perform at that level or kind of hide behind other people’s work, people smell that and they know that. There’s also the resentment that comes on to play too. If you joined a high-performing team and then have actually stayed on that high performing team for some amount of time, that’s a very good indication.

Jon: Right, that’s our theory and then you come in and see this group of people that loves working together and loves helping each other out and essentially what you want to do is you want to apply what you learned in the high-performing team to this team, right?

Chris: Absolutely. Yeah.

Jon: Rich, how long have we been talking now?

Rich: Going on about 30 minutes.

Jon: At this point we’ve laid the groundwork and we know where you came from and what your expectations are, I think it’s just been a fun story. I think what we should do is maybe finish off the story if there are other parts of the story that we should tell and maybe next week we can talk about, “Okay enough story time, how do you make a high performing team.”

Chris: I think we’ve covered the landscape there. It’s the typical US-based teams, expectations, culture and how folks work and this biased against offshore remote teams as being cheaper and quality not as high, not capable of doing the heavier lifting type of thing, and it definitely doesn’t have to be that way. At Kelsus, we’ve been fortunate to leverage some of these strengths and assets that come from this remote international teams, and then have the mentoring, coaching, the growth hacking, the growth mindset to level up and become a high-performing team. How do you do that? We’re still on that journey. We’ve come a long way. We can get into some of the practicalities on that next time.

Jon: Yeah, I think let’s do that. In order to finish up story time though, I think there’s one other story I want to tell to make one other point about high-performing teams. That’s a story about a small group of smart people over a short time can produce just about as well as a high-performing team without doing the right things and someone has to tell a story about that because it’s not the same.

This is sort of a fake high-performing team. We worked with a team at Intel few years ago towards the end of 2015, beginning of 2016 to produce musical experience for the keynote that the Intel is giving at CES, the Consumer Electronic Showcase, the biggest conference in the world, 600,000 attendees across 20 hotels in Vegas. It’s ridiculous, it’s so big. They were giving one of the keynotes and I don’t even know how many keynotes there were if it was the main one or there were 500 keynotes. All I knew was it Intel’s keynote and it was one of the first keynotes at the conference and it felt important to me.

What I found when we joined that team was that they were basically a bunch of really smart people that were driven by just a kind of an ego-centrical leader who was just going to keep adding until it was too late to add anymore. That was his mentality, “What can I squeeze into this thing and how much more can I add to it until it’s basically showtime?” I was like, “What is happening here? I think we did use Git but it wasn’t even Intel one. It was some smart developer that I had worked with previously, we better use a repository.

Then we had no communication, but that same developer was like, “I just made my own personal […].” I was like, “Really?” and he was just like, “Let’s have this lighting feature. Let’s have this new configuration. Let’s build a monitoring system.” We just kept being, “Okay, we’ll just try to add it and layer and layer more features just getting added to the point where in order to get the thing done, everybody had to stay in Las Vegas. Fortunately, at the Venetian for 14 days leading at the CES. Fourteen days straight and each of those 14 days we worked at least 12 hours, thank God Kelsus was charged by the hour. 

That was it and it was Fede and me in Vegas trying our best to save the world and to do heroics  to get the thing done. In the end, it went off. I’m not going to say it went off without a hitch, but we did the performance and the keynotes was more or less a success. I think it could be successful with a little bit more discipline, but that is a surrogate for a high-performing team. It was a team of smart people that got a lot done in a very short amount of time with heroics. What we are talking about when we talk about high-performing teams is not that. A high-performing team is able to sustain high performance and you can only do what I said for a short time.

Chris: Yeah. You are also rolling the dice. You’re not going to be, like in that particular case, it kind of worked out well, but it could have easily gone the other way and could have been a disaster.

Jon: Yes, exactly. We’ll talk more next week. It’s going to be some sort of the things we talked about that make a great software developer, but more specific to remote and independent developers. People are out there on their own and doing this for Kelsus. Looking forward to that.

Chris: Absolutely. See you next week.

Jon: Yeah, talk to you next week, Chris. Thanks.

Rich: Later.

Jon: See you, Rich.

Rich: Well dear listener, you made it to the end. We appreciate your time and invite you to continue the conversation with us online. This episode, along with show notes and other valuable resources is available at mobycast.fm/71. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you and we’ll see you again next week.