Managing Global Software Development – Nate Dow, BairesDev

This is Techron tv. Hey guys, thanks for the throw. We are here with Nate Dow, who's director of Technology for Bears Dev, and we're talking about how software development has gone global and the challenges that come with that.

Hey, Nate, welcome to show. Hey, Mike, thanks for having me. Really appreciate it.

We saw maybe in Covid times things really took off where people were looking for talent wherever they could find it, but has that become a permanent state of affairs? And if so, where are we finding talent these days around the world? Where's the best place to go looking for software developers?

Great question. Uh, COVID definitely provided some very heavy tailwinds. Uh, there's no doubt about that.

Ultimately, it comes down to organizational culture as what we're seeing. Many of our clients that, that we picked up during, uh, the Covid era are realizing the benefits of having a fully distributed team, uh, across, in our case, Latin America. But we have seen a bit of a slowdown as some of the larger corporations, especially return to a an in-office policy.

What I, what I see anecdotally is that smaller organizations that are a little more flexible with their work from home, uh, policies that can actually be a competitive advantage for, for maybe the little guy, uh, as we see more and more larger organizations enforcing the work from office or hybrid approach. So there's definitely still room for, for the fully remote workers. We, ourselves are a fully distributed team across many countries and many states in the us.

Uh, but it's, it's definitely slowed down since the Covid era. Are there best practices for doing this, or maybe best advice? 'cause it seems like people struggle with everything from language to time zones and whatcha gonna do to kind of culturally prepare your organization to operate on a global level like this?

That's a good question. Uh, part of it is having a mindset that is very collaborative, uh, and inclusive. Understanding that there are gonna be cultural differences always, but also understanding that different parts of the world will have different cultural differences.

Um, one of the benefits of of working with Latin American based resources is it typically minimizes some of those cultural differences, right? Similar TV shows, uh, similar, similar jokes can be told and, and context is a little bit easier to understand. So I would recommend that anybody that's looking to, to expand to a global team understands the culture of the areas of the world that they're hiring from.

Uh, and also I will say that making an effort to, to learn a language, uh, that maybe even if English is the first language that's spoken on the team, uh, breaking the ice with, with some Spanish or, or Portuguese, um, and just being able to say hello and, and your team members' native tongue, uh, that can also go a long way for building culture. Do folks wind up traveling anyway to visit each other to establish some sort of, uh, personal relationship? Or is it all virtual?

The vast majority is virtual. And during the pandemic, uh, as an organization, we would do everything remotely, as many of us had to. As we've returned to a, a more normalized, uh, work environment where, where travel is accessible, we prefer to have at least some of our development, especially in the beginning phases, uh, kind of kick off the engagement with, with in-person, uh, meetings.

We find that being in a room together and whiteboarding, uh, going out to dinner and, and building those relationships, shaking hands, uh, can increase a team's chemistry and then carrying that on throughout the engagement as they are then fully remote. Uh, we, we find great success with that. Obviously we're biased towards that fully remote, uh, culture thereafter, but even then, we like to sit down with our clients and with our, our engineers that we have, um, face-to-face whenever we can.

A lot of organizations will have fairly structured DevOps workflows. Um, what does it take to onboard people from different cultures and different locations and that kind of process? What, you know, what have you seen, what works, what doesn't?

Yeah, that's, that is a really good question. Uh, I mean, at any given time, we have four to 500 projects going on, so a lot of, a lot of it ends up being communication, uh, and understanding and documenting what a client's DevOps workflow entails, right? And then also on our side, being able to bring the expertise, uh, in a collaborative nature from our own DevOps professionals.

Uh, what that ends up looking like is, is just a lot of communication upfront. Uh, part of my role is understanding what the technologies and best practices of an organization might be before we go matchmaking with, uh, a DevOps professional for our own talent pool. Uh, so I'll just reiterate that again, though.

Communication is key in any aspect of, of software development, but especially in, uh, the merging of DevOps cultures. So you have multiple projects going multiple times with multiple team members, and they're working with organizations on the backend that probably have their own DevOps workflows. So how do you kind of stitch all that together in a way that is cohesive?

I get the communication part of it, but is there any kinda, um, mechanisms for integration or sharing or, or platforms that you're kind of especially fond of, or for all? I know you rolled your own, but, um, you know, walk me through it a little bit. Yeah, we use industry best practices and tooling depending on the client, and it also depends on how we're interfacing with our client.

Uh, for example, if we're going with a staff augmentation approach where they say, Hey, we need DevOps engineers and they're going to manage those engineers, we would expect 'em to onboard just, just as they would any other full-time employee, right? Integrating with their systems and understanding the tooling beforehand, um, as part of that. But then taking the, the DevOps engineer and managing them as if they are a full-time employee, uh, working in their own system.

That's the expectation there. If we are managing the project end to end, uh, DevOps is going to be a key part of our design and discovery phase that we discuss, uh, and make sure that we align, uh, during the design discovery sprint, usually a two week period, uh, where we're coming up with a technical architecture document, communication plan, making sure that we have a groom backlog, including any sort of DevOps, uh, activities or aspects of the project that need to be confronted in the beginning. As far as, uh, you know, an internal tool or internal, uh, mechanism that we've developed, we, we look towards third parties when it comes to specific software tooling.

We're not in the business necessarily of developing, uh, DevOps tooling ourselves, and we try to take it on a case by case model based on our client's needs. How hard is it to find developer talent these days and DevOps professionals specifically, but is it still, uh, pretty much a favoring the employee or has the economics of the world changed a little bit and it's getting easier for you guys to find these people? Great question.

I would say it is still highly competitive, especially in the DevOps realm. Uh, as, as more and more organizations look to adopt, uh, a DevOps mindset and realize the benefits of continuous integration, continuous delivery, uh, that's still a highly competitive area. But to your point, we've seen macro economic trends that have freed up, uh, developers, uh, across the board, whether that's in the DevOps area, whether that's in more of your traditional front end or backend, uh, engineering resources.

There has been, uh, a loosening in the demand, definitely not what we were experiencing uh, two years ago, for example. Uh, but still in very high demand. You cannot walk down the street without somebody telling you about their great new AI thing.

How do you think AI will play out in, uh, DevOps these days? And what might be the impact on skills, requirements, expertise? How do you think this is all gonna look someday?

I really see AI automating a way, a lot of the redundant tasks, uh, at least the good products, the good AI products that will eventually be adopted by developers are the ones that will be able to automate the redundant menial tasks that a DevOps engineer doesn't want to do. Uh, part of that is the nature of DevOps itself and, and its automated nature. Um, but part of that too is just understanding, I think AI product owners will need to understand that that's, that's where AI can really benefit these highly skilled engineers, where they can go off and solve the more complex, uh, intellectual problems that AI isn't capable of solving today.

Uh, in the long run, we'll just see more and more automation. Obviously AI will continue to increase in its capability, uh, to take on more and more of those tasks. I imagine that the DevOps role will evolve as the, the DevOps tooling continues to adopt this ai, how it evolves, that's the million dollar question.

Um, generally speaking though, the lowest hanging fruit for those repetitive tasks that, that DevOps engineers don't wanna do, uh, and then complexity will, will continue to increase, uh, within those AI tools Beyond the automation and the workflows. We're also gonna see, I think AI models will be embedded into just about every application there is eventually. And, um, today those AI models are built largely by data scientists using things called ML ops as practices.

And then there's data engineers running around who are doing data ops, and then we got our DevOps folks, and then there's a few security people running around doing DevSecOps. Is all this stuff gonna converge at some point? Will dis evolve into, I don't know, ML ops, DevSecOps something or whatever, however we wanna describe it, but it feels like there's a certain amount of, um, a, a greater need for cohesion.

I think you're right in the sense that the trend is definitely towards a, a convergence, uh, of these different practices. And what we see with software tooling in general is a democratization of capability right now. A a solid full stack engineer can access, uh, open AI's APIs and, uh, leverage large language models, for example.

And so in that same way where that wasn't a possibility just a few years ago, uh, I think we're gonna see more and more of, uh, the enabling of a traditional DevOps engineer that might be able to wear more of an ML ops hat might be able to wear more of a DevSecOps hat as the tooling becomes more, uh, enabling for people with those baseline skill sets that can then cross skill and be proficient as an ML ops engineer with, I would say, less, uh, of a, a barrier to entry after having those initial skill sets. So I think you're right in the assumption that there is a convergence, um, how much a convergence to where you, you know, you'll only need one engineer to do everything. I don't, I don't know that that's, uh, where we're at today for sure.

Uh, but it is heading in that direction of, of one engineer being able to fill, uh, multiple needs because of this tooling that's enabled largely by ai. Last comment, globalization, um, has been with us for some time now. It seems like more of the software projects that are being built and deployed spanned multiple countries.

So are we seeing this trend towards where we need DevOps teams that are made up of folks from different countries because, well, the software's just that much more distributed and going into different environments and different places and, you know, it's not all running in the cloud, it's kinda everywhere these days. There are definitely pros and cons, uh, to that. I would say that as much as we might think we need people in, in physical locations around the world, kind of a follow the sun model, if you will, um, it's obviously very dependent on the, the use case of an organization.

Um, the, the simple answer is yes, especially if you're managing, um, on-premise resources that that need attention and you have, you're supporting, uh, users in different time zones around the world. Globalization is, is a bit of a no brainer, uh, in, in that regard. If, where a lot of times organizations are supporting mainly, uh, north American time zones, you can still go global, north and south.

Maybe that makes more sense than going east to west. Um, but it really depends on the organization's span, uh, and also the intensity of which the infrastructure needs to be tended to, Right? Folks, you're heard it here.

They say software's eating the world, but I might argue it's also making it smaller. So hopefully we can all just figure out ways to work together and go from there. Hey Nate, thanks for being on the show.

Hey, thanks for having me, Mike. Really appreciate it. All right, and back to you guys in the studio.