Our offshore team had a perfect delivery record. That was the problem.

What a trip to Vietnam taught me about offshore teams that two years of status calls never did.

I was sitting across from a senior engineer in Ho Chi Minh City when he told me, without any particular drama, that doing good work for our company mattered to him because it was a reflection of what Vietnam could do on the world stage. Not the company he worked for. Not his career. The country.

I nodded and said something appropriately appreciative and moved on with the conversation. But I have not stopped thinking about that sentence since I got home, because once I understood what it meant, it reframed almost everything I thought I knew about how offshore partnerships actually function.

I had been overseeing a software delivery partnership with a team in Vietnam for long enough to have opinions about it. We had regular meetings. We tracked delivery metrics. We sent requirements documents and received working software in return. The partnership looked functional from where I sat, which is exactly the problem I flew twelve hours to investigate.

The first thing I got wrong was assuming honest feedback would be easy to get

I prepared carefully before the trip. I built a conversation guide. I thought through what I wanted to learn and, more importantly, how I needed to ask in order to get honest answers from a team whose culture does not easily produce criticism in the presence of a senior visitor.

The first meeting confirmed what I had prepared for: every question about the partnership came back positive. Everything was working well. Requirements were clear. Communication was good. The team was happy. It was, in other words, exactly the kind of feedback a senior visitor receives when the team has concluded, probably correctly, that honesty carries more risk than a pleasant non-answer.

I had anticipated this, which is why the preparation mattered. The approach that eventually worked was to stop asking people to evaluate the partnership and start asking them to describe systems. Not “is the requirements process working” but “walk me through what happens from the moment a requirement arrives to the moment a spec goes to an engineer.” Not “do you feel you can raise concerns” but “when something is ambiguous and you can’t get clarification quickly, what do you actually do.” Questions about systems rather than people made honesty feel safer, because the person wasn’t criticizing anyone, they were just describing a process. That shift in framing was the most important preparation I did.

What came out of those conversations was specific and actionable. Two things surprised me enough that I want to share them.

Cars are not cars

Picture a woman in her late thirties. She lives forty minutes outside a mid-sized city in a state where public transit means a bus that runs twice a day. She works a job that requires her to be there at seven in the morning. She has two kids in two different schools. She just got a repair estimate on her car that is eight hundred dollars she does not have, from a dealer whose service department is running three weeks behind. The car is how she does everything. Without it, in a very literal sense, she cannot work, her kids cannot get to school, and a doctor’s appointment becomes a logistical problem she may not be able to solve. She is not shopping for transportation. She is protecting the infrastructure of her entire life.

The team in Vietnam did not have a feel for that person. They understood cars as products. They understood vehicle service as a transaction. What they did not have, and could not have without living in a market built entirely around car dependency, was an intuitive sense of what is at stake for the customer on the other side of the software they were building.

Vietnam’s primary personal transport is the scooter. Ho Chi Minh City has something like nine million of them (and they all cross the road at the same time). The relationship between a person and their scooter is coherent and real. In many structural ways it mirrors car ownership in the United States. Close enough that it’s easy to assume the understanding transfers. It doesn’t, because the stakes are not remotely similar. Nobody’s ability to keep their job depends on whether their scooter starts tomorrow.

I had never made any of this explicit in a requirements document. Why would I? It is so obvious to anyone who has spent time in car-dependent America that it doesn’t feel like context worth providing. It just feels like reality.

And here is the thing that has been bothering me since I got home. I flew to Vietnam to address a context gap on the other side of the world, and in doing so I realized the same gap exists three desks away from me. I have colleagues who have spent their entire careers in cities like New York City or Washington, D.C. where car ownership is optional. These are people who take the subway to work and couldn’t tell you the last time they needed a car to do anything important. They understand the market we serve intellectually. They do not feel it the way someone who grew up where the nearest grocery store is fourteen miles away feels it. The offshore team’s gap was more visible and more complete. But the domestic version has been sitting right next to me, unaddressed, because the people who have the intuition don’t think to say it and the people who need it don’t know to ask. Neither group knows the other exists.

The fix is not a training program. It is a document, written in plain language, that explains what a car means in the markets this industry serves. Not a product spec. A human document about what is actually at stake for the person in the dealership and why. That document would be useful to our offshore partners. It would probably be useful to some of our own people too. We just haven’t written it because it has never occurred to anyone that it needed to be written.

The motivation structure is not what I expected, and that’s the risk

Back to the engineer and what he said about national pride.

The company I visited is one of Vietnam’s largest technology companies. They have a stated mission that includes, in real terms, putting Vietnam on the global technology map. This is not empty corporate language to the people who work there. The engineer who said what he said was not performing company values. He meant it personally. Shipping good software for an American company was, in his mind, evidence that Vietnam belonged in the conversation with the world’s leading technology organizations.

That is a remarkable source of motivation. The team I met was more appreciative, more flexible, more willing to go the extra mile than most domestic teams I have managed. There was a quality of investment in the work that I noticed almost immediately. By the end of the first day I had started to understand where it came from. By the end of the trip I understood why it was the most important management problem I had encountered in years.

A team that cares this deeply about the work, and that is also culturally conditioned not to push back on senior direction or surface problems upward, will work harder and longer in the wrong direction without telling you. The enthusiasm and the silence come from the same instinct. If doing well for your company is connected to your country’s reputation, then admitting that the requirements are unclear, or that the pace is unsustainable, or that the work has been going the wrong direction for two weeks, carries a weight that goes beyond the professional. You don’t say that. You work harder.

When I asked directly about work-life balance and weekly hours, I got the same polished deflection I had received earlier about partnership health. Fine. Good. No problems. I had expected this and didn’t push on it directly. Instead I paid attention to what I could observe. Engineers working hours that would be considered unusual by any domestic standard. A willingness to take meetings and respond to messages at times that suggested the boundary between work and not-work had largely dissolved. Significant time spent outside our project on internal company initiatives, stacked on top of their primary commitments. And then, at lunchtime on one of the days, I walked through the office and saw engineers asleep at their desks.

I learned later that desk sleeping at lunch is not uncommon in Vietnamese office culture, and I want to be careful not to overread it. But in that moment it forced a question I hadn’t planned to ask: was the leadership team aware of how their people were spending their time? The answer, when I found a way to ask it indirectly through a systems framing, was illuminating. The leadership could speak fluently to delivery metrics. They could not speak fluently to sustainability. The metrics were the point. The metrics were perfect.

That is when I understood the real problem. The team had perfect delivery records on our account. Every commitment met. Every sprint completed. No missed targets. On our side, we consider it a sign of healthy estimation when teams miss some commitments. A perfect record doesn’t mean the team is exceptionally capable. It usually means the estimates are padded, the scope is being quietly dropped, or the team is absorbing the gap through hours that don’t show up anywhere. For this team, a missed commitment was apparently unacceptable in a way we had never intended and never communicated. We don’t hold our own domestic teams to that standard. We wouldn’t want to. But nobody had ever told them that.

The team was optimizing with tremendous effort and genuine pride for a signal we had never meant to send. They were building in the dark on ambiguous requirements rather than waiting for clarification, because waiting felt like underdelivering. They were working hours that would concern any manager who knew about them, in service of metrics we would have been happy to see them miss. None of this was in any status report. None of it was visible from Atlanta. All of it became visible the moment I was in the room asking about systems instead of satisfaction.

This means that the positive signals most offshore partnership managers rely on are not reliable indicators of partnership health when the team is motivated this way. High responsiveness, consistent delivery, low friction, absence of complaints: all of these are exactly what a deeply motivated, culturally deferential team produces regardless of what is actually happening underneath. You cannot manage this passively. You have to ask directly whether the pace is sustainable, whether commitments are being met through hours rather than efficiency, and whether there is anything the team has wanted to raise but hasn’t found a safe moment for. And you have to ask in a way that makes honesty genuinely feel safe, which is a different skill from simply asking the question.

The question I came home with

Both observations come down to the same thing: context that is obvious to the people who have it does not travel on its own. Car culture context doesn’t appear in a requirements document. The psychological reality of a motivated offshore team doesn’t surface in a status call. Someone has to go get it, and then figure out how to build structures that make the transfer reliable rather than dependent on a senior leader periodically flying to the other side of the world.

I came home with specific things to fix. The requirements process. The feedback loops. What we actually mean when we talk about delivery commitments. The domain knowledge everyone on our side takes for granted. These are all addressable, and we are working on them.

But the harder question is still sitting with me, and I don’t have a clean answer to it. The engineer who said the work was a matter of national pride is still building software for our company. He is doing it with a level of investment and personal commitment that I suspect most of the people on my side of the partnership don’t know exists. He has attached something that matters to him deeply to the quality of decisions being made in meetings he will never be in, about a product roadmap he has no say in, for users in a country he may never visit.

What do you owe someone in that position? What does it mean to be a responsible steward of that kind of trust when most of the people in your organization don’t even know it’s been extended to them?

I don’t think the answer is complicated in principle. You go. You ask questions designed to make honesty feel safe. You tell them what their work actually does in the world. You fix the things that are broken on your side of the relationship. You treat the metrics skeptically instead of gratefully.

What I know for certain is that you cannot do any of it from Atlanta.