Outsourcing Communication: Stop Talking to the Project Manager (and 7 More Offshore Lessons)

Early in my career, I heard nothing but horror stories about offshore development. A friend would tell me how he hired a team overseas, waited three months, and got back code he had to throw away. “It was easier to do the work myself,” he said. The complaints were always the same: the developers were hard to understand, they didn’t follow directions, and the code quality was bad.

Almost none of those were skill problems. They were outsourcing communication problems.

I’ve since hired developers in Russia (St. Petersburg, back in 2012), Uruguay, and the Philippines (starting in 2018), and worked alongside engineers in a handful of other countries. I built a team of more than 20 developers in the Philippines at Stackify before we sold it in 2021, and that setup worked so well it turned into Full Scale. Three offshore attempts, three successes, after a decade of hearing it couldn’t be done.

Here is what actually separated the wins from the disasters. None of it was the hourly rate, and the lesson that surprises people most is about who you’re even allowed to talk to.

Lesson 1: Communication decides it, not the time zone or the rate

Most people choose an offshore partner on price. Then they obsess over the time zone gap. Both matter, but neither is the thing that sinks the engagement.

Software development is about communication. Being able to tell someone else why you are building something, and how you need to solve the problem, is what decides success or failure. That is true with the engineer sitting next to you, and it is doubly true with one who is 8,000 miles and 14 hours away.

When I was deciding where to build my Stackify team, I cared about English fluency and communication skills more than anything on the resume. A brilliant developer you cannot have a real conversation with will cost you more than a good developer you can. The rate gap is real, the savings are real, but they evaporate fast when every requirement turns into a week of back-and-forth.

Hiring globally isn’t a fallback either. Roughly 90% of software developers don’t live in the US, according to the Stack Overflow Developer Survey, so most of the talent was always going to be somewhere else. The question was never whether good engineers exist abroad. It was whether you can communicate with them well enough to get the work done. It’s also the core of why companies use offshore talent: the skills were always global, the salaries weren’t.

Get the communication right and offshore works. Get it wrong and no discount will save you.

Lesson 2: Stop talking to the project manager

This is the single biggest pattern I see in failed engagements, and almost nobody warns you about it.

I’ve talked to founders running teams in other countries where they have only ever spoken to one person, the technical project manager. Every other developer hides behind that person. Sometimes it’s a language gap. Sometimes it’s a cultural rule about who is allowed to talk to the client. Either way, you end up with a team you can’t actually communicate with, and a middleman in the way of every decision.

You don’t have a relationship with the people writing your code. You can’t tell if they understood you. Feedback takes a day to travel each direction because it has to pass through one human bottleneck. The PM smooths everything over in the status meeting, and you find out three weeks later that the team built the wrong thing.

The fix is structural, not a better Slack channel. Talk to your developers directly.

AMC Theatres is the best example I can point to. The developers we placed in the Philippines are treated as full AMC engineers, not as a contractor block sitting outside the team. They’re in the same Slack channels, the same code reviews, and held to the same standards as the engineers in Kansas City. No middleman in between, and the developers care about the product the same way the in-house team does. That is what makes an offshore team actually work.

One nuance from my own experience: a proxy isn’t always the problem. My Uruguay team at Stackify ran through a single product owner who took my ideas and iterated on them, and he was excellent at it. It freed me up to run my main company. The difference is choice and access. I picked that arrangement, and I could still reach the developers whenever I needed to. The failure mode is the middleman you can’t get around, the one who exists because nobody else is allowed to talk to you.

If a vendor won’t let you talk to the people building your software, that is your answer. Walk away.

Lesson 3: Don’t hand your requirements over the wall

Here is the mistake that creates most of the horror stories.

Most offshore collaboration fails because people simply hand a bunch of requirements over to an outsourcing firm. Then, they expect to get back a successful project.

That is project outsourcing, and it is the weakest form of the model. You write a spec, throw it over the wall, and hope. There is no shared understanding of the problem, no one on the other side who cares about the outcome, and no way to course-correct until the deliverable shows up wrong. If you genuinely have a scoped, hand-it-off piece of work, there is a right way to outsource a software project, but it takes more structure than throwing a spec over the wall.

The better model is staff augmentation, not project outsourcing: you hire developers to work directly for you, long term, as part of your team. They sit in your standups, learn your product, and build context that no spec could ever capture. This is why I tell people that staff augmentation is the right way, and why staff augmentation beats project outsourcing for anything long term. We aren’t in this for some three-month project.

The over-the-wall way	The team way
Write a spec, hand it off, wait	Developers join your standups and planning
Vendor owns the “how”	You own the product, they own the craft
Find out it’s wrong at delivery	Course-correct daily
No shared context	Context compounds over months

Make sure you work with a dev agency that cares about your product, not just your project.

Lesson 4: Over-communicate, then do it again

With a co-located team, a lot of communication happens by accident. Someone overhears a hallway conversation. A question gets answered in two seconds because the person is right there. None of that happens across a 14-hour gap, so you have to make it happen on purpose. This is the heart of managing an offshore development team well, and it’s a habit, not a tool.

My rule is to over-communicate. A few extra words of context up front saves a full day of someone guessing, building the wrong thing, and waiting for your next morning to ask about it. That guessing is the hidden tax of bad communication on distributed teams, and it is expensive. A two-day feature balloons into two weeks of clarification.

One small thing that matters more than it should: keep your language simple. Even with fluent English speakers, I won’t reach for a word like “intrinsic” when “built-in” does the job. Over-communicate on substance, simplify on vocabulary. The goal is to be understood, not to sound clever.

Lesson 5: Show the work, don’t just describe it

The best discovery I made in my early years managing remote developers was the annotated screenshot.

For my first two or three years acting as the product owner, I struggled to point at things. I’d try to describe a UI problem over chat and it never quite landed. The day I started taking a screenshot, drawing a few boxes and arrows on it, and sending that instead, my communication problems got noticeably smaller. I look back and wish I’d had those two years back.

I also record short videos. I’ll make a few notes, hit record on QuickTime, and walk through what I need in two or three minutes. Why? Because a developer can watch it again and again until it’s clear. Sometimes the best way to communicate is to let someone see and hear what you mean, because plain text loses the context.

A quick toolkit for outsourcing communication that travels well across time zones:

• Annotated screenshots for anything visual. Draw a few boxes and arrows and add one sentence of context.
• Short screen recordings for anything with more than two steps. Keep them under five minutes.
• Written summaries of every decision, so it survives past the meeting and doesn’t depend on memory.
• Video calls for the conversations that matter, because you need to see whether someone actually understood you.

Lesson 6: Say the warnings out loud, not just the spec

Clarity is the fuel of a productive team. When it’s missing, momentum dies one “let me double-check” at a time. And clarity is not just telling people what to build. It’s telling them what to watch out for, where to speed up, and where to slow down.

I once told a team five times: “Whatever you do, don’t spam their API. We can’t get blocked.” That wasn’t in the spec. It was in the warning. We weren’t just shipping a feature, we were avoiding a costly mistake. That’s what clarity sounds like in practice.

On a co-located team, you’d mention that risk in passing and someone would catch it. On a distributed team, if you don’t say it explicitly and more than once, nobody knows it mattered until something breaks. Narrate your intent, say what you’re not doing and why, and make the trade-offs visible.

Clarity is one of the five pillars I wrote about in Product Driven. As I put it in the book, “product vision without clear explanations is just a PowerPoint deck.” On a distributed team, that deck is all your developers ever see unless you keep connecting the work back to the why. It carries more weight offshore than anywhere else.

Lesson 7: Overlap a few hours on purpose

The time zone difference between the Philippines and Kansas City is 14 hours. On paper that sounds like a dealbreaker. It turns into an advantage once you build in some overlap.

My teams shift their schedule so we share a few hours every day. That window isn’t really for handoffs. It’s for the standup, the quick Zoom when someone is stuck, the back-and-forth that builds rapport. You can’t build chemistry with a team you’re never online with at the same time. Three or four shared hours covers it for most engagements.

While my US team sleeps, the team in the Philippines handles on-call and keeps work moving, so by the time I wake up things have progressed. That only works if you protect the overlap window and use it well.

Lesson 8: Hire people who will tell you when you’re wrong

The quietest communication failure is the one that sounds like agreement.

A developer nods, says yes, and builds exactly what you described, even though they could see it was the wrong call. That’s worse than a language barrier, because everything feels fine right up until the work comes back wrong. Whether a developer will speak up when they don’t understand, or push back when the spec is broken, matters more than the hourly rate on their invoice.

So I hire for it, and I build an environment that rewards it. I want the engineer who asks the annoying clarifying question and the one who says “this doesn’t feel right to me” before writing a line of code. Without that, your team will faithfully ship your mistakes and never tell you they saw them coming.

The Philippines earns most of the credit for why Full Scale has worked as well as it has. There’s no language barrier, English fluency is excellent, and people grow up consuming American culture, so they understand the references and the working style. The culture rewards friendliness, and people genuinely want to do a great job. That’s close to the perfect personality for a remote team. The fluency is real too, the country is the third-largest English-speaking nation in the world.

The thread through all eight lessons

If you reread these, none of them is really about a tool. Slack and Zoom and annotated screenshots help, but they’re not the point. Every lesson is about the same thing: building a real working relationship with the people writing your software, the same way you would with anyone down the hall.

That’s why the model matters more than the tactics. When you hire a dedicated team you talk to directly instead of buying a project behind a wall, good communication stops being something you fight for and becomes the default. We’ve held a developer retention rate above 93% partly because the engineers are treated as part of the client’s team, not as anonymous output. That stability matters when US tech turnover runs in the low double digits every year: a team you can communicate with is also a team that sticks around long enough to build real context. It’s part of why we’ve been Great Place to Work Certified in the Philippines and named to the Inc. 5000 four years in a row.

If your team works well remotely, it will work well globally, too.