How do you guarantee code quality with an offshore team?
You guarantee code quality by defining it in measurable terms before work starts — a written definition of done, automated gates that block bad merges, a small set of engineering metrics reviewed monthly, and contractual service levels by defect severity. Quality that depends on someone in Berlin reading every pull request does not survive contact with a growing team, a holiday or a busy quarter. Quality that is encoded in the pipeline survives all three.
This is not an offshore-specific problem, which is exactly why it is worth saying plainly: distributed teams do not produce worse code because of distance. They produce worse code when the standard was never written down, because distance removes the informal correction that co-located teams get for free. Write the standard down and the gap largely closes.
What belongs in the definition of done?
The definition of done is one page, agreed jointly, and applies to every ticket without exception. A workable baseline for a product engineering squad:
- Acceptance criteria met and demonstrated against the ticket, not against the developer's interpretation of it
- Reviewed and approved by an engineer other than the author, with review comments resolved rather than dismissed
- Automated tests written at the appropriate level, and the whole suite green
- No new critical or high issues from static analysis, dependency scanning or secret scanning
- Observability in place: relevant logs, metrics and alerts for new code paths
- Documentation and API contracts updated in the same pull request
- Feature flag or migration plan defined for anything user-visible
- Deployed to staging and verified there before the ticket is closed
The value is less in any single line than in the absence of ambiguity. "Done" stops being a negotiation at the end of every sprint, which is where most of the friction in outsourced delivery actually lives.
Which gates should be automated?
Anything you would otherwise ask a human to check twice should be a gate. Humans are for design judgement; machines are for consistency.
| Gate | Enforced at | Sensible starting threshold | Owner |
|---|---|---|---|
| Formatting and linting | Pre-commit and CI | Zero warnings; formatter is not negotiable | Vendor |
| Type checking | CI | Strict mode, no new suppressions without a comment | Vendor |
| Unit and integration tests | CI, blocking merge | All green; coverage on changed lines does not fall | Vendor |
| Static analysis | CI, blocking merge | No new critical or high findings | Vendor |
| Dependency and licence scanning | CI plus nightly | No known critical vulnerabilities; licence allowlist enforced | Shared |
| Secret scanning | Pre-commit and CI | Zero tolerance, with rotation runbook | Shared |
| Pull request size | CI warning | Flag anything over roughly 400 changed lines | Vendor |
| Migration and rollback check | Release pipeline | Every schema change has a tested rollback path | Shared |
Coverage on changed lines is a better gate than a global coverage percentage: it stops the number sliding without triggering a low-value campaign to test old code that nobody is touching. Pull request size is the most underrated gate on the list — small pull requests get genuinely reviewed, large ones get approved.
Which metrics actually predict quality?
Resist the temptation to measure output. Lines of code, story points and commit counts reward the wrong behaviour and are trivially gamed. The DORA research programme identified four delivery metrics that correlate with software delivery performance, and they remain the most useful starting set for an outsourced squad:
| Metric | What it tells you | What a problem looks like |
|---|---|---|
| Deployment frequency | How small and safe the batches are | Everything ships at the end of the sprint in one release |
| Lead time for changes | How long work waits rather than how fast people type | Days sitting in review or waiting for an environment |
| Change failure rate | How often a release causes a degradation | A rising rate after a team scales up too quickly |
| Time to restore service | Whether the team can operate what it builds | Recovery depends on one person in one time zone |
Add three practical companions: review latency (median time from pull request opened to first substantive review, where a spike often signals overload before quality drops), escaped defects (bugs found in production per release, the cleanest single quality signal), and rework rate (tickets reopened after being marked done, which measures whether the definition of done is real).
Seven metrics is enough. Review them monthly with the vendor, look at trend rather than absolute value, and never tie individual engineer bonuses to them — that is the fastest way to make them meaningless.
What should the service levels say?
Delivery service levels belong in the statement of work with defined severities, defined clocks and a defined escalation path. A structure that works for most product engagements:
| Severity | Definition | Response | Resolution or workaround target |
|---|---|---|---|
| S1 Critical | Production down or data at risk | 1 hour, 24/7 | 4 hours |
| S2 High | Major feature unusable, no workaround | 4 business hours | 2 business days |
| S3 Medium | Feature impaired, workaround exists | 1 business day | Next sprint |
| S4 Low | Cosmetic or minor | 3 business days | Backlog, prioritised normally |
Two clauses matter more than the numbers. First, a warranty window: defects traceable to delivered work and reported within an agreed period, commonly 30 to 90 days, are fixed at the vendor's cost. That single term aligns incentives better than any penalty regime. Second, an on-call arrangement that is explicit about who carries the pager outside European hours — an area where an offshore team's time zone is an asset rather than a cost, provided it is planned deliberately as part of the wider time-zone operating model.
How do you catch quality drift early?
Quality rarely collapses; it erodes, and the leading indicators show up weeks before the escaped-defect count moves. Watch for review latency climbing, pull requests getting larger, test suites gaining skipped or flaky cases, static-analysis suppressions accumulating, and the same engineer approving everything within minutes. Any one of these is normal in a busy week. Two of them persisting for a month is a signal to intervene.
The cheapest early-warning system is a monthly sample review: your senior engineer reads five randomly chosen merged pull requests end to end and forms a view on design quality, test quality and review depth. It takes two hours, it cannot be gamed, and it catches the things dashboards miss — such as tests that assert nothing, or a pattern being copied twelve times instead of extracted once.
What do you do when quality slips?
Escalate along the technical path before the commercial one. Take the specific evidence to the vendor's tech lead, agree a written remediation plan with dates, and re-measure in thirty days. Most slips have mundane causes — a strong engineer rotated off, a review bottleneck, an unclear requirement producing rework — and they are fixable in weeks when raised specifically rather than as a general complaint about quality.
If the trend does not turn after a documented remediation cycle, you are looking at a structural problem: the wrong seniority mix, an unstable team, or a vendor whose bench economics are being managed at your expense. That is the point at which contractual mechanisms and, if necessary, a planned vendor transition become the right response — and the reason the transition-out clause should have been negotiated at the beginning.
Prevention is far cheaper. Vet the actual engineers before they join, using the approach in our guide to vetting senior software engineers, agree the definition of done in week one, and put the gates in the pipeline before the first feature ticket. If you want a squad that arrives with those practices as standard rather than as something you have to impose, ILMTEC builds senior dedicated engineering teams for European companies, with named engineers, a vendor-side tech lead and the quality gates configured from day one.
