One Team, Two Countries: Running UK and Offshore Engineering Without 'Us and Them'

The Problem Is Structure, Not Geography

I've worked with distributed engineering teams for most of my career, first while working in India and later from the UK as a technology leader. The pattern I see go wrong most often is not about skill, cost or even time zones. It is about structure.

When the UK team designs and the offshore team builds, you get "us and them" almost immediately. One side feels it does all the thinking and all the late-night firefighting. The other side feels it gets tickets without context and blame without authority. Both are right, and neither is the problem. The org chart is.

Running UK and offshore engineers as one team is a deliberate design choice. Here's what I've found works.

Organise by Domain, Not by Location

The single most important decision is how you draw team boundaries. There are three common models:

Model	How it works	What goes wrong
Location-based	UK team does design and "hard" work; offshore team does delivery or maintenance	Two-tier culture, handoffs, offshore engineers never own outcomes
Function-based	Offshore does QA or support; UK does development	Quality becomes someone else's problem; slow feedback loops
Domain-based	Each team owns a product domain end to end, with members in both locations	Needs deliberate overlap and good written communication

Domain-based ownership is harder to set up, and it is the only one I'd choose. A team that owns subscriptions, or checkout, or fulfilment integrations, owns the design, the code, the on-call rota and the outcomes, regardless of where each engineer sits.

Two refinements help:

Make sure every domain has senior engineers in more than one location, or at least a clear path to that. If all the technical leadership for a domain sits in one country, you've recreated the location model with extra steps.
Let offshore engineers lead domains. Nothing breaks "us and them" faster than a domain lead in the offshore office whose UK colleagues bring design questions to them.

Your repository structure can help or hinder this. As I wrote last month in my post on multi-repo vs monorepo, clear ownership boundaries in code make it much easier to have clear ownership boundaries in people.

Protect the Overlap

Time-zone overlap is a finite resource. Treat it like one.

Take a UK and India pairing as an example. India is four and a half hours ahead of the UK in summer and five and a half in winter. If the UK team works roughly 9:00 to 17:30 and the India team works roughly 10:00 to 18:30 local time, you have around four to five hours of shared working day, depending on the season. That's enough, provided you spend it well.

What I protect in the overlap:

Stand-ups and planning, so the whole team is in the room.
Design discussions and pairing on difficult problems.
Incident handovers, when needed.

What I push out of the overlap:

Status updates that could be written.
Code review that doesn't need a conversation.
Meetings where only one location is really participating.

A simple rule: never schedule a meeting that requires one location to join outside normal hours on a routine basis. If it's necessary, rotate the pain.

Write Things Down

Distributed teams run on writing. Without it, decisions get made in the office where they happened to come up, and everyone else hears about them later, if at all.

The practices I rely on:

Architecture decision records (ADRs) for anything significant: context, options, decision and consequences, in the repository next to the code.
Written proposals before meetings. A short design doc circulated a day ahead means the meeting is about the decision, not about explaining the problem.
Async decision windows. For non-urgent decisions, post the proposal, give everyone at least one full working day in their own time zone to comment, then decide and record it.
Recorded demos for people who couldn't attend live.

A lightweight ADR template is enough:

# ADR-042: Move delivery slot calculation to the fulfilment service
 
## Status
Accepted
 
## Context
Slot logic is duplicated in checkout and account management.
 
## Decision
Fulfilment owns slot calculation and exposes it via an internal API.
 
## Consequences
Checkout depends on fulfilment availability; we add caching and a fallback.

Writing things down also helps people working in a second language, who can read at their own pace rather than keep up with fast, idiom-heavy discussions.

Fair Career Paths

This is where many offshore models quietly fail. If promotion to senior or staff roles only happens in the UK, your best offshore engineers will leave, and they will be right to.

What fairness looks like in practice:

One engineering career framework for all locations, with the same levels and expectations.
Calibration across locations, so a senior engineer means the same thing everywhere.
Visible, high-impact work for everyone. Rotate who presents to leadership, who leads incident reviews and who owns the interesting projects.
Invest in travel. Bringing people together in person, in both directions, pays back for months afterwards. It shouldn't always be the offshore engineers who travel.

Pay will differ by market; that's normal. Opportunity shouldn't.

Vendor, Direct Hire or Something in Between

How you engage offshore engineers shapes how much of this you can do.

Model	Strengths	Weaknesses	Best for
Project vendor (fixed scope)	Fast to start, low commitment	Outcome ownership stays with the vendor; knowledge leaves at the end	Well-defined, time-boxed work
Dedicated vendor team (staff augmentation)	Named engineers, scalable, vendor handles HR	Dual loyalty; career paths owned by the vendor	Scaling quickly while you learn the market
Employer of record	Direct relationship without setting up an entity	Cost overhead; some local practices harder to offer	Small numbers of direct hires in a new country
Own entity, direct hire	Full ownership, strongest culture and retention	Slowest and most expensive to set up	A long-term, sizeable team

My view: whichever commercial model you use, manage the engineers as members of your team. Include them in rituals, reviews and career conversations, even when their contract is with a vendor. If the vendor won't allow that, find another vendor.

Rituals That Work

Rituals that have held up for me across distributed teams:

Team-level stand-ups in the overlap, not location-level ones.
Rotating facilitators for retros and planning, across both locations.
Written weekly updates from each domain team, readable by anyone.
Blameless incident reviews that include whoever was on call, wherever they are.
Shared on-call with a follow-the-sun element where the time zones help, rather than the UK team carrying every out-of-hours page.
Regular in-person time, even once or twice a year.

Advice by Stage

Startup: avoid splitting across locations until you have strong written habits. If you must, hire senior people offshore first, not juniors.
Scaleup: move to domain ownership early and set up a single career framework before the team grows past the point where it's easy to fix.
Enterprise: invest in leadership in every location, and measure retention, promotion rates and incident load by location to catch drift towards "us and them".

The Takeaway

Cross-country teams succeed or fail on structure. Give teams ownership of domains rather than locations, protect the overlap hours, make decisions in writing and give everyone the same route to senior roles. Do that, and geography becomes a scheduling detail rather than a culture problem.