Great Teams Aren't Limited
by Geography

At the beginning of my career, geography played a much larger role in how companies built teams than it does today. Where an office was located often determined where people were recruited, which markets were accessible, and ultimately which talent could become part of the company.

That constraint hasn't disappeared entirely, but it has changed significantly.

I've spent much of my career building and working with teams across different countries, cultures, and time zones. That experience has reinforced for me that geography is only one variable in building a great team. Expertise, communication, leadership, cultural alignment, and the ability to work toward a shared objective usually matter much more.

This doesn't mean every role should be remote or that every company should build globally. There are very good reasons for teams to work together in the same place, and some companies deliberately build around that model. The opportunity is simply to recognize that location no longer needs to be an automatic boundary when the work itself doesn't require it.

The Team Should Come Before the Map

When a company needs to expand a digital team, geography can easily become one of the first filters. Where can we hire? Where do we already have offices? Which markets are accessible to us? What talent can we realistically attract within a particular budget?

Those are all legitimate considerations, but I think there is a more useful question to answer first: what combination of people and expertise does the initiative actually need?

A complex digital program may require UX and UI designers, engineers with particular technical expertise, QA professionals, experienced Project Managers, or people who understand a specific platform or industry. Those needs can also change as the initiative progresses. Discovery, design, implementation, launch, and ongoing optimization don't necessarily require the same team composition.

Starting with the capabilities rather than the locations changes the conversation. Geography still matters, but it becomes one of several considerations used to assemble the team rather than an arbitrary boundary around where that team can come from.

We see this in our own work. On one current engagement, three people from Emberlight Global are supporting a U.S. client from Costa Rica, Mexico, and Honduras. On an organizational chart, that might look like a geographically distributed team. In practice, geography is one of the least interesting things about how they work together. They participate in the same delivery structure, collaborate around the same priorities, and are accountable to the same client objectives.

We've experienced the same model across much greater distances. For a client in New Zealand, we built a team with people working from Nicaragua and Argentina. The distance was greater, the time-zone considerations were different, and the operating rhythm needed to reflect that reality. None of those considerations disappeared simply because collaboration technology made the arrangement possible.

What mattered was whether we could create a working model in which the right people could collaborate effectively despite those differences. That distinction has become increasingly important to me because access to global talent and the ability to build a successful global team are not the same thing.

Access to Talent Is Only Part of the Equation

The ability to recruit across markets opens an extraordinary pool of expertise. It can make specialized capabilities easier to find, create greater flexibility in how teams are assembled, and allow companies to consider people who would never have entered the candidate pool if hiring had been limited to commuting distance from an office.

There is an economic dimension as well, particularly when companies in higher-cost markets build teams across regions such as Latin America. I don't think there is any reason to avoid acknowledging that advantage. Different markets have different compensation structures and operating costs, and those differences can create meaningful efficiencies.

Where I think the conversation becomes more interesting is in what companies can do with that efficiency.

A broader talent strategy might make it possible to bring dedicated QA into a program instead of asking developers to absorb that responsibility. It might create room for stronger UX or UI expertise, an experienced Project Manager, or a more specialized engineer than would otherwise fit within the economics of the initiative. A company may also discover that the person with exactly the experience it needs simply happens to live in another country.

In that sense, the opportunity isn't only to build the same team for less. It can be to build a different and potentially more complete team because the available talent pool and economics have changed.

None of that guarantees the team will work well together. Distributed teams still have to navigate differences in culture, communication styles, language, working hours, holidays, and expectations. Even relatively small time-zone differences can become frustrating when they aren't considered intentionally, while much larger differences can work surprisingly well when the operating model is designed around them.

There is also a meaningful difference between having people assigned to the same project and having them genuinely operate as one team. People need context, not just tasks. They need to understand why decisions are being made, how their work affects other disciplines, and what everyone is ultimately trying to accomplish. They also need enough trust to ask questions, challenge assumptions, and contribute their expertise rather than simply executing instructions.

This becomes particularly important when a team crosses company boundaries as well as geographic ones. If external specialists are consistently treated as outsiders, the relationship will naturally remain transactional regardless of where anyone is sitting. The strongest distributed teams I've experienced develop a shared sense of responsibility for the outcome while still respecting the roles and accountability that exist within each company.

Distance Makes Good Delivery More Important

One of the lessons distributed work has reinforced for me is that distance tends to expose weaknesses in the way work is managed rather than create entirely new ones.

Unclear requirements are a problem when everyone sits in the same office. So are ambiguous ownership, poorly documented decisions, unnecessary meetings, weak handoffs, and uncertainty about who has the authority to make a decision. Physical proximity can sometimes compensate for those weaknesses because people resolve them informally. Someone walks across the room, asks a question, or hears a conversation that provides missing context.

A distributed team has fewer opportunities to rely on those accidental interactions, which makes thoughtful delivery practices considerably more important.

This is one of the reasons Project Management plays such an important role in the teams we build. A strong Project Manager isn't simply maintaining a schedule or tracking whether tasks have been completed. The role is much closer to orchestration: making sure the different disciplines remain connected, that dependencies are visible, that decisions happen with the right people involved, and that everyone has the information they need to keep moving.

That doesn't mean solving distance with more meetings. In fact, one of the quickest ways to make distributed work exhausting is to assume every gap in communication requires another call. The objective should be to create enough clarity, documentation, ownership, and predictable communication that people can work independently when appropriate and collaborate synchronously when the conversation genuinely benefits from it.

I've also come to think about this as an experience-design problem in its own right. We normally associate User Experience with the people using the digital solutions we create, but many of the same principles apply to the way teams work. If people constantly struggle to find information, don't understand where decisions are made, repeat the same conversations, wait unnecessarily for approvals, or move through confusing handoffs, the operating experience itself has friction.

Sometimes improving a distributed team means introducing a better tool. More often, it means examining the process around the tool: simplifying a workflow, clarifying an SOP, changing how information is documented, establishing clearer ownership, or reconsidering which conversations actually require everyone to be present.

The goal isn't to recreate the office through software. It's to build a working environment appropriate for a team that isn't always in the same place.

That still leaves room for physical interaction. I don't believe the lessons of distributed work somehow make being together irrelevant. Kickoffs, workshops, planning sessions, difficult strategic conversations, or simply opportunities to strengthen relationships can benefit enormously from sharing a room. The difference is that physical proximity can become something teams use intentionally when it adds value rather than a permanent prerequisite for collaboration.

When Geography Becomes Secondary

When distributed teams are working well, something interesting happens: geography gradually becomes less noticeable.

I don't mean that cultural differences disappear or that time zones stop mattering. Those realities continue to exist and should be respected. What changes is their importance relative to everything else that defines the team.

The three people supporting our U.S. client don't begin their day primarily as representatives of Costa Rica, Mexico, and Honduras. They're colleagues working on the same engagement. The people we assembled in Nicaragua and Argentina for our New Zealand client weren't valuable because of the countries they represented. They were valuable because of the expertise they brought and what they were able to accomplish together for the client.

For me, that's a much more useful way of thinking about teams without borders.

It isn't about being remote for the sake of being remote, and it certainly isn't an argument that every company should abandon local hiring or physical workplaces. It's about giving companies more freedom to build around the capabilities they actually need and recognizing that the right person doesn't necessarily live within an arbitrary distance of an office.

That freedom also comes with responsibility. Companies and their partners have to become better at creating clarity, establishing trust, managing delivery, respecting cultural differences, and designing ways of working that allow people to contribute fully regardless of location. Access to talent creates the possibility, but leadership and execution determine whether that possibility becomes a successful team.

There is no single blueprint for building an exceptional digital team, just as there is no single geography where exceptional digital talent exists. Different initiatives, cultures, and business realities will continue to require different approaches.

What has changed is that we have more choices.

For me, building without borders is ultimately about having the freedom to think first about the expertise an initiative needs, then finding the right people to provide it, wherever that expertise happens to be. When the operating model, leadership, and culture allow those people to work effectively together, the lines on the map become much less important than the shared objectives that brought the team together in the first place.