Back in 2012, when I first arrived in Vietnam, Google Maps barely worked outside major cities. People navigated differently. When you got lost — and you always got lost — you asked someone.
Every time, the same thing happened: they stopped. They turned to face you. They gave you directions with complete confidence.
The directions were sometimes wrong.
Not because they were trying to mislead you. Their mental map of the neighborhood — the one they’d navigated for twenty years — just didn’t match the map you needed. They pointed you toward a landmark that had moved. They said “it’s close” when close meant something different to them.
There’s a Vietnamese proverb one of my team members taught me: Đường đi ở miệng. “The map is in the mouth.” The real directions live inside people, not on paper.
I’ve been thinking about that proverb for fourteen years — mostly because the same dynamic shows up in offshore software development, over and over, in ways that detailed specifications don’t fix.
The person helping you is being completely sincere
When I first moved to Vietnam, I’d get frustrated. Someone would give me wrong directions with complete confidence. My initial reaction: why not just say you don’t know?
It took a while to understand what was actually happening.
In one version of helpfulness, the goal is giving accurate information. If you don’t know, you say so.
In another version of helpfulness, the goal is not leaving someone alone with their problem. You help as much as you can. You never send someone away empty-handed.
Both are completely sincere expressions of kindness. They just have different definitions of what kindness means.
I’d been treating my version of helpfulness as the universal standard. It isn’t. It’s just the version I happened to grow up with. And the moment I stopped assuming my defaults were the right defaults, a lot of things started making sense that hadn’t before.
The same thing happens when you build software across cultures
At one company I worked with, the leadership team in Tokyo had been frustrated with their Vietnam-based engineers for months. The specs were detailed. The tickets were thorough. Standups happened every day.
The same category of problems kept reappearing.
When I looked closer, the issue wasn’t the specifications. It was what happened when the specifications ran out.
Every spec document has a boundary. On one side: everything you thought to write down. On the other side: everything you assumed was obvious. Same industry, same training, same context — the “obvious” side gets filled in automatically by people who share the same professional defaults.
When you cross into a different cultural and professional context, that automatic fill-in stops working.
Here’s a concrete example. At a manufacturing client I worked with, the team had a detailed spec for an inventory module. One requirement: “error handling for invalid entries.”
The client expected the system to reject the entry and flag it for manual review.
The development team implemented an error popup and let the user continue.
Both interpretations were reasonable readings of the requirement. One matched the client’s operational workflow. Neither team knew they were working from different assumptions until integration testing — three weeks before go-live.
The Vietnamese engineers weren’t cutting corners. They built exactly what the specification described. The unwritten part of the spec wasn’t theirs to infer.
Why writing more doesn’t solve it
The standard response to this kind of friction is more documentation. Longer specs. More explicit acceptance criteria. More frequent check-ins.
It helps at the margins. It doesn’t solve the problem.
Because the issue isn’t how much is written down. It’s that the act of writing can only capture what you know you need to say. The hardest assumptions to document are the ones you don’t know you’re making.
In teams that share the same professional background, “error handling” contains a set of implied defaults that everyone absorbed through years of working in similar environments. You don’t document those defaults because you don’t know they’re there — they feel like common sense.
Common sense isn’t common across contexts. It’s context-specific sense.
What actually helps: designing the shared map
This isn’t about communication volume. More meetings don’t help if both sides are still working from different underlying assumptions about what the meeting is for.
Three things I’ve seen make a consistent difference:
Define “done” at the behavior level, before anyone writes a line of code. Not feature-level done. Behavior-level done. Edge case done. “What happens when a user does X when they shouldn’t” done. The question that surfaces the gap: “What would cause you to reject this deliverable, even if it technically satisfies the requirement?”
Make acceptance criteria visible to both sides before the sprint. Not as a QA checklist — as a shared vocabulary. The goal is to surface the places where both teams are using the same words but imagining different outcomes.
Treat cultural defaults as something to name, not something to overcome. When you onboard a new team member from a different industry background, you make your team’s defaults explicit. Do the same with your offshore team. Not as a lecture — as a joint inventory of how each side works, so you can identify where the gaps actually are.
The problem isn’t the people. It’s that nobody built the shared map — and both sides assumed the other one was reading from the same one they were.
Most vendors help you get it running. Almost none are there when it breaks.
There’s another thing worth saying directly, because it’s something I’ve watched happen enough times to take it seriously.
Most offshore vendors will be in the room at kickoff. They’ll be in the room at go-live. The demo will look right. The deployment will succeed.
Almost none of them are still in the room six months later — when something breaks under real production load, when the product works so well it surfaces a new problem nobody anticipated, or when the team that built it needs to understand something they didn’t design into it.
That gap — between “shipped” and “operational” — is where most offshore relationships fail to deliver real value. Not because the code was bad. Because nobody was responsible for the map after handoff.
Our team in Ho Chi Minh City has worked with clients in Japan and Southeast Asia for fourteen years. Development costs run roughly 30% of an equivalent Tokyo or Singapore engagement. We have a PM who speaks both the technical side and the business side, in English, without filtering through a chain of home-country coordinators. (If you’re weighing Vietnam against other offshore destinations, here’s why I stopped making that comparison.)
The part that matters most, though: we’re still in the room after go-live. QA checkpoint before anything touches your production environment. Monitoring available from month one. Not because we promise that — because it’s how we’ve operated since 2012.
FAQ
- Why does offshore development still fail even with detailed specifications?
Specifications document what you know you need to say — not the assumptions you didn’t know you were making. Every spec has a boundary, and what lives on the other side of that boundary differs between teams, cultures, and professional contexts.
The issue isn’t documentation volume. The hardest assumptions to write down are the ones that feel like common sense — because they feel universal until they aren’t. The solution is to surface those assumptions before work begins: define “done” at the behavior level, review acceptance criteria jointly, and treat implicit defaults as something to name rather than inherit.
- What’s the most common reason offshore projects in Vietnam underperform?
In my experience running a Vietnam-based team for fourteen years, it’s almost never technical skill. The issue is expectation alignment — specifically, who owns the decisions that the specification didn’t cover.
When that’s undefined, each side fills the gap with their own professional defaults, and those defaults diverge in ways nobody notices until integration or production. More meetings don’t fix this. Surfacing the decision boundaries before work begins does.
- How do I evaluate a Vietnam offshore development partner before committing?
Ask one question: “What’s your process when the spec is ambiguous?” A team that says “we’ll ask you” is fundamentally different from a team that says “here’s our protocol.” Then ask for a real example — a time when a requirement was unclear and how it got resolved. That answer tells you more than any portfolio.
Also ask who is accountable for the product six months after go-live. If the answer is vague, that’s the gap that will cost you later. Talk to us about how we structure ongoing accountability.
Thinking through an offshore engagement?
Fourteen years in Vietnam has taught me that the problem is rarely the people. It’s the map — and whether both sides built it together. If you’re in the “why does this keep happening” phase, or evaluating options before you commit, I’m happy to talk through it.
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.