I’m Shogo Harada, CEO of Linnoedge. I run a software development company in Ho Chi Minh City.
For a long time, I believed something that turned out to be wrong.
I believed offshore development fails because of chemistry.
Pick a good vendor, you win. Pick a bad one, you lose. So the whole game is picking: do the due diligence, check the references, and hope you get lucky.
When I have drinks with other executives, that’s where the conversation usually lands too. “We had bad luck.” “That one was a good pick.” A lottery.
But after years of running development teams in Vietnam (and being on the buying side myself), I’ll be direct: that’s not what I see when projects fail.
“It failed because it’s Vietnam”: the excuse nobody can disprove
Search “why offshore development fails” and you’ll find the same list everywhere: communication gaps, unclear requirements, quality issues, time zones, attrition. The lists aren’t wrong. But they describe symptoms. Underneath them, I keep finding the same structure.
Here’s how it usually starts. A company decides to go offshore, but the decision stays in the boardroom. Management has real reasons: cost, or simply that they can’t hire engineers at home anymore. The buyer’s own team never hears those reasons.
For that team, the old way was easier: a familiar local freelancer, same language, shared context, no friction. Now they’ve been handed something inconvenient, and nobody explained why.
Then something goes wrong. And the frustration finds the easiest available explanation:
“It failed because it’s Vietnam.”
This one sentence does more damage than it looks, because nobody can disprove it. If the cause is “Vietnam,” what exactly do you fix next? Nobody knows.
The moment you blame the country, the subject of improvement flips from “us” to “them,” and thinking stops. An excuse that can’t be falsified can’t be improved on, either.
A slightly embarrassing admission: it took me years to see this, and I run a company in Vietnam. I’ve caught myself reaching for “bad chemistry” more than once. But every time I traced what actually happened, step by step, the answer came back to the same place.
The real culprit: instructions that assume the reader can read your mind
So what do you find when you skip the excuse and look at what actually happened?
In most of the cases I see, the culprit wasn’t the country and it wasn’t ability. For my Japanese clients, it was the Japanese language itself. Japanese is built on the assumption that things don’t need to be said explicitly, a high-context language, as linguists call it. And I had never noticed how much of my own communication leaned on that assumption.
Some real instructions from Japanese clients, and I’ll confess, I used to write all of these myself:
“Naruhaya”: shorthand for “as soon as possible.” No deadline attached. Today? This week? Only the writer knows.
“Bimyou”: literally “it’s… subtle.” A soft way of saying no, without saying what’s wrong or how to fix it.
“I’ll coordinate”: who decides what, by when? Nothing has actually been decided.
If you work in English, you have your own versions. “ASAP.” “Make it cleaner.” “Let’s align on this later.” Every language has them.
My favorite extreme example translates roughly as: “Please handle this ASAP-ish, in a nice way.” I don’t think that instruction would survive contact with a colleague sitting in the same office. It’s too vague. But with a long-time freelancer, it somehow works: years of accumulated context fill in the gaps. That shared “just get it” shorthand is doing invisible work.
I didn’t see this for a long time. I assumed my “read between the lines” was a universal standard. It wasn’t. It was a private dialect.
That dialect doesn’t reach a team in another country. Not because they lack ability, but because I never put it into words. And then I quietly blamed the gap on their country.
Once we saw that, our practice changed. Not “ASAP”: “by Friday, 5 p.m.” Not “I’ll coordinate”: “who does what, by when.” Every ambiguous phrase we cut, trouble drops. The effect is bigger than I expected, every single time.
Clear words aren’t enough, though
“So just write clearer instructions.” That’s where I stopped, at first. It wasn’t enough.
There’s a second structure I’ve come to feel strongly about: sending work that one or two people can handle to an offshore setup is usually not worth it.
When you hire an individual, you depend on that individual. They take a holiday, work stops. They quit, the search starts from zero. The reasoning behind every spec lives in one person’s head.
None of this depends on which country they sit in. It’s the same structure everywhere.
Send work at team scale (three to five people or more), and the picture changes. One person leaves, but the context stays inside the team, so the handover holds. Quality stops depending on one person’s skill and settles toward the team’s standard. Key-person risk doesn’t get “managed.” It structurally disappears.
My own lesson here: our team members had proposals all along, and I didn’t notice until I started asking. People with a strong sense of responsibility tend to hold back: they don’t want to overstep. So now I go and ask: “What do you think?” That one habit surfaced more good ideas than any process change we ever made.
I wrote about this in another article: now that AI writes code cheaply, the value of offshore isn’t “an affordable individual” anymore. It’s a team that accumulates your context. Which means the failure mode is changing too.
The old failure was picking the wrong cheap coder. The next one is buying code by the hour when what you needed was a team that holds your context. The standard failure lists won’t warn you about that one.
So here’s what we do on our side
Everything above (vague instructions left unexamined, work parceled out to individuals), none of it is “a Vietnam problem.” It’s a structural problem on the buying side. I say that as someone who has sat on both sides of the table.
So what we do is simple.
First, we make the “why offshore” explicit before anything starts, and we make sure it reaches the people who’ll live with it. One sentence is enough. “We can’t hire at home, so we’re going where the engineers are.” When the reason stays at “somehow it’s cheaper,” the team never buys in, and every incident becomes another chance to say “because it’s Vietnam.”
Second, when we’re the ones outsourcing, we buy at team scale, not individual scale. A system isn’t born the day you announce it. It’s born the day someone says, “we’d have been stuck without that team.” Until then, it’s just a plan.
And third, we go and ask the team what they think. We don’t run projects on one hero. We don’t call engineers “resources.” We call them by name and ask their opinions.
It sounds soft. In practice, it’s the most reliable habit we have.
What would you find in your projects?
I can’t claim the high ground here. We outsource work too, and I repeated the same failure more times than I’d like to admit: file it under “bad chemistry,” find the next vendor, watch the same thing happen again.
What changed things was replacing “chemistry” with “structure.” Cut the ambiguous words. Buy a team, not a person. Be able to explain, in your own words, why that country. None of it is glamorous, and all of it can start tomorrow.
If offshore isn’t working for you right now, or you’re about to commit and something feels off, try setting the chemistry question aside for a week. Ask a different one instead: “What have we not put into words?” That’s how we fixed it on our side. What would you find in yours?
Frequently asked questions
Why do offshore development projects fail?
The usual suspects are communication gaps, unclear requirements, and uneven quality. But in the projects I see, there’s a structure underneath: the buyer’s decision (“why offshore?”) never reaches the working team, and instructions stay ambiguous. Fix the structure and most of the list fixes itself. I unpack the team side of this in how AI is changing what offshore is for.
How do I de-risk offshore vendor selection?
Look past hourly rates and ask structural questions: Will my work be handled by a team of three to five or more, not one individual? What happens when a member leaves? How does the vendor turn vague requests into explicit ones? A vendor who can answer those in concrete terms is de-risking for you. Rates only tell you the price — here’s how to read the full cost picture.
What should I do first to make offshore development work?
Three moves, in order: decide in one sentence why you’re going offshore and share it with your team; replace ambiguous instructions (“ASAP,” “make it cleaner”) with deadlines and owners; and buy at team scale so the context survives any one person. Which one matters most for your situation depends on where you are — that’s exactly the kind of thing I’m happy to think through with you below.
Worried about an offshore decision? Let’s talk it through
Whether you’ve been burned before or you’re about to commit and want a second pair of eyes, I’m happy to walk through it with you — from someone who runs teams on the ground in Vietnam. No sales agenda. Bring your questions.
Book 30 minutes →
Shogo Harada原田 祥吾
CEO · Linnoedge Inc. · LinkedIn↗
Operating IT offshore development and overseas expansion support businesses across two bases: Tokyo and Vietnam. A leader who believes in “Systems over Spirit,” structuring cross-border businesses that often tend to be opaque. Committed to providing “reproducible quality” to organizations and clients rather than relying solely on individual skills.