Growth Hacking for Remote and International Developers – Part II [Podcast Transcript]

Chris Hickman and Jon Christensen of Kelsus and Rich Staats of Secret Stache continue their  discussion on growing high-performing remote and international engineering teams.

Some of the highlights of the show include:

Current Culture and Change Perspective: Identify processes, strengths, areas for improvement, attitude, and environment related to people and technology

Level Up: Teach, mentor, and build team’s strengths to make world-class developers 

Reasons for Remote Teams: Costs less - not necessarily; a remote team can cost more, if not done well and hire amateurs, not professionals

Challenge of Retention: People move on to the next best offer; developers tend to be attracted to brands and money

Developer Shortage: Top talent is attracted to top companies; 80-90% more interested in working for top-tier U.S. companies and leaves 10-20% of top developers available 

Supply and Demand: Smart and capable people are available for remote offshore teams, but technology must overcome ecosystem 

Positive Attributes for Remote Workers: Strong communication and soft skills, high emotional intelligence (EQ), work independently, able to manage time, and trustworthy 

Growth Plan: As part of learning and training process, lead by doing, conduct code reviews, and hold regular meetings and discussions 

Anyone can be a Leader: Step up, take initiative; and understand the difference  between a manager and leader

Key to Kelsus’ Arsenal: Off-site retreats to get together, learn, engage, be productive 

Links and Resources

Transcription

Rich: In Episode 72 of Mobycast, we dive into part two of our discussion on growing high performing 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, Rich. It’s another episode of Mobycast.

Rich: Hey.

Chris: Hey, guys. It’s good to be back.

Jon: Good to have you back. Rich, what have you been up to?

Rich: Oh, last couple of weeks, I’ve been recruiting another developer, looking for a front end advanced JavaScript developer to integrate with some of the WordPress work that we’re doing. That’s been a challenge just trying to find the right person at the right price point for us.

Jon: When you first said that, I was imagining HBO’s Ballers and I was imagining you doing all kinds of major big things to recruit the developer like courtside tickets, concert passes.

Rich: Yeah. We have a recruiter that looks down in South America and Central America who we worked with in the past, but the guy who we ended up, at least, we’re in a trial with, he’s in Canada. He’s in my timezone, too, so that’ll be nice. He’ll be our first Canadian developer, not that it really matters but we’ll see.

Jon: That sounds great. How about you, Chris?

Chris: Recently, I got to do something fun, interesting, and different for me. I was a guest on Bret Fisher’s live YouTube channel. It’s stepped out from behind the microphone, in front of the video camera, so no jokes about having a face for radio versus video, please, but it was fun and interesting. If folks want to go check it out, it’s Bret Fisher on YouTube, DevOps. Bret is very well known in the Docker community. That’s how I met him at DockerCon.

Jon: Yeah. I watched that and I thought you did a great job. I thought you were very presentable. It was fun to watch it and thank you for plugging Mobycast in there and thanks, Bret for having Chris on. It was pretty cool.

Chris: Absolutely.

Jon: As for me, I told you a couple of weeks ago that I got that new raft. Yesterday, we’ve found that we got both ends of the spectrum of my family’s rafting capability completely taken care of. A couple of weeks ago, we did some flat water, had a good time, splashed around, and it was easy. This weekend, we decided to do something more challenging and, let’s just say everybody was safe, but there was some luck involved with being safe. It really wasn’t that big of a trip we did, but I don’t think we’re going to go back to it.

Chris: It’s good to know your limits.

Jon: It’s not something because we are a little older, but yeah, we had fun. Today, we’re going to talk about remote developers again. It could be remote in the US or remote international. Last time we talked about how you and I, Chris, have come to work with remote developers and for me it was the story of doing that over my whole career and for you, it was a more recent story.

I was really interested in talking to you about that because you, coming to it more recently just have that new eyes for it whereas I’m so close to it, I can’t really see the difference almost. It’s been so many years since I haven’t worked with the remote developers all the time. But it’s interesting just to see somebody who’s new to it, who are used to working with local teams and how that changes your perspective on things. That was fun.

Basically, we’re still testing this hypothesis that we believe that the time that people spend on high-performing teams—there’s nothing to say that remote teams can’t be high-performing, they absolutely can—is a big indicator on their software development skills and ability. We also think that even though there’s no reason that remote developers can’t be high-performing, that it’s a little more difficult to get there. There’s not the support infrastructure for remote developers to learn the same things that somebody that’s working at Netflix or Microsoft might learn.

Today, we’ll get into a little bit more of the nuts and bolts of what you did specifically, Chris, with the Kelsus team when you got on board to help turn it from a mid- to high-level performing team to more of a high-performing team. Let’s go ahead and get started, maybe you can kick us off with that, Chris.

Chris: Yeah. As you mentioned, my background had been more with co-located folks on teams, a broad spectrum of different companies and teams that I had been in coming into Kelsus, definitely quite different with the team that was thousands of miles away and really only communicating via instant messaging,video calls, and whatnot. Coming in, just taking a survey of the land, understanding the culture, looking and spending some time just figuring out like, “Okay, what is the current culture that’s in place?” learning a bit more about this new team that I’ll be working with, what are the strengths, and then also what are some things that we can work on?

We talked a little bit about this in the previous episode where there were some really great core strengths there just from a cultural attitude standpoint, very much a team-oriented atmosphere, very collaborative, very receptive to mentoring, learning new things, and not very big egos. All just really, really great things.

On the other hand, the tech stack, some of the processes, and whatnot, definitely not what I was used to at other teams that I’ve worked with. That was the challenge is given this virtual remote team that’s thousands of miles away, how do we leverage those strengths, those really great assets to bring it up a level and just level everyone up. That was the first part is just getting a survey of the land, understanding the team, understanding their personalities like we talked about previously. The timing was fortuitous and we had our off-site retreat down in Uruguay and we got to hang out for a week. It was really great solidifying those relationships and kicking it off from there.

At that point in time, we weren’t really using the cloud heavily or as heavily as we could. Things we weren’t really using, containerization, and docker at that point. We had a very strong background in developing mobile apps and starting to get more into the into web apps, but still not really having a core strength and just running distributed systems and back-end services. Then also just this idea of running an operating production software was not really there as well. Those are the things looking at how do we go ahead and start teaching, mentoring, and building those strengths on the team to really complete that and turn them from, as you said, mid to high to really a world-class development team.

Jon: Let’s just talk about remote teams in general for a second because I think that we needed to dispel some rumors. I think our listeners probably don’t have the same rumors that are out there in the market, but it’s why remote teams in the first place? I think the thing we need to dispel is it’s not because it’s cheaper, that is not the only thing, and it doesn’t necessarily end up cheaper, in fact, a lot of times a remote team can cause quite a bit more spend if it’s not done well. Getting cheaper developers is not really the answer. If you’re doing that, you’re doing software development for the wrong reasons.

Chris: Maybe just to add, I think a lot of people, that is their mindset. That’s what they go […] or it’s like “I want to save money so I’m going to go have a remote offshore team.” As you point out, that’s not the best way to look at it. You’re probably going to get bit pretty bad. We’ve all seen the memes of what happens when you hire the amateur versus the professional type thing. There are other really good reasons for having a remote distributed team.

Jon: The thing I’ve been saying recently, Chris, and I honestly believe this, is with a developer shortage in the United States and with the way that the United States works where top talent is really attracted to top companies, be it startup unicorns or well-established companies like Netflix, Google, Facebook, and Amazon, Apple, the top tier of developers in the United States has almost entirely spoken for that. Not entirely. There’s obviously really great developers that are working for some consulting companies in the United States. But let’s say, you have 100 top developers. I would say 80% to 90% of them are going to be more interested in working for those top-tier US companies than not. That leaves you with only 10% or 20% of the top developers even available for non-top-tier work in the United States, would you agree with that, Chris?

Chris: I would say definitely in the US market, in the top 20 cities of metro areas where the jobs are in tech is strong, you don’t have to be a great developer. If you’re a good developer, you have a job and you’re probably switching jobs every two or three years for […]. Retention is a challenge for a lot of companies and they just don’t realize it’s just a constant flow just because everyone’s just moving around to the next best offer. Definitely true in those top 20–25 markets.

Jon: Yeah. Those developers are largely attracted to brands and money. Slack just came into Denver, they had an open house last week and it was well-attended.

Chris: I know in the Valley, especially, people see all the wealth that’s been generated there and just all the multi-millionaires and billionaires. A lot of folks, they’ll go join a startup. As soon as they start smelling this startup’s not going to pan out, it’s not going to be the big home run, they go on to some other one. It’s not just the current offer or buzz, but also just like, “Hey, is this going to be the big home run? If it’s not, I’m moving on.”

Jon: Right. If you go to the non-top 20 cities in the United States or other non-top cities of the world, not London, not Buenos Aires, not São Paulo—for Kelsus, that’s residency in Argentina or Corrientes in Argentina—but other places where just by the laws of nature, there are super smart people, super-capable people living there, but those same companies are not hiring in those locations. All of a sudden you have a greater percentage of those super smart people available to potentially do work. It actually is easier to find and hire really good intelligent great developers in those places than it is to go to San Francisco and hire somebody for your new startup project or hire somebody for your middle midsize enterprise project.

Chris: Absolutely. Supply and demand. In the top-tier cities, the demand is extremely high and the supply is pretty much fixed and demand outstripped supply versus in those other places, the demand is not as high just because it doesn’t have the ecosystems there in place. But thanks to technology, now we can get beyond that and we can tap into that. That’s the nut here that we’re talking about.

Jon: Right. I would say slightly unfortunately, there is a bit of a higher bar when hiring remote. I think there are people that can be really successful in on-site types of companies that have a hard time working remotely. Maybe if you could talk a little bit about some of the attributes of somebody that can work remotely successfully, Chris?

Chris: Yeah. There are quite a few things here that go into it, but a lot of it is actually not really—

Jon: Remote specific?

Chris: Not any of that. It’s not really even hardcore tech, specifically.

Jon: Exactly.

Chris: Soft skills are really, really important when it comes to working on a remote team. When you’re physically co-located with someone, being able to read body language and communicating face-to-face, you don’t have to be as adept with some of those soft skills versus if you’re communicating via text, instant messaging, or even video calls, you have to be more empathetic, you have to have those better soft skills. That’s definitely one of the things that go into being a really good remote team player is you need high EQ (emotional intelligence), need to have a bit more balance to balancing at the technical with the emotional. Good communication skills are just so important because you’re going to be spending a lot of your time just doing that or just communicating with your teammates that are spread all over the place.

Letting them know what’s going on, what you’re working on, when you have problems getting the help, not being careful with your communication, and clear and concise with your communication so that people don’t read it the wrong way, and then you start creating problems that way. Good communication is really, really important.

Another thing that’s obviously pretty big here is the ability to work independently. Managing your time, when you commit to things and actually doing them, standing by like what people are expecting of you, not getting distracted even though that you’re not physically co-located with the rest of your team, we’re still here to get a job done.

Jon: I think what goes along with that is trust, too. When you work by yourself, on your own, somehow, is signaling and by actual work getting done, but also by your presence and by your letting people know when you’re coming and going that builds some trust with the people that you’re working with that you focus and care about the job.

Chris: Absolutely. Some of their attributes, just that growth mindset, and realizing that continuous learning is very important, is a part of that. You have to be an expert learner. You have to know how to learn and be able to self-teach, learn new technologies, new skills, and keeping up to date with what’s going on in the whole community. For some people, that’s hard. It’s a lot.

Some people, it’s just a lot easier just to tell me what to do and I can sit through training classes or something like that or maybe it’s going to a conference, but if you’re on a remote team, it’s definitely much more self-directed and it’s up to you, the onus is on you to do that self-development. Definitely, things like a positive attitude and help out go a long way here. There’s a lot of overlap, obviously, with folks that are not remote.

Jon: Right. None of these things would hurt in a local job.

Chris: Right. The magnifying lens just makes these much more critical with remote players. Then just awareness and sensitivity to your other teammates and other cultures and whatnot. Just the idea that we are a team, there is a lot of collaboration, there’s really no room for the really super smart arrogant jerk. That’s way too high of a cost. We want to have fun while working together, we need to do it as adults, and play well with each other. Those soft skills really come into play here.

Jon: Right. I just want to repeat one of those one more time because it’s so critical. It’s the communication, the written and verbal communication skills. As you were talking about that, I was thinking back through many of the best developers that I’ve worked with and thought some of them maybe weren’t really any better technically than some other people that didn’t come to mind right away.

Maybe if you were measured, it would be like how hard a problem can you solve, how many user stories are you getting, what amount of time with how few bugs kind of thing, and how maintainable is your code at the end of it all, if those were the measurements. If two people were equal in all those technical things, I’m definitely putting the one that is better able to communicate what they’re working on and the problems that are arising and the things that are going on in their mind significantly higher than the one that can’t. That’s just so critical.

Chris: Absolutely.

Jon: Great. We were lucky enough that when you joined, many of the team members, if not most had these things going on and we just needed to make some adjustments. What are some of the things that we did to cultivate those? What we were good at and work on what we needed to work on?

Chris: This goes back to what we talked about in the previous episode where my initial impression was that I was a bit blown away by just the culture, the team, and basically just all these attributes that we just went through. These were present and accounted for on the team. Just a really great place, a baseline to start with. It’s like, “What’s the growth plan look like? How do we now level up our team to have them be more cloud-native, to learn docker and containerization, why they should do it, how to do it, and how to operate that? How do they become better back-end distributed system developers? How do we get them to start taking the mentality of it’s not just delivering software, but now it’s also running production software, what does that mean?” The next step is like, “How are we going to do that? How are we going to level folks up? What does that growth plan look like?”

Part of this will be a little bit of a recap. We talked a bit about this back in episode 55 where we were discussing like, “Do these seven things to become a great software developer,” and we talked a little bit about what we’re doing at Kelsus. I deliver this growth plan to our developers, but I think it’s important enough that we can go through it in a bit more detail here, what we set up. I think maybe to start off, one of the biggest things that was done is leading by doing is really important here and not just telling people what to do, but to actually show them how to do it as well and to roll the sleeves and get in there with them.

One of the very first things we did was like, “Let’s introduce docker and containers. Let’s take some of these applications, these web apps that have been built and go ahead and containerize them and get those running in prod as containers.” That’s always a big step, teaching a team that hasn’t been using Docker and containers to now deal with that abstraction and just all the tooling that goes along with it, the developer mindset. We’ve covered this in previous episodes as well, that’s a big culture shift and process shift.

Jon: For it to come a little bit top-down was critical. A lot of changes you want to get the team to champion the change because then it’ll stick better, but this one, it had to be a little bit top-down, it had to be like, “Hey, team. I’m Chris. Good to meet you all. This is really important to me. I’m sorry, but I’m your new boss so we’re doing this and here, I’ll kick it off.”

You could do the same with a lot of different things maybe if it hadn’t been docker and containers, it could have been well-written unit tests, “Hey, I’m going to write the first 10 unit test. Take a look at how I did that and see how they’re put together. Use them as a template, but we’re doing this from now on,” as opposed to what I’ve seen, and I don’t mean for this to be an episode just for managers, but it makes sense for people that are listening as managers and also for people that are listening as individual contributors, this is what you want to see in your managers in order to make changes inside your team.

By doing it, you indicate how important it is and that you’re willing to spend time on it. If somebody’s like, “Hey, is everybody writing unit tests?” people might be like, “Yeah, yeah, yeah.” Meanwhile, they’re literally commenting it out of the CI/CD system because nobody got time for that. That happens if it’s not clearly important to the leadership. Docker and containerization were clearly important to you, so you take the time to work on it and make it part of CI/CD system.

Chris: Yeah. It’s important to let people know. You jump to sell them on the […] and why this is important. It’s not just, “Here, we have to do this,” but why? What’s the benefit? Why are we doing this? Definitely, that’s the key part of just about all these particular things that we’ve introduced with our team, with this growth plan, whether it be switching to docker and containers, one of the things right after that or concurrently we did with that was code reviews. When I first came on it, there may have been some code review process, but it definitely wasn’t treated as a first-class citizen.

That’s one of the things that just immediately stuck out as well. Let’s take this more seriously and let’s really do a good job with code reviews and what does that look like. Again that was rolling up the sleeves, getting in there, and spending a lot of time myself doing code reviews and showing people the difference between a thorough valuable code review versus one that’s really just checking off the checkboxes type thing. It’s also giving that rationale of why are we doing this? In the future, we’ll probably revisit this in-depth as well because code reviews are one of those things for me, personally that I came around on.

Jon: Right. […] at one point.

Chris: I was maybe a little bit of a chip on the shoulder, just like, “Oh, God. I don’t need code. My code’s perfect and it’s just slowing things down and whatnot.” A lot of things I was working more, I had a big piece of a system, I was the primary developer, I wasn’t working on large teams. But the more you’re working together as a team, the more people that are on the team, it becomes even more critical, so something to talk about in the future.

But here at Kelsus, it was definitely instrumental. Again, this growth plan for our developers is just by doing these thorough code reviews, pointing out just really key topics whether it be things like the importance of error validation server-side, not trusting any inputs even if the only clients accessing this might be clients that we’re writing, you still have to be very paranoid about that and sanitize your inputs on the server, things like what do you do when errors do happen? How do you handle that security type issues, readability, maintainability, coding standard?

All those things, just some core key principles that really go a long way into dealing with some of these challenges we have of leveling up. Code reviews were definitely a big important part of that process.

Jon: I guess, Chris, one of the things that’s occurred to me as you’re talking about this is that there may be some folks listening that are like, “Yeah, I could use some instruction and I wish I had a manager who’s been in and fought the hard fights, worked in a high-performing team, knows everything, knows all the best practices, and can teach me.” And then there may be other people that are like, “Yeah, I know this stuff. If I had a boss telling me to do this stuff, I’d be like, ‘Come on, I’m not a baby.’”

It’s really important to point out that what you were faced with was raw talent that needed being pulled up by their bootstraps help like, “Look, everybody, this is how high-performing teams are running, this is what we do, and I’m going to lead by example,” but for people that may be beyond that, that are doing code reviews and have a nice […] model, maybe they’re not looking for their manager to do this so much as lead from within like, “Hey, manager, this is how we’re taking care of ourselves and making sure that we’re a high-performing team. Support us on this.”

I just wanted to point out. It may be too subtle for a podcast, but it comes back to the leadership thing. When you see a team that needs direction, leading by example exactly like you did, working with raw talent and giving them what they need to succeed is how you do it, and then working with the team that knows already and just giving them the room is what they need.

Chris: Yeah. Anyone can be a leader. You just have to step up and take that initiative. It doesn’t have to be Mr. Manager. It can be someone else on the team. For the most part, there is a difference between a manager and a leader. There are reasons for having both in your organization. It just depends on your particular situation, whatnot, but someone has to do it.

Jon: Right. If you see a team that’s not doing these things, that are not acting like a high-performing team or not got all the pieces and parts in place that a high-performing team would have, then somebody, exactly, somebody has to take that leadership role.

Chris: Yeah. You might have teams that say, “We don’t need to do all this because we’re already a high performing team.” At that point, then you’re just saying, “Well, we’re perfect. We can’t improve.” It’s like ask yourself, “Really? Is that true?”

Jon: Right. It goes back to that story I told about. You can actually get away with it without doing any of this stuff. If you have a bunch of really talented people that are super smart, you can get away with it for a short amount of time and you can deliver a lot quickly. There may be times when that’s valuable like, “Let’s throw out all the process and crank out some code for two months.” Maybe every once in a while that’s worth it, but you have to know what you’re doing and it has to be a decision and not a default mode.

Chris: Right. Some addition to leading by example, showing people, giving them the rationale why we should be doing things these new ways, code reviews, one of the next things that we did was institute its concept of a monthly engineering team meeting where we dive deep into a particular topic that’s just part of the overall learning, training process. We made the decision like this was important enough that we’re going to carve out the time, I’m going to do it on a regular basis. It’s proved to be one of those things that, for the most part, it’s been valuable. It hasn’t been a waste of time. We have a lot of interesting discussions and we’ve covered a lot of pretty important topics. It’s been a useful addition to that growth plan for our developers.

Jon: I would say in addition to that, really pushing for having some of these technical conversations in our Slack has been useful. Don’t have secret meetings and direct messages, but actually talk through some issues in Slack and let people see it. It’s along the same lines because a lot of times, that’s what we do in the monthly engineering team session is talk through problems that we solved. Having that happen more than once a month, just on a daily basis has been huge for the team.

Chris: Absolutely. Getting back to the communication skills, with remote teams, especially, this is one of my pet peeves, just being really wary of having one-to-one conversations with people because the impact of that is magnified with a remote team versus in a co-located situation. If you’re in the hallway or in someone’s office, chances are there are other people around and having a true private one-to-one that other people aren’t really being able to take part in or at least just hear what’s going on is less likely versus if you’re in Slack and doing a DM, the point-to-point communication, no one else sees that. It could be something that’s really valuable for the rest of the team or other people to learn from. Having it in a public channel that others can see and just going through that process is great for so many reasons, whether it be learning or getting other ideas, other perspectives, or maybe tips on just how to fix it. So, super important.

Jon: Yeah, just […] visibility too, just straight up like, “Look, these people are working and talking about this.” It just helps.

Chris: Absolutely.

Jon: Another thing is we started doing one-on-one meetings. Maybe talk a little bit about why we did that.

Chris: This happened about a year into that process and kicked it off at our annual company retreat. We’re leaning up into that particular retreat. I know we were thinking about like, “How can we be more mindful and be a bit more structure around the growth of developers?” Realizing that there are definitely certain traits, characteristics, aspects in members of our team that we really want to encourage and we value. What do we, as Kelsus, as an engineering team, value? How do we want to see people grow? Realize that we need a bit of a framework here to actually formalize that so that people know what they need to be working towards.

We started off laying out a matrix for “these are the different levels, if you will, of developers and here are the characteristics and what their scope of influence is and the activities that they’re capable of doing and whatnot.” That led to the genesis of having these one-on-one sessions. The intent is to meet regularly, individually with our teammates and go through this and use this as a guideline for what’s their own customized personal development plan look like and how do they want to grow.

That’s evolved over time, especially with me personally, I definitely take an even more customized, flexible approach. The most important thing is just that personal development and really understanding each person and how they want to grow, what’s important to them and then also giving them feedback and guidance on making them the best developer or team member, whatever it is their role is that they can be here at Kelsus.

It’s evolved into this, “Let’s talk about how you want to grow, what are some of your objectives, longer-term,” and then breaking those down into shorter-term objectives. Have some goals, let’s have some concrete goals, let’s have some dates attached to them, and then we’ll regularly work on this and checkpoint over these one-on-one sessions. I’ve noticed with the folks that I’ve been talking with some common goals have been to become certified in AWS and the various certification levels that they have there, do things like […], this is one of the topics that you’re going to have to be able to really know inside and out for one of those exams. 

Go do a deep dive on it and for our next session, come back and teach me it as if I don’t know anything about it. I have them go through and just really describe that in detail and then I can ask questions back and forth about in. It’s been a really useful way for them to practice for these exams and to get into. It’s been really rewarding, too, to see folks go on and actually then sit for their exam and pass it and see the excitement in them and just that pride in passing the exam.

Jon: For sure and it affects the whole team. It’s great. That’s the point like high-performing teams impact each other to get even better.

Chris: Absolutely. Another common one has been just improving English skills. Our team is based in Argentina so Spanish is the first language, English is the second. Everyone speaks English and actually speaks pretty darn well, but they all can improve. Just about everyone that I’ve dealt with, […] everyone out there, they’ve identified this is that “No, it’s really important.” It is true and being in the software development world to have exposure to the most opportunities like English is the lingua franca. We talked about how important communication skills are so being able to communicate in English adeptly is really important.

We spend a lot of time just, “Okay, what does that mean to improve your English skills? How are you going to measure that? How are you going to know you’ve gotten better?” Having some goals and some metrics around that. Then, there’s a whole slew of different practices and activities people can do. We spend a lot of time just going through that. That’s been very, very interesting or rewarding as well to see people just grow and every time it becomes easier to communicate and talk with them.

Jon: Right. I was just listening yesterday to, I can’t remember, Hidden Brain, or something like that, one of those podcasts. No, it was a different one, but anyway, it was about baseball coaching and about how in the last five years or so, there’s been after Moneyball where teams were made with statistics. Now, individual coaching is done with instant feedback loops. People used to always think, “You might get a little better after you’re a major league player, but you’re essentially the […] casts, this is the kind of player you’re going to be. If you’re a medium level hitter, you’re always going to be a medium level hitter.” But as soon as they did this type of practice that you’re talking about that has very quick feedback cycles and lets you adjust and learn and have intentional practice, even major league players were significantly changing their capability. I can’t say enough about how important it is, that intentional practice.

Chris: Yeah. Part of this is growth mindset, too. A big part of that, especially with the baseball example, is people just said, “Oh, I’m mediocre.” They’ve been typecast. They’re a mediocre hitter and they’re there for their arm or they’re there for their fielding ability. That’s what they practice on is their fielding.

Jon: Even if […] get better at it, it seems that they can get better at fielding. That’s what they’re there for, their professional level, but even that, making it better.

Chris: Yeah. It totally applies here to team building and leveling up as a developer. Identify what those goals are that you want to improve on. This is not groundbreaking, this is not rocket science.

Jon: But it is. This is groundbreaking. We were not talking like this 10 years ago, 15 years ago, and now we are. That’s the new ground, it’s what’s possible. But once you know it, it’s like, “Oh, that’s obvious.”

Chris: Yeah, and just doing it, just sticking to it. You have to hold yourself accountable. You can’t just say you’re going to do something and set goals and then just like, “I was busy these last three weeks. I didn’t do anything.” You really have to make it a priority. If you are going to do it, if you have identified this as being a goal that’s important and you are going to commit to it, then commit and make time for it.

That’s another big thing that I’ve been working with folks is just how do you treat it as such? You need to carve this time out on your calendar. It’s important and you need to treat it as such. It’s not a hobby. It’s not a nice-to-have. Think of it as I-must-have.

Jon: We also give people access to online training. It goes back to this intentionality. Online training without intentionality almost makes people worse. Men, now, all of a sudden, they’re just chasing shiny courses, doing 20% of each training course and then they know not enough to be really useful at anything.

These are Pluralsight courses, Udemy, and Udacity courses that people take and it’s just like, “Come on.” They can be great, it can be really useful in an intentional practice, but otherwise, you might as well watch TV. Just go watch a cool series that’s really fun instead of spending a little bit of time dorking around on Udemy not really learning anything. Online training can be great with the right learning mindset, but otherwise, don’t spend your time on it without learning mindset.

Chris: Yeah. As you pointed out, be intentional. Understand why you should be doing that training. You’ve got to identify with it and you’ve got to understand the value to it and the practicality of it.

Jon: A lot of it is because it’s shiny like, “Oh, this AI thing would be so cool.” Yeah, it would be cool, but just be aware are you going to really do that? Starting down that road, it’s great, but realize that road is a long road. It could take a couple of years before you’re really an AI expert. Once you are, are you planning on making that your career? If you feel that’s great, go all in, just don’t go in 5%, 10%, 15% because you’re just wasting time.

Chris: Exactly. Maybe the last thing we can talk is just the off-site retreats that we instituted. This might have been an excuse for you, Jon, to say, “Hey, I’m going to go surfing in some really cool part of the world,” but it’s one of those things that’s just an awesome tool for us, again, being a completely remote distributed team to get together in person one time a year, hang out for a week, and having it be a combination of a bunch of different activities. Things like just hanging out and doing team building. But then, we also have lectures and we also have workshops. We’re doing learning, we’re doing that mentorship in getting better as a team, and having everyone together in the same room. There are some things that we can do just a lot better that’s grown over the years. We’ve done three of these retreats now. Each one gets a bit more streamlined, more productive, more engaging. It’s become key to the arsenal.

Jon: Right. Two-thirds of the time, the surf hasn’t really been that good anyway.

Rich: I know. It’s either too little surfer like the waves are just monster, right?

Jon: Right. All right. Thanks so much, Chris and thanks for putting this together, Rich. I guess I’ll give you one more closing argument if you’d like, Chris?

Chris: Again, just to sum up a little bit, just remote teams, distributed teams, and international teams have challenges, but there’s also just a lot of really great advantages to them as well and putting together that growth plan, having that intent behind it, can pay off immensely. Talent is global so don’t limit yourself by geographic boundaries. Again, using some of these techniques has been just incredibly rewarding for us and can be for anyone else.

Jon: Right. We can have a high-performing team and you can, too. We may be looking in the future at helping other people have this experience, so stand by. Thanks again and we’ll talk to you next week.

Chris: All right. See you. Bye.

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/72. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you. We’ll see you again next week.