For my last year of high school, I left Naples through the AFS exchange program and moved to Monticello, Iowa. Naples: 2 million people, noise, organized chaos. Monticello: population 3,000. Italian name, nothing remotely Italian about it.
I was 16, an exchange student. Across Iowa there were maybe 30 of us total: from Germany, Japan, Brazil, Finland, Thailand. I couldn’t really speak English at that point, and that didn’t stop me for a second. I communicated, joined in, showed up for everything. Plenty of things went over my head, got lost in translation, or were simply misunderstood. But I was learning constantly, and not just the language. We didn’t share a language, a culture, or any common frame of reference. What we did share was curiosity, openness, a willingness to figure it out, and a lot of smiles. None of us knew what to expect, but we all embraced it. I became as Iowan as I could, and at the same time learned more about Germany, Japan, Brazil, and Finland than I ever would have from a classroom.
What made it work wasn’t that we were tolerant of each other. It was that we were interested. You learn to listen differently when you know your interpretation is probably missing something. You stay flexible because your default assumptions keep getting challenged. You develop empathy not as a concept but as a reflex, because it’s the only thing that gets you to the other person. When someone approaches a problem in a way that makes no sense to you, the useful question isn’t “why would they do that?” It’s “what do they know that I don’t?” At 16, before you’ve settled into a fixed way of seeing things, that instinct can take root. I got lucky that it happened to me then.
Those people are still in my life. Some of them were at my wedding in Turkey, and again when we celebrated a second time in Italy. That year in Iowa is where I got my real education in what it means to work with people who think differently than you. Everything after that was practice.
The Career That Followed
I didn’t travel internationally for work. I lived internationally for work. There’s a difference.
Italian in France, building systems for airports and the European Space Agency. A computer science degree in London, then my first lead engineering role in England, building interactive television before most people knew what that was. US companies in Germany. German companies in the US. International teams in Australia, where I also went back to school for a master’s. Fifteen years in San Francisco building products in Silicon Valley. Every single product I’ve worked on has been used across multiple markets. Every team I’ve led or been part of has been multicultural by default, not by design.
My marriage is multicultural. My kids were born in different countries. I’ve learned languages not because I had to but because I wanted to understand the people and places I was living in.
Now I’m back in Europe, based in Milan. Milan is more international than I expected. It’s the most international city in the country by a significant margin, and it’s moving fast. That matters for what I’m building now.
What You Gain
The obvious argument for diverse teams is that diversity is a value. It is. But that’s not why it works. When everyone in the room has the same background and the same mental model, you have a systemic blind spot, and nobody inside the room can see it. One person from a different context asking “wait, why do we do it this way?” is worth more than a full sprint of internal review. I’ve seen this play out too many times to call it a coincidence.
It shows up in the product. Users in different markets don’t just speak different languages. They have different relationships with technology, different trust patterns, different expectations about what software should do for them. If your team doesn’t look like your users, you’re guessing, and when you’re guessing at scale the cost is real. The same teams also build software that’s harder to break. Date formats, character sets, right-to-left layouts, local payment rails, GDPR versus CCPA, how phone number validation works in Brazil versus Japan. A monoculture team discovers these in production. An international team has already broken the product in their heads across a dozen contexts before anyone writes a line of code.
Then there’s what distance does to how a team communicates. When you can’t tap someone on the shoulder, you write things down. Decisions get written up. Context gets shared in writing. Specs get clearer. This feels like overhead until you realize it’s the thing that scales. And right now it matters more than it ever has. AI tools work directly with your documentation, your codebase, your written context. A team that already communicates in writing has a structural advantage. The discipline international teams develop out of necessity is exactly what makes them ready for how work is changing.
Time zones belong here too, even though everyone files them under problems. Yes, someone is always at a bad hour. But a team spread across time zones can run nearly continuously: a bug filed in San Francisco at 5pm is picked up in Milan at 9am and resolved before the SF team wakes up. Follow-the-sun support, development cycles that don’t stop. It takes tight handoff discipline to unlock, but the teams that figure it out move faster than co-located ones.
And your talent pool stops being one city’s job market. The best person for a role might be in Warsaw, Nairobi, or Buenos Aires. If you’ve built the culture and systems to work internationally, you can hire them. If you haven’t, you’re competing with every other company for the same local pool.
What Breaks
I’m not going to pretend this is easy. And I’m not going to give you the obvious list.
Start with the mistake I see companies make repeatedly. They translate the UI, adjust the currency format, maybe hire one local sales rep, and call it international. Then they wonder why it’s not working. Going international is not a localization task. It means understanding a market from the inside: how decisions get made, how relationships are built, what “good customer support” means in that context. That knowledge doesn’t come from a market research deck. It comes from people.
The deeper problem is that HQ culture becomes the default culture, whether you intend it or not. When the company is headquartered in one country, that country’s way of working quietly becomes the standard. Meetings run in HQ time. Career paths are visible from HQ. “How we do things” is really “how we do things in San Francisco” or “how we do things in Berlin.” The international offices feel it. They adapt to survive. And over time, you lose exactly the diversity of perspective you hired them for. I’ve been on both sides of this: the one adapting, and the one setting the culture. You have to fight it on purpose, and keep fighting it, because the default always wins when nobody is paying attention.
Part of what collides is speed. German engineering culture values thoroughness, documentation, and consensus before moving. US startup culture values speed, iteration, and deciding with 60% of the information. Japanese teams build consensus before the meeting even starts. None of these is wrong. But when they meet without anyone naming the difference, the American team thinks the German team is slow and risk-averse, and the German team thinks the Americans are reckless and chaotic. The frustration is real on both sides, and it’s almost never about the decision. It’s about the process.
Feedback collides the same way. In the Netherlands, Israel, or Germany, direct critical feedback is normal and expected, a sign of respect. In many Asian cultures, a public “no” or explicit criticism in a group setting is something to be avoided at almost any cost. This creates a kind of miscommunication that’s hard to catch: a team member signals disagreement clearly, just not in a way the rest of the room is calibrated to read. The signal gets missed. The decision goes through. Later you find out the concern was valid. The cost isn’t that one decision. It’s the erosion of trust in a team that never figured out how to hear each other.
Language does something similar, quietly. When a company runs in English, the people most confident in English drive the conversations, in meetings, in Slack, in documents. That confidence gets misread as competence or seniority. The person who needs a moment to find the right word gets talked over. The idea that takes two sentences in French takes five in English and lands differently. Over time, non-native speakers communicate less, contribute less visibly, and get passed over, not because they have less to offer, but because the medium doesn’t serve them. Companies that don’t design around this lose people. I’ve felt it from the other direction too. I still think about the years when the most interesting engineering and research papers were coming out of Germany, and I couldn’t read them as fluidly as I would have liked. Language is not just communication. It’s access to knowledge, to networks, to how people in a given place think about problems.
Distance compounds it. Promotions, the interesting projects, the moments that build a career, they flow disproportionately to people who are physically near leadership. Remote and international employees, even exceptional ones, are systematically less visible. And the same time zones I just called an advantage become a pressure when nobody designs the rotation: someone is always on a call at an inconvenient hour, and it’s usually the same someone, the one furthest from HQ. Neither of these shows up in a dashboard until people start leaving.
Underneath all of it, trust across distance and difference takes longer to build. That year in Iowa where a group of teenagers from completely different backgrounds figured each other out, that happened because we had time and proximity. In a distributed global team, you don’t get that for free. You have to engineer it.
Part of engineering it is accepting that some things don’t happen over a video call. A team dinner. A walk around a neighborhood you’ve never been to. Eating something unfamiliar with someone whose city you’re visiting for the first time. This isn’t team-building overhead. It’s the work. I’ve made a point of visiting the places I work with, not just for meetings, but to spend real time there. Meet people in their environment. Sit at their table. See how they live. The trust that comes from having been in someone’s city, even once, is different from what you build over months of messages. Both matter. But you can’t get to the second without at least some of the first.
Where We Are Now
The tools are better than they’ve ever been. Engineering and digital work have compressed geography in ways that weren’t possible even ten years ago. Collaboration tools, async-first workflows, shared codebases across time zones. A lot of the old friction is gone.
AI is accelerating this further. The gap between building for one market and building for many is closing. Translation is better. Documentation is more accessible. The surface area a small team can cover internationally is larger than it’s ever been.
But here’s what hasn’t changed: you still need people who understand different markets from the inside. The judgment that comes from having lived somewhere, worked somewhere, failed at something somewhere different from where you grew up, that doesn’t get automated. That’s still a human thing. And teams with that depth have a real edge over teams that don’t.
We’re more connected than we’ve ever been. We’re also still different from each other, in how we think, what we value, what we expect. That’s not a problem to solve. It’s the whole point.
The photos I’m posting with this are from that year in Iowa. Most of those people are still in my life. If you want to understand why I think multicultural teams work, it starts there.