Nearshore Software Development vs Building a Global Team

The idea of US companies using “nearshore” software development teams (i.e., teams in Latin America) over “offshore” ones (i.e., teams in Asia and Eastern Europe) started gaining popularity in the late ’90s.

That was around the time when Shiva Nathan, the Founder and CEO of Onymos, was taking on his first management role at Oracle. He said he felt pressure to try the buzzy new thing — instead, he did something completely different. 

But first, what makes “nearshoring” development so attractive? 

“It is usually about finding software engineers in a similar time zone to you. There is a night and day difference between working with an offshore team vs a nearshore team. Literally,” says Shiva. “If you are California-based, you are lucky if the overlap you have with an offshore team is two hours early in the morning and two hours late at night. On the other hand, you could get 50% or more overlap with a nearshore team in a working day.”

He adds, “People might be more inclined to use offshoring if they want round-the-clock support. In that case, it is less about collaboration and more about coverage. Sometimes, cultural similarities or language barriers may factor into these decisions, too.

“As far as the ‘code quality’ or ‘talent pool’ differences go, human beings are the same everywhere. If you go out and give them your spec, they will create things by the spec and give it back to you.”

Rejecting the typical “offshore” and “nearshore” paradigms

As Shiva explains it, by 1999, Oracle had long since standardized its outsourcing model. Part of that was treating its offshore software development teams like vendors or service providers — separate from Oracle as a whole.

Oracle teams would share a detailed project plan with an offshore team and wait for them to complete it. That was often the extent of their interaction. When the idea of deliberately pursuing “nearshoring” came up, Shiva wasn’t that interested. If you didn’t work closely with them anyway, what difference would it make?

“If you were an offshore developer, you were not treated as part of the core team. You were a hired gun of sorts. That creates a very specific dynamic. You had no investment in a project’s success after you handed the code over. I thought doing it that way incentivized people to minimize issues and race to the finish line for paydays.”

He wanted to do it differently. 

He proposed building an outsourced team that was globally distributed (to maximize coverage and collaboration over every 24-hour period) and treating them all like they worked for Oracle, not like third parties.

“I wanted them to be an extension of the in-house team, meaning I wanted them to be independent, creative, and come up with actual ideas for the products they worked on. I wanted to find a certain caliber of tech talent, people with a certain mindset, wherever they were. 

“Sure, if you know exactly what you’re building, maybe you can just offshore or nearshore that the stereotypical way. If you are building a Ford and you know how Fords are built, you can say, ‘Here, build 1,000 Fords for me.’ Boom! But software development never works like that.

“I think if you are talking about offshore vs nearshore, you are already losing the battle. Think in terms of building a geographically diversified workforce. It should be no different than having a remote team in the United States. If they are in Kyiv, Bangalore, or Mexico City, they are part of my team just the same. When people feel ownership in your company, they are happy to expose the problems because they are not trying to please a customer. They are talking to peers.”  

When I asked Shiva to summarize his philosophy, he said it really just comes down to two things:

• Reject the “us and them” mindset. Think of everyone as part of a single, global team.

• Make every team member a product owner. Everyone should feel like an integral part of product development.

What were the results at Oracle?

Did Shiva’s way of thinking catch on? 

“I think my division, my particular team, was the first one that said, ‘We don’t want a second-class services team that just does what we tell them to do. We want a distributed team.’ I ended up even having some of my US engineers report to a manager in India, which was unheard of before.

“I thought that would be the best model, and it was working very well. Then my bosses at the time said, ‘What if we give entire products to these international teams that have proven themselves? Let them figure out the problems. Let them figure out the solutions.’ You could almost think of them as their own Oracle business units. That worked out very well, too. Some of those Indian teams eventually got hired into Oracle India to design and develop products from scratch.

“When I eventually joined Intuit as Head of Platforms and Services, I practiced the same strategies there. We had similar results.

“You should commit to treating customers and service providers both like partners. I think that mindset is part of why Onymos is successful today.”