Do You Need a Project Manager for Your Offshore Development Team? Pros and Cons

Nothing wrong with a PM. Somebody needs to keep the project moving, watch the calendar, catch trouble before it turns into a crisis, and vendors have filled that role themselves for as long as I’ve been doing this. Fine setup, by itself.

Here’s where it goes sideways. Week one, you meet the project manager, you hit it off with them. A year later, they’re still the only person from the vendor’s team you’ve ever talked to. Every requirement you send goes through them on the way in. Every developer question goes through them on the way back out. You find out about a mistake in the work after it’s already shipped, not before.

I’m not telling you to ban the vendor from ever supplying a PM, that’s the lazy version of this advice. Talk to the developers as much as you talk to the PM, daily if the work calls for it. Figure out who that PM actually works for. Whoever that is decides whether reaching the developers is your call or the vendor’s.

What a project manager actually does on an offshore development team

Strip away the job title and a PM’s day looks the same everywhere: run the daily standup, turn client requests into tickets, chase status updates, catch problems before they become problems, keep the schedule from slipping while everyone assumes it’s fine.

It’s a legitimate job. Someone has to do it. A good PM bridges communication gaps across time zones, gives you access to developers you couldn’t hire or oversee directly on your own, and gives you one point of contact when things start running behind. A poor PM is just another salary and another layer of interpretation between you and the code. That person also has eyes on your codebase and your IP, which is worth a real vendor security review rather than a handshake.

All of that is true, and none of it is why I think you don’t need one. On a short-term project with a deliverable defined by contract, a vendor-side PM can genuinely be enough. The spec is already written and the scope is locked, so there’s less room for the PM to rewrite the story after the fact. That changes on a longer engagement, the kind that runs for years, which describes most staff-augmentation relationships. That’s where the real question shows up: if things start going wrong, who does the PM answer to?

The question that actually matters: whose payroll are they on

Who does the project manager work for, and are you talking to real engineers every single day? This is the question I use to gauge whether a team will be reliable, and it’s the only one that counts.

When the project manager works for the vendor, there’s only one thing they do when a deadline passes or a feature breaks: manage you. Explain why it happened, explain what the next steps are, get you one more sprint. That’s usually not the individual PM’s fault, most of them are trying their best, it’s the structure they’re stuck in. Their salary comes from the vendor that just failed to deliver on time. You’re essentially asking the vendor to grade their own homework. Economists have a name for this setup: the principal-agent problem, the conflict that shows up whenever the person acting on your behalf has their own incentive to protect first.

When the project manager (or engineering manager, or tech lead) works for you, the incentives are different. They report to your management team. They have all the motivation to bring an issue to light as soon as possible, because the longer it’s hidden, the worse it gets for them. Accountability is now on your side.

Chris Borchers, Chief Technology and Product Officer at Basys, named this exact pattern before he ever worked with us. Here’s how he put it: “You hire a project manager or a technical manager that kind of shields the developers on the other side, and then those developers aren’t able to get close to the customer. They get farther away from the problem, farther away from the customer.” Chris had avoided offshore development “like the plague” for years because of exactly that setup, catching bad code and rewriting it as it came in. What changed his mind wasn’t a better vendor PM. It was no PM standing between his team and ours at all.

The failure mode you should really be afraid of is a PM that works for the other side of the table.

The general contractor test

Outsourcing your software development is a lot like outsourcing your home construction. You need someone there every day to direct all the trades, so you hire a GC (general contractor). You’re not going to spend your day walking around the site shouting at plumbers and electricians, and you’re still going to walk the site, make the calls that matter, and fire the GC if the job is garbage.

Now imagine that the GC works for the roofing company. When the roof leaks, who’s going to go inspect the roof? This is what makes outsourcing your development project very different from outsourcing your construction project. An outsourced project manager is a GC who works for the subcontractor. Your technical leader is a GC who works for you. It could be the founder who’s still involved in the project. It could be an in-house VP of Engineering. Or it could be a fractional CTO that you hire. It’s the same role, just on different sides. And the entire success or failure of your project is determined by who you hired.

Full Scale lays out that split in plain terms:

	Vendor-side project manager	Client-side technical leader
Whose payroll they’re on	The vendor’s	Yours
What happens when a deadline slips	Manages the story, buys another sprint	Surfaces the problem, because sitting on it makes their own job worse
Your access to the actual developers	Filtered through them	Direct, daily
Who grades the work	The vendor grades itself	You do
The AMC Theatres model	Not this	This

The developer accountability problem nobody mentions

But a PM who works for the vendor doesn’t only keep the vendor from being held accountable; they also give the developers somewhere to hide. When everything including every question, every piece of feedback, every “what’s taking so long?” goes through the PM at the vendor, the engineers never get asked about their own work. The PM takes care of that. They smooth it over. They turn “missed deadline” into “scope creep.” The developer who wrote the code that failed? They don’t talk to you. They never talk to you.

How can you hold someone accountable if you’ve never spoken to them?

AMC Theatres, one of Full Scale’s anchor clients, sets this up the other way on purpose. In fact, Derrick Leggett, AMC’s CIO, told us plainly: “It’s a fully integrated team. It’s just that some of the people happen to be living in the Philippines.” Nobody at AMC sends a question to us to ask one of the developers. The developers sit in AMC’s organization, and are subject to AMC’s performance reviews. They’re answerable for their work like anyone else hired in Kansas City.

This is something we sacrifice, by the way. When things go wrong during a sprint, AMC sees what happens. They don’t wait to hear about it from us. And none of us have a wall to hide behind. That’s the model we’ve seen succeed over many years, in a partnership that’s been stronger than other projects built in the opposite way.

So what do you hire instead of a vendor’s PM?

So if you are a non-technical founder, the response isn’t “let the vendor PM protect you,” the response is “get some technical talent on your side of the table before you commit.” That can be a part-time role. I’ve found that a fractional CTO at $5k–$10k per month is inexpensive insurance against the very problem the article discusses. They’ll examine the work and ask the right questions, and report to you. Just make sure that person is technical enough to understand the product, otherwise you’ve just paid someone to do the same job as the vendor PM.

If you have in-house tech leadership (even a single senior developer), treat them as your general contractor, just like you would if you were using Full Scale’s staff augmentation services. The vendors’ developers are yours, and you manage them. Have your leaders manage the offshore developers daily, just like they would manage any other employee. Give them direct access to the team. Don’t have a vendor PM managing the team.

Be upfront about what that will cost. No one will tell you in their proposal, but the vendor PM handled the 1:1s, the mentoring, and the conversations about performance issues. Without them, you’re going to need to step in. And that’s why the “hire some technical talent” bit is important: if you don’t, there’s no one to take those responsibilities.

A final point, unrelated to any of the above.

The old “hand off” model, where you create a spec, hand it over the wall and then wait for it to come back, in whatever form you requested, is dying whether you’re doing it yourself or outsourcing it. AI can already do this.

You need people from your offshore team who will challenge a bad requirement and ask the right question before they write the wrong code. You only get that from someone who has a direct relationship with your business, not someone whose manager has been incentivized to simply accept the ticket as presented.

The verdict

You don’t want a project manager. You want an in-house leader, be it you, the VP of Engineering, or a fractional CTO, on your side of the payroll line, in direct, daily contact with the people writing your code.

If that person also happens to go by the name of project manager, that’s a matter of scheduling. Whose side that person is on is the decision.

If you’re hiring offshore devs under your own lead rather than a vendor’s account manager, that’s staff augmentation done right, and is a completely different thing from the managed-services model, where the vendor manages the whole thing for you.

Good to know what you’re paying for before you do.