We run a development company in Ho Chi Minh City, building software mostly for Japanese clients. The team is multinational — Vietnamese and Indian engineers, with Japanese, Vietnamese, and English all in the mix, working mostly async across time zones.
After years of running a team like this, here’s the one thing I’m sure of: whether a team can surface problems quickly decides the final quality of the work. Not the talent. Not the stack. That. And I don’t mean it as a slogan — I’ve watched it play out, the same way, over and over.
So we take “don’t blame the person who failed” pretty seriously. That’s not the same as not caring about quality — it’s the opposite. If a failure isn’t visible, you can’t fix it. So we put “make it visible” first. That’s all it really is.
Here’s how we actually think about it, in plain terms.
We forgive the failure. We don’t forgive hiding it.
Bugs happen. People read specs differently. Estimates slip. This never goes to zero. Pros write them, veterans design them, and they still show up.
So the thing that actually matters is: when a problem appears, how fast does it get shared?
I’ll be honest — my own instinct used to be to figure out whose mistake it was first. But after a few years with a multinational team, I learned that backfires. The moment you pin a cause on a person, people go quiet next time. And when people go quiet, the bug goes underwater. Nobody can fix what nobody can see.
Think about what happens when the person who finds a problem expects to get grilled for reporting it. The report comes late. Then it stops coming at all. On a remote team that doesn’t share a language, that silence spreads fast — and not seeing the real state of things is the one situation you can’t afford.
So we deliberately keep “whose fault was it” out of our retros. We only look at two things: what happened, and how we stop it from happening again. That’s not kindness — it’s the practical move. The second you blame someone, the information you need to fix the thing dries up.
We praise the person who finds the bug. And we treat hiding a problem to keep moving as the thing that breaks trust. Those two go together — that’s the culture we keep building on.
A concrete one. About 14 years ago, I built an iPad survey app for a business expo in Tokyo. Simple thing — people who stopped by the booth would answer about 15 questions on the spot.
It had a bug: the last three answers never got saved. The earlier questions recorded fine — just those final three vanished. And I found out two days before the show opened. That one stung.
What goes through your head in that moment is, honestly, “did we actually test this properly?” and “how on earth do I explain this to the client?” It’s less that you want to hide it, and more that saying it out loud is just hard on you. But there’s no real option to stay quiet. Walking into the day silent, and letting data go missing on the floor, breaks trust far worse.
What that day drilled into me is that the timing and the telling matter more to trust than the bug itself. You can’t avoid problems happening. But whether you put it on the table the moment you know — that decides what the relationship looks like afterward. Deciding to “say it” two days out is still my baseline today.
Work happens where people can see it.
This is the hard one, honestly. “Transparency” is vague — how much of what do you actually put in the open?
What I care about isn’t “publish everything.” It’s that the right people get the right information at the right time.
With a co-located team in one office, you can get away without much of this. You ask the person next to you. You read the room. When someone says “got it,” you can usually tell on the spot whether they actually got it.
But put a time zone, a language gap, and async work in between, and all of that “you just kind of sense it” stops working. “Understood” — how understood? You can’t see the other side of the screen.
So we lean on the written record. Not out of some high-minded principle — talking it out isn’t physically possible across the gap, so writing is what’s left. If I’m being honest, the motivation is more defensive than idealistic: if we don’t, we just have accidents. Write it down first, and at least you stop bleeding trust over “I said / you said.”
Build a team that can fix things — not a hero.
How do you cut down on key-person dependency? Our answer is “anything you do twice, write up as a procedure anyone can follow.” But I’ll admit — I used to believe the opposite. “As long as we’ve got that person, we’re fine” was actually my favorite state to be in. Hand everything to a strong ace engineer and yes, it’s fast, and the quality holds. So I used to think good management meant finding strong people and clearing the runway for them.
What changed my mind was watching the team freeze, instantly, every time “that person” took leave or moved on. Code only one person understood. A client only one person could handle. A spec only one person could decide on. Leaning on the ace feels easy and looks like a strength — right up until they’re gone, and then it’s all risk.
So “anything you do twice gets written up” is half a rule for us now. If it repeats, turn it into something anyone can run. Write it, review it, fix it. It’s unglamorous, but keep at it and the “only that person can do this” list shrinks one item at a time.
We’ve got several engineers using Claude day to day now, and individual speed really has gone up. But early on I’ll admit I half-assumed “hand out the tool and we’re done.” What I found in practice is that the people who got faster were the specific ones who could use it well — and the team’s overall quality hadn’t moved at all. Same shape as the “ace leaves, team freezes” problem. I wrote about that in more detail elsewhere, but the short version is: the only thing you can actually hand out is the system.
A team where everyone can fix things beats one hero, because that “ace is out, everything stops” moment never arrives. It’s quiet and it’s not flashy — but I sleep better handing work to people that way.
Build small, learn fast.
“Build small, show it early” isn’t a new idea, I know. But there’s a reason we hold so tightly to it specifically in offshore work — a reason that comes from the distance between the teams.
With a time zone and a language in the way, a misread spec can stay invisible for days. “Understood,” comes back — and you don’t notice the gap until you actually see what got built. So before we push for polish, we go check that the direction is right first.
This is especially true for AI-driven features, or consumer-facing systems where user behavior is hard to predict — building something you can run beats locking the spec down first, and the final result usually comes out better for it. We feel this every time on the AI-powered systems we build.
So we run projects on “build small, show early.” It gets us to a finished thing more reliably than leaning on a thick spec document.
We hold AI to the same culture.
One more, on AI. Lately the way people use it has shifted from “ask a question, get an answer” to “it does the work itself.” It writes code, researches, drafts, opens tickets. Less a tool waiting for instructions, more an agent you hand a task to and it just runs. Our team uses it that way daily now.
And that shifts the real question. Until recently, “the AI might be wrong, so have a human check behind it” was enough. But once an agent is doing real volume of work, having a human watch every move can’t keep up. The reviewer becomes the bottleneck — speed drops, and you miss more, not less.
So what do you do? We decided to design AI the same way we’d onboard a new team member. With one decisive difference: a human gets a ramp-up period. You start them on small work, build trust back and forth over time. An AI agent doesn’t get that runway. From day one, it’s moving at full speed.
So the part that, for a human, would be “trust you build over time,” you have to set up in the design ahead of time. How much you delegate. What you keep inside a range you can roll back. You decide that before you hand the work over. It’s the same thing you do trusting a new hire — the only difference is, with no time to build trust, you front-load the equivalent into the design.
Projects that run on “well, we can technically build it” — honestly, we’d rather not take those. Who is it for? When it goes wrong, who notices and how do they roll it back? Settling that up front is far easier on both sides than landing in “that’s not what I meant” later. Clients sometimes call us rigid for it. That’s one place I don’t bend.
Designing for trust
So here’s where I land. The thing we hold onto as a culture isn’t “don’t fail.” It’s that we assume failure is unavoidable, and we tilt everything toward making it visible fast when it happens.
Bugs can be fixed. Misunderstandings can be fixed. A design mistake can be improved once you find it. The only thing you can’t fix is the problem someone hid. That survey app 14 years ago got fixed because I decided, two days out, to say it. Had I gone in silent, the data would’ve gone missing on the floor — and I wouldn’t even have known.
Offshore development usually gets picked on “it’s cheaper.” But what decides whether a company is one you can work with for the long haul isn’t price — it’s this culture part, ahead of the cost. If cheap is the only axis, there’s always somewhere cheaper.
If you want to check whether your team and ours actually fit, grab 30 minutes with the button below. Honestly, the fastest way to find out is to ask how we work — what we do when a problem shows up, what we keep on record — before any talk about the tech.
Let’s talk about whether we fit — first.
Before price or stack, let’s talk about how we work — what we do when a problem surfaces, what we put on record. I’ll listen to where your team is and we’ll figure out together whether the culture clicks. Come treat it as a sounding board, not a sales call.
Book 30 minutes →Frequently asked questions
What kind of company culture does Linnoedge have?
We put weight on transparency, documentation, and protecting quality as a team. We protect the person who reports a bug or a problem, and we don’t tolerate hiding things. Because we work as a remote, multinational team, we run tickets, meeting notes, and decision logs as our “infrastructure for trust.” This article lays out the details.
What’s the single most important thing for not failing at offshore development?
Building an environment where problems can’t stay hidden. On a distributed team with time-zone, language, and culture gaps, a late report on a problem can put you past the point of recovery. At Linnoedge we build a “share it early, share it small” culture into the development process itself. More on our offshore development service here.
When commissioning AI-driven development, where should we start?
Before “can it technically be built,” we start by working out together who it’s for, and — when it goes wrong — who notices and how it gets rolled back. Start with a 30-minute conversation and tell us where things stand.
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.