[Upcoming Webinar] Developing Engineering Talent and Leadership Reserve Your Seat

How Splice Builds Globally Distributed Engineering Teams

Perspectives in Engineering

How Splice Builds Globally Distributed Engineering Teams

GitPrime elevates engineering leadership with objective data. In this interview series, engineering leaders talk about how to build high performing teams.

One of the primary reasons to build a distributed engineering organization is that a company is not limited by geographic boundaries. But even though the talent pool spreads around the globe, hiring engineers who speak other languages, come from other cultures, or live in countries with different labor laws can intimidate even the hardiest hiring manager.

Juan Pablo Buriticá, however, seeks to build teams in places where other North American companies typically don’t: Latin America, especially in Colombia.

“The engineering team at Splice is now fifty-something people. We grew from five engineers to fifty-five in about the first eighteen months, fully distributed,” Buriticá says. “We treat Engineering as a one-hundred-percent distributed organization.”

For the last ten years, Buriticá has successfully been building and scaling distributed engineering teams and Latin American open source software communities. Before taking over as the VP of Engineering at Splice, he served as the CTO and VP of Engineering at Ride, the VP of Engineering at Onswipe, and the Director of Engineering at Panelfly.

“Co-located and distributed teams are not better than each other, but they are different,” Buriticá says. “I like leaning into the challenges of distributed teams because all teams eventually become distributed, whether it’s across floors or offices or buildings. It happens no matter what, unless your company stays a twenty-person size. If you build effective, asynchronous channels of communication from the beginning, then you can scale a lot faster.”

Talent is equally distributed, but opportunity is not.”

Leila Jana CEO of Sama Group

In this interview, Buriticá delves into the ins and outs of sourcing engineers in other countries, including universal lessons he’s learned from his own very particular experiences. He also explores other decisions for an organization to make before deciding to hire abroad, such as whether consultants or product engineers better suit the company’s needs, and identifying the company’s mission in a way that transcends borders.

Three lessons for sourcing in other countries

Buriticá would love to see more companies hiring engineers in Latin America. “Opportunities are not distributed evenly, but talent is,” he says.

Yet he acknowledges that his own recipe for hiring abroad has such a long and specific history that it would be difficult to copy. Nevertheless, the major steps he took offer lessons for others looking to expand a team beyond their own borders.

Start by building a network and a brand

Buriticá was born and raised in Bogotá, Colombia—a distinct advantage when it comes to making connections there. Yet he still had to put in the years of effort to build a strong network and making a name for himself.

He went about that by starting the first-ever open source conference in his native country.

“It was called BogotáConf,” he says. “From there, I started helping other communities get started. I bootstrapped JSConf Colombia, RubyConf Colombia. I’ve sponsored other events, and I’ve built a brand of being focused on Latin America.”

Companies don’t have to start conferences and hold events to network abroad, though. Whether networking happens on an individual or a large-scale level, how those bonds are built also shapes an organization’s reputation. Buriticá made sure to continue building his brand upon the way he treats other engineers.

“I pay really well for the region,” he says. “I build teams that respect the craft. So I get to hire the best engineers in the region. Folks know my work, and they know the people who have worked with me. They are attracted to the sorts of things I do. It’s a self-fulfilling cycle.”

Learn the lay of the land

Buriticá acknowledges that hiring in a foreign country can be a daunting challenge. Language and cultural barriers aside, an organization likely has to learn the labor laws and hiring regulations between the two nations.

“That’s what I’ve found to be the biggest hurdle to hiring in Latin America,” he says. “I’ve been more than pleasantly surprised in the States by how many facilities foreign people have here. You can come as a foreign citizen, open a bank account with your passport, and do business with a business visa. You’re essentially an international contractor.”

Similar regulations exist abroad, but few people know about them or understand them. Buriticá again has that home-field advantage in Colombia—but even he hires local accountants whom he can rely on for his operations. He’s not an expert, he notes, so he finds the people who are.

The approach here is two-pronged: organizations can get familiar with the labor laws and rules in the regions where they want to hire, and they can also hire agents on the ground who understand the things that no amount of remote research can convey.

Begin with nearshore and consulting opportunities

“By hiring as many Latin Americans as I can,” Buriticá says, “I’ve found that the majority of opportunities in Latin America now are nearshore and consulting.”

The work these engineers get right off the bat is different than what you might give an in-house engineer. Nearshore engineers and consultants are typically looking to work with an organization that has already thought through the product. They want the specs, and they can then build to suit.

Most of the people Buriticá has hired in Latin America for Splice, and before that for Ride, came from a consulting background. But he found something else, too: within three to six months, the mentality switched, and these consultants had the chance to become product engineers—an opportunity Buriticá recognizes is largely lacking for them in Latin America.

Decide whether you’re hiring consultants or product-focused engineers

The opportunity to switch from consultants to full-fledged product engineers is not merely a decision for engineers to make. Organizations themselves must decide which they ultimately want and whether they will aid these engineers in making that transition.

The difference between a consultant-style nearshore engineer and a more product-focused one, Buriticá believes, is about ownership. There’s not a right/wrong or a better/worse decision here. “There’s space for both,” he says.

Some companies already know their product, their market, and their business really well, and they need to rely on straightforward implementation or manufacture. Others—such as typical product startups—succeed better if they can learn and iterate faster than their market. And iterating faster than the market is quite challenging if the people responsible for building the products don’t understand what the market is.

“If you give a metric to a product team, they will figure out how to drive it or game it,” Buriticá says. “You’re giving them a direction, and you’re letting their creativity do the work.”

Consultants typically don’t enjoy all those same freedoms. Yet that doesn’t mean consulting is a net negative for the engineer or for the organization. Often consulting gigs are short-term or less than full time, so consultants have the opportunity to rapidly learn about many different businesses—and companies get the set results they want accomplished without investing time and resources into a learning curve.

If you’re a software engineer, you’ll understand that software is a process and not a product. You’re trying to codify something to the best of your understanding, but you’re always going to be out of date. Always. But you can learn any skill.”

There are various models along the spectrum of consultant/in-house engineer. It all depends on what an organization requires, and what an engineer desires. A happy match happens when those two needs align, and that is more likely to happen when an organization can communicate what it ultimately wants, particularly after discovering a consultant relationship that works well.

In his interview processes, looking for engineers he can hire as full-fledged product developers, Buriticá pitches his company’s mission to potential hires. “In the last meeting that you have with me, I’m telling you, these are all our products, here’s where we’re going. Are you in for the ride or not?” he explains.

Buriticá wants his engineers to be on board with the company’s mission up front. They can then train engineers on everything else needed to be successful in their roles.

“We can teach you,” he says. “If you’re a software engineer, you’ll understand that software is a process and not a product. You’re trying to codify something to the best of your understanding, but you’re always going to be out of date. Always. But you can learn any skill. With those principles and willingness, we train anyone in the dark.”

Connect to the mission with every hire

Buriticá has good reason to match with engineers who believe in the purpose of the organization: he understands that engineers, wherever they are from and wherever they are working, find motivation in having an impact.

But the mission needs to be something specific, and directly connected to the organization’s work. Nothing vague here, like We’re going to change the world. And nothing complex. If you can’t express to new hires what exactly they will be doing—and why—in one simple sentence, why should they be excited to come work for you?

“I like building mission-driven teams,” he says. “My last company was a carpooling company. What was our mission? Maybe we can make it easier for everyone who has a long commute to coordinate with each other. And your software skills will help that. Right now, at Splice, what do we actually come here to do? Help artists get paid, while they make more and better music. That’s what we’re here for.”

Connect the mission, no matter what, to engineers and give them the ability to see where their work has an impact.”

Distilling a company’s goals into something that touches everyday work organization-wide creates a story. A story that’s easy to tell is something that engineers can remember every single day to give them purpose and demonstrate how their work has an impact.

Buriticá points to an artist, Karra, who’s career shifted with the launch of her Splice vocal pack. The code every engineer wrote throughout the product had an impact on that artist’s career. Even the engineer working on the spreadsheet that calculates artist payouts just changed someone’s life. And that is something basic, almost primal, that transcends international boundaries and gives engineers purpose, whether they’re working down the hall or across the equator.

“Connect the mission, no matter what, to engineers and give them the ability to see where their work has an impact,” Buriticá says. “Our tagline for Engineering at Splice is this: Be the Bass. We carry the rhythm, we let everyone shine, we have no ego. But our work supports everyone. We bring everyone forward. All startups have their cultural challenges, but we do what helps us continue to move our team forward, wherever we are.”

Our tagline for Engineering at Splice is this: Be the Bass. We carry the rhythm, we let everyone shine, we have no ego. But our work supports everyone. We bring everyone forward.”