How to fix a low-trust relationship across an ocean
I frequently end up working with clients who have a team based offshore, often in India. And somehow, there’s frequently a feeling of frustration and disappointment when working with them due to a general sense of a lack of communication.
What this lack of communication exactly was changed across each client. But I kept running into a variant the same frustrating dynamic:
- Agreement in meetings, but missed delivery
- Low visibility into what’s actually happening
- Difficulty getting proactive input
- Frustration from the US team
While I haven’t been responsible for fixing this dynamic with any of my clients, I’ve wanted to be better able to advise them on how to turn this dynamic around. So instead of making up some advice, I went ahead and interviewed six different people who have managed to turn this type of situation around.
It’s easy to blame culture. But the fixes are about trust.
There absolutely is a difference in cultures between India and the US, just like any two locations. The cultural differences showed up in many of my interviews.
But one thing I realized as I was having these conversations is that the advice I was hearing wasn’t primarily about navigating cultural differences. It was the same advice that I would give when talking about creating successful async work environments.
Every strong relationship and every productive relationship has a strong layer of trust underneath it.
One of the patterns I was seeing with the contractor teams is that the US-based teams I’ve been working with assumed trust was there, as opposed to thinking about how to constantly re-establish trust.
Cultural awareness helps you understand why trust might be missing—but the interventions that actually worked were about building trust and creating structure. These are the same levers you’d pull for any distributed team starting from a low-trust place.
And the way to fix these relationships was not to just say, “Hey, this is what I need from you” and ask for it more loudly, but instead to change the environment, the communication infrastructure, and the incentives to lead to a behavior change.
The disconnect goes both ways
In the most recent case, we got lucky. A member of our product team was headed to India to visit family, so we extended his trip to meet with the offshore team in person.
The biggest insight from that trip: the India team was feeling the exact same frustration we were.
They described the US side as a black box. Tickets got thrown over the wall with little context. Communication happened sporadically. They wanted to do good work but didn’t have what they needed to succeed.
This reframed everything. We had been thinking “how do we fix them?” when the real question was “how do we fix this relationship?” The trust deficit ran in both directions.
The US team assumed the India team didn’t care about our goals. The India team assumed the US team didn’t care about them. Both assumptions were wrong—and both were creating the exact behavior that confirmed the other side’s suspicions.
Once we understood this, our interventions changed. We stopped trying to enforce behavior through process and started investing in connection. The results came faster than any of us expected.
If you’re struggling with an offshore team, it’s worth asking: what does this relationship look like from their side? The answer might surprise you—and it might reveal that you’re contributing to the problem more than you realized.
The decision guide: Match the symptom to the intervention
While there are many different variants of not having the right level of trust with offshore contractors, I would say that there were three key symptoms that I saw emerging from both my own experience and the interviews I was conducting.
Choose your interventions based on the behavior patterns you’re seeing. One thing that there was consensus around was layering in interventions to become more effective.
Radio silence: You get finished work only
One pattern that I run into is where work is happening and tickets are being completed, but there’s a black hole effect. Between when the work starts and the work ends, there isn’t a strong sense of what is happening or what choices are being made.
When trust is lacking, sharing insecurities, questions, and uncertainty can feel like admitting incompetence. So much of the fix here is creating psychological safety—making it clear that sharing work in progress is expected and that there won’t be negative consequences for asking too many questions.
Start with standups and chit-chat. As challenging as it is given the time zones, 15 minutes of verbal communication every day goes a long way. As Jason Meresman said, “Not having the daily standup is the same as saying I’m not going to take any corrective action.”
One piece of feedback we got from the team in India was that they felt like they didn’t know much about us. When there were meetings, we would jump immediately into the work.
Standups give you 15 minutes each day not only to talk about work but to get a little bit of a sense of each other’s lives. What you ate for dinner or what your weekend plans are.
Those little moments of interaction help build trust between people who have never met face to face. We assumed the trust was already there instead of building it.
Move decisions into shared channels. One thing we saw: a lot of conversations were happening via DM or on the contractor’s internal Slack channel. No wonder it felt like radio silence.
Conversations, even if they don’t involve everybody on the team, need to happen somewhere where the whole team can see them. It’s important to model how decisions should get made and what good communication looks like.
We asked the teams to move conversations into public channels so that there was a sense of chatter within our workspace, and did the same on our end.
Both of these interventions work because they create repeated, low-stakes opportunities to build familiarity. Trust accumulates through dozens of small interactions where nothing goes wrong.
The waiting game: No action without explicit direction
Another pattern I’ve seen is when the team waits for direction. If you don’t tell them exactly what to do, nothing happens. If it’s not documented precisely in Jira, it doesn’t get done. When they run into roadblocks, nobody flags them.
This pattern almost always emerges from an environment where they’ve been criticized for taking initiative. There’s an expectation that they were hired to output code, not for their technical thinking—so they wait for direction instead of acting independently.
Double down on business context. Through our product manager’s research in India, we found out that nobody had walked the current team through the product strategy, user base, or how the various components fit together. That onboarding had been done years ago with different people—there had been turnover since then.
We took the time to walk everybody through who our users were, how they used the product, and how it fit into the overall business. The team was thrilled to get this context.
Without context, the team can’t take initiative—they’d just be guessing. Sharing business context signals: “We trust you with this information, and we expect you to use it.”
Treat the team operationally like internal staff. The more you can treat your contractors like employees, the better. Darin Swanson used this approach explicitly: “The company decided they weren’t employees—but in every other facet, we asked how we could treat them like employees. That drove pretty much every decision.”
If you want them to take ownership, treat them like owners. Darin even ran performance reviews with contractors on the same cadence as full-time developers.
Model the behavior you want to see. If the goal is to shift from a world where every ticket needs to be fully explained to one where they ask questions proactively, modeling goes a long way.
Lee Almegard made a practice of publicly asking for help and flagging when she was stuck. As she put it: “I was trying to ask for help in public as an example to them—to show it’s safe to ask questions and to flag that you’re stuck.” She would tag others on the team, and they would jump in, demonstrating that asking for help doesn’t lead to punishment or embarrassment.
It took time, but the more she did it, the more comfortable others felt doing the same.
For people to take ownership, you have to treat them like owners. You can’t just tell them that’s the behavior you want—you need to include them in the work the same as anyone else. Every time you exclude them from context or decisions, you’re reinforcing that they’re outsiders who need permission to act.
The cold shoulder: Everything just feels extra hard
In other contexts, the relationship with a contract team has just felt tense and awkward. There’s no single word for it, but it feels like there’s no openness. Things are moving along, but everything is a little bit painful.
This might be the line between a lack of trust and active mistrust. There are almost certainly skeletons in the closet—whether from working with your company or other overseas clients where they got burned badly. They’ve learned it’s best to keep their heads down and just do the job.
Reset working agreements. Sometimes it’s healthy to sit down and talk about how you actually want to work together. Bring both teams into the room and decide what good looks like—rather than deciding unilaterally how things should work.
Roger Marley has used this approach to great success: “We do a show and tell of honest frustrations of what we felt from the other side, on the basis that we’re going to do a trade. You’ve had this difficulty with us—we’re going to give you this. And then you’re going to do the same thing for us. That starts to reduce the distance between the two.”
The emphasis is on making it an equal partnership when everybody comes into the room. By saying the mistrust out loud, you create a structured way to rebuild rather than pretending the problems don’t exist.
Use a neutral intermediary if needed. Sometimes there’s so little trust that contractors feel uncomfortable raising any issues while a leader is in the room. In that case, it can help to designate someone they see as a peer—someone who can have one-on-one or small group conversations to collect feedback and relay it to leadership.
Ryan Alexander described his approach: “The main thing I did was act as a surrogate communicator who could say no. That was what they needed—someone who could push back.” He positioned himself as an advocate who could translate their “soft yeses” into actual pushback, since doing so directly felt culturally unsafe to them.
Over time, the neutral intermediary can build relationships that encourage people to speak up in more public forums. The more that happens, the less tense the relationship feels overall.
By sending our product manager to India, we accidentally did this. The team saw him as a peer instead of a leader and so could have more honest conversations.
If things feel really tense and awkward, the trust deficit is likely severe. That needs to be addressed before anything else can be fixed.
What has never worked for me
A narrative had been circulating at my client: if only we could provide more detailed tickets, better-explained PRDs, a RACI, and ask for more Slack communication, this would all be solved.
Talking with the developers one-on-one showed just how wrong this was.
More detailed documentation, more pressure, more asking for things—none of it changes behavior on its own. It’s easy to believe that since there’s a client-vendor relationship we can just ask for what we want and get it immediately. But that type of relationship doesn’t buy you teammates.
If you’re hearing demands for contract partners to behave differently in your own organization, it’s a sign to pause and focus instead on interpersonal connections and shared context. Those are the things that actually move the needle.
What I do differently now
I had a kick-off call with a few developers for a new initiative this week. I prepared the epic and created a workflow chart to show them what the user journey needed to be.
I started with small talk—asked about one developer’s recent PTO. Then I explained not just the initiative, but why it mattered for our users. When they offered to build a POC, I pushed back: could we collaborate on an architecture diagram first?
“We’re used to being given the architecture, not being asked to design it,” one of them said. I could tell he was excited about the shift.
In one call, I’d hit several of the patterns from this article: small talk to build connection, business context so they understood why the work mattered, and treating them like owners by asking them to design rather than just execute.
Notice what I didn’t do: I didn’t ask them to communicate differently. I didn’t send a document explaining “how we work here.” I didn’t lecture them about proactive communication.
I just treated them like I’d treat any team I wanted to build trust with.
Culture and time zones will always make offshore relationships harder. But the playbook for fixing them isn’t some special cross-cultural toolkit. It’s the same work you’d do with any distributed team starting from a low-trust place: show up consistently, share context generously, and treat people like partners instead of vendors.
The gap isn’t cultural. It’s relational. And relational gaps close the same way everywhere—one interaction at a time.