The drift always looks the same. The engagement starts strong: good engineers, fast onboarding, early wins. Around month three, pull requests start needing an extra round of review. Questions you thought were settled in week two resurface in new forms. The work coming back is technically correct and subtly wrong for the product. The reflex diagnosis is a communication problem, so the calendar fills up: another standup, a written daily status, a dashboard nobody reads. Six weeks later the drift is unchanged, because the failure was never in the pipes. It was in what the pipes were carrying.
Communication is bandwidth. Context is state. Offshore engagements fail on state.
Why context decays faster offshore
Context is everything a team knows that never got written down: why the payments service is structured the way it is, which customer drove that strange requirement, what was tried in 2024 and abandoned. Colocated teams replenish this state constantly without noticing, and three structural facts drain it faster across an offshore boundary:
- No osmosis: a colocated engineer absorbs decisions from conversations they were never part of. An embedded remote engineer receives only what someone deliberately writes down or says to them directly. Everything else silently fails to transfer.
- Compressed sync windows: when the shared hours are spent on status updates, the why conversations, the ones that actually move context, never get scheduled. Decisions made after the offshore team's day ends arrive the next morning as unexplained changes.
- Rotation resets: when an engineer leaves or a vendor swaps one out, every piece of context that lived only in their head leaves with them, and the replacement starts from whatever was written down, which is usually not much.
Context engineering: the practices that hold state
The fix is not more talking. It is treating context as an engineered artefact with an owner, a home, and a definition of done:
- Decision records: one paragraph per irreversible decision, in the repository next to the code it explains. What was decided, why, and which alternatives were rejected. Thirty minutes to write, and the difference between month-nine archaeology and a one-line answer.
- A zero-history onboarding runbook: written assuming the reader knows nothing your team just knows, and tested on every new joiner. The gaps they hit in week one are the runbook's bug reports. Fix them before the next person arrives.
- Documentation inside the definition of done: a feature is not finished until the context needed to maintain it exists outside its author's head. Enforced in review, not requested in retrospectives.
- Ask-in-public norms: questions go to channels, not direct messages, so every answer becomes searchable state instead of private knowledge that dies in an inbox.
- Pairing across the boundary: a regular rotation where onshore and offshore engineers build together. Pairing moves the tacit knowledge that documents never capture, in both directions.
The rituals worth keeping, and the theatre worth cancelling
Meetings are how struggling engagements try to buy back trust, and most of what gets added is theatre. Three rituals earn their calendar slots: a weekly delivery review anchored in the code itself, pull requests and quality trends rather than slideware; a sprint demo where the offshore engineers present their own work to your stakeholders, which builds ownership on one side and product context on the other; and a monthly retro on the engagement itself, not the sprint, where both sides say what is actually getting harder. Nearly everything else can go. The daily written status report is surveillance wearing alignment's clothes. The duplicated standup, one internal and one for the client, tells you the real conversation is happening somewhere you are not. Cancel them and spend the hours on pairing.
Measure state, not activity
Activity metrics flatter drifting engagements: plenty of commits, plenty of meetings, plenty of green dashboards. State has its own signals, and a 90-day scorecard should read them instead:
- Review-cycle latency: the number of rounds a pull request takes to merge. When it rises over time, you are watching a context gap, not a competence gap.
- Bus factor per system: count the systems only one person can safely change, and drive each count to two through pairing and decision records.
- Question archaeology: how often does the same question get asked twice by different people? Every repeat is a piece of context that failed to persist the first time.
- Velocity against your own baseline: measured against the team's own first stable quarter, never against industry benchmarks that describe nobody in particular.
- The escalation-path test: by day 90 something small should have gone wrong and travelled the escalation path. A path that has never fired is not proven robust. It is untested.
What you own, and what your partner must own
None of this works if the labour is divided wrongly. You own product direction, priorities, architectural authority, and the final bar for what merges. The partner owns the health of its engineers inside your system: weekly performance reviews, independent code-quality checks against explicit standards, mentorship, and a replacement guarantee that includes structured context handover, because a guarantee that swaps the person while the state walks out the door is worth very little. Above both sits one named owner on the partner side who answers for the engagement as a whole. This is the shape we ran for a Singapore university's student platform: a squad of five under a single accountable owner, from kickoff through commissioning and multi-year support. The university's staff measured milestones and inspected quality. They did not chase status reports.
The playbook is unglamorous. Write decisions down where the code lives. Test the runbook on real newcomers. Cancel the theatre and pair instead. Measure state, not motion. Teams that do this stop having offshore problems, and discover they simply have engineering management, done deliberately, with the honesty that distance forces on you.
