The pattern I see managing remote teams
The accidental mistake engineering leaders make that turns a single remote team into a divided one.
A founder told me a few weeks ago that his remote team wasn’t working out. Good developers on paper, he said, but the work kept missing the mark, and he wanted to know if he should swap them for a fresh group.
I’ve had some version of that conversation a few dozen times.
Almost every time, the developers turn out to be fine.
It barely matters whether that team is offshore on the other side of the world or just remote across town. What breaks is the same.
Most engineering leaders never get to see that, because they only ever watch one team, their own. I’ve had the opposite view. Between the remote teams I’ve built myself, in Uruguay, India, and the Philippines, and the 80-plus companies I get to watch up close today, I’ve seen this play out dozens of times over. The failures rhyme. They break in the same handful of ways, for the same handful of reasons, over and over.
You end up running two teams and calling it one
This is the one that gets almost everybody.
You keep the people you can see close. They’re in the building, or at least in your time zone, so you talk to them all day without thinking about it. The remote group gets handed work and a Slack invite and slowly turns into a separate unit you manage from arm’s length. Before long you’re running two groups that share a codebase and not much else.
Nobody decides to do this. It happens one small default at a time, until the two halves have stopped really talking to each other and you’re the only thing left connecting them.
It’s almost never the people. It’s that you’ve quietly built two teams instead of one.
I’ve said for years that if your team works well remotely, it will work well globally too. The reverse is just as true. If you can’t run a remote team well, adding a time zone and a plane ticket doesn’t create the problem, it just makes the cracks louder.
The damage is usually done before anyone writes code
When a team fails, the easy story is that the developers weren’t good enough. Look closer and the real decision almost always happened earlier, at the setup.
The classic version: a company needs more capacity, local hiring is slow, so they find an outsourcing firm, write up a pile of requirements, hand it over, and wait for a finished product to come back. A lot of remote collaboration fails for exactly that reason. You can’t toss a spec over a wall and call it a team.
The next mistake is hiring on price alone. You find a good rate, then chase an even cheaper one, and you pay for it twice in rework and rebuilds. I call that cheapshoring, and it’s the most expensive way to save money I know.
Then there’s the middleman. At a lot of firms you only ever talk to one project manager, and everyone else stays hidden behind that person. You get a team you can’t actually talk to and a translator standing in the middle of every decision. Nobody on that team feels like they own anything, because they don’t.
Tools don’t fix this. Leadership does.
When a remote team is struggling, the instinct is to go buy something: a better project tracker, a new chat app, more dashboards.
Every distributed team on earth already has the same good tools: Slack, Zoom, GitHub, shared docs, and now AI that summarizes every meeting and writes up the action items. The tooling problem got solved years ago.
A tool only moves information around. It doesn’t decide what’s worth saying, who needs to hear it, or whether the team actually understands why they’re building the thing in front of them. That’s a person’s job, and it belongs to the leader.
When people sit in a room together, a lot of communication happens by accident. Someone overhears a problem and jumps in. You settle something in five minutes by the coffee machine. Spread that same team across time zones and all of that accidental communication is gone. Someone has to put it back on purpose, because nobody is going to overhear anything again.
Software development is about communication more than almost anything else. It’s the first of the three skills I argue for in my book, Product Driven: communication, curiosity, and courage. On a remote team, communication stops being something that happens to you and becomes something you do on purpose, every single day.
Keeping the thinking only in-house
There’s a subtler version of the two-teams mistake, and it hides inside good advice.
You’ve heard that you should keep technical leadership in-house, and you should. The architecture calls and the product direction belong with the people who own the business. But plenty of leaders take that one step too far and keep all the thinking in-house. The remote team gets handed fully-formed tickets and told to build exactly that, nothing more.
That turns your remote engineers into order-takers. They stop asking why, they stop catching the bad idea before it ships, and you lose the whole reason you hired good people instead of cheap ones.
The best engineers I’ve worked with anywhere in the world are the ones who push back on the spec and tell you when you’re about to build the wrong thing. You only get that if you let them think.
Keep the direction in-house. Let the thinking happen everywhere.
How the good ones actually do it
The fix is almost boring to say and genuinely hard to do. You run one team.
You put the remote engineers in the same standups, the same code reviews, and the same roadmap as everyone else, held to the same standard. You interview them yourself, the way you’d interview anyone you were about to trust with your product. You hand them real context instead of tickets, and you let them own outcomes instead of tasks.
The best example I have is AMC Theatres. Their CIO, Derrick Leggett, has built a global engineering org where the Full Scale developers in the Philippines are treated as full AMC engineers. He says it better than I can: “It’s a fully integrated team. It’s just some of the people happen to be living in the Philippines.”
That isn’t a vendor on the other side of a wall. It’s one team that happens to be spread out.
This is the model we build at Full Scale, remote engineering teams that work like part of your company instead of a shop you hand work to. But the model matters more than the provider. Whether your people are offshore or just scattered across home offices, the leaders who win stop managing a remote team at all.
They just manage their team. Some of it happens to live far away.