Hi, I’m Matt Watson, founder & CEO of Full Scale. This is my weekly newsletter based on my 20+ years of experience as a CTO and CEO of working in tech.

This week, we are handling a common sentiment I hear quite often:

"Offshore doesn't work."

I hear it constantly. Somebody tried it, it went badly, and now it's a settled fact for them. The developers were cheap and it showed.

Guess what? It isn't always a technical skill problem.

A developer on the other side of the world tells you "no blockers." You take it at face value. Two weeks later the feature is late, and it turns out he was stuck on day two. That's the kind of thing that ends up filed under "the offshore team can't code."

In this example, the developer speaks perfect English. He is a strong engineer.

What broke was communication, and not the language kind.

It's the invisible kind, the culture gap nobody that almost nobody thinks to look for.

And it shows up on any team split across a culture lines: offshore, nearshore, or a remote hire eight time zones away.

It's the number one reason people decide a global team "doesn't work."

Once you know what to look for, it shows up everywhere:

None of that is a coding failure. Every bit of it is a communication failure.

Christian Arches, one of our Customer Success Managers at Full Scale, tells this story about an engineer on one of his teams: he "implemented something that he didn't validate or even ask about if he got the right requirement. He just implemented it, and it turns out that it's not what it's supposed to be. So it requires rework." And rework, as Christian puts it, "equates to time, and time equates to money. So it's additional cost for the client."

The habit he drills into his team now: "Validate assumptions is what we always say."

All of it, because the right questions never got asked.

You hear flawless English on the standup and you assume everyone communicates the same way you do.

They don't.

Erin Meyer's The Culture Map is the best framework I've found for this. She puts communication on a spectrum from low-context to high-context.

In a low-context culture like the US, the meaning is in the words. We say what we mean and take people at their word. Be explicit or don't bother.

In a high-context culture, a lot of the meaning is in what doesn't get said: the tone, the relationship, what everyone already understands. The words are only half the message.

Japan, India, the Philippines, plenty of Latin America, most of the places you're likely to build a team, all run more high-context than the typical American manager.

A lot of that comes down to harmony. These cultures put a real premium on being polite, keeping the peace, and not making the other person uncomfortable. Blunt disagreement feels rude. So people soften, they hedge, and they avoid a flat "no."

So "I can do that" might mean "I respect you and I'll try," not "I commit to this." Silence, which reads as a problem to an American manager, can read as politeness or respect to your developer. And saying "no" outright can feel rude enough that a good engineer will quietly overcommit instead.

Fluency is not the same as directness. You can be perfectly fluent in English and still communicate on a completely different operating system.

This shifts by culture, so don't treat it as gospel. But the shape below repeats often enough across high-context teams to be useful just about anywhere.

None of that is a flaw to train out of people. It's just a different communication style, and your job is to manage around it.

If you fix one thing, fix this. It's the single biggest lever you have.

A yes-or-no question in a harmony-first culture is basically a request for a yes. "Does that make sense?" "Are you good with the deadline?" "Any blockers?" Every one of those hands the person an easy yes and a hard, slightly rude no. Guess which one you get.

And that yes? It usually just means "yes, I heard you."

Not "yes, I agree." Not "yes, I can hit Friday." Just: I received that.

So stop asking them. Ask questions that can't be answered with a yes.

"Walk me through your approach." "What could go wrong here?" "Show me where you're stuck." Now they have to tell you something real, and you find out what's actually going on.

And on anything that matters, never take the first yes. Ask them to say the task back to you in their own words. That thirty-second playback is where you catch the requirement that got heard three different ways, before it turns into a week of rework.

That question swap is one habit. But the burden was never all on the developer to adapt to you.

You set the team's communication culture. If directness doesn't feel safe, that's on you to fix, and a few more boring habits get you the rest of the way.

Give corrective feedback in private, because public criticism costs a lot more face in a harmony-first culture than it does in yours. Say the words "this is your call and I trust it" out loud, or people will keep asking permission. And put decisions in writing, because a doc or a PR comment lets a high-context engineer disagree with you without the face-to-face cost.

That's the short list. Our complete guide to managing an offshore team covers 12 key best practices.

The gap runs both ways, too. Your developers need to understand that blunt American feedback isn't personal. When a client says "no, that won't work," that's not an insult. That's just the work talking.

At Full Scale we don't leave any of this to chance. We train our engineers on these exact culture differences, how American clients communicate and what direct feedback actually means. And it cuts both ways. The managers have to change how they communicate just as much as the team does.

Both sides are learning a second language here. It just isn't English.

If your remote team only turns detailed specs into code, be honest with yourself. AI is going to do that, cheaper, and soon. That isn't the job you're hiring for anyway.

What survives is everything on the human side of the line. Helping figure out the requirement. Asking the question nobody asked. Pushing back on a bad assumption. Building the right thing instead of the half-baked ticket description. Every one of those is a communication skill.

None of this means skill doesn't matter. You still have to find bright, capable people, wherever in the world they are. We all know cheapshoring doesn't work, and hiring well is hard enough on its own.

But you can hire the sharpest engineers on the planet and still fail, if the way you manage them never accounts for how they actually communicate.

So the next time someone tells you their global team can't cut it, ask them what they actually changed. Did they stop asking yes-or-no questions? Did anyone make it safe to say no?

Almost always, nobody did. And when a team fails like that, it's rarely the developers. It's the people managing them.

After a whole post about the danger of "yes," that's still the answer I want to hear. The real one. "Yes, I understand what we're building and why." "Yes, I'll own this." That yes is a developer taking ownership of an outcome, and building teams of owners is the entire argument of my book, Product Driven.

But a real yes and a polite one sound identical on day one. You only learn the difference by working with someone. A few months in, you know whose "yes, I can do that" is a commitment, who goes quiet when they're stuck, and who pushes back. You earn that read one sprint at a time.

So make it safe to say no. The people who will tell you no when it matters are the same people whose yes means "I own this."

Those are the people you build around.

The essay above is really about the Courage pillar of Product Driven, specifically Scaling Courage Starts with Empathy.

Most managers think they want agreement.

What they actually need is a team safe enough to disagree with them. That safety doesn't scale on its own; you have to earn it, and with a cross-cultural team you earn it by understanding their communication style first, not by asking them to adopt yours. Courage has to be modeled before it can scale. If you want a real no, you go first.

I spent the last couple weeks in the Philippines. Part of that was with our team on our community day! I personally helped donate computers at a college and plant trees in Cebu City.

We do this every year to give back to the local communities in the Philippines. You can watch a little recap video here. Thanks to our hundreds of employees for all the hard work and donating their time.