Sprint 14 closed on Friday. Six of eleven tickets moved to done, two came straight back on Monday, and the status deck has said amber for fourteen weeks with a dotted recovery line stapled to the burndown. You have been in the job five weeks. You inherited the team, the contract, and a roadmap commitment your VP made before you arrived.

You do not need an essay on why offshore development is hard. You need to know what to do on Monday with the offshore dev team you have.

The play is this: spend one week working out which of four problems you actually have, because all four look identical from the outside and each has a different fix, then run a six-week intervention and make a keep-or-exit call at the end of it. The four causes are unclear requirements, missing capability, a broken feedback loop, and a contract that pays for the behaviour you are complaining about. Most inherited teams have two at once. Very few have all four.

The expensive mistake is guessing. Spend six weeks rewriting tickets when the real problem was that your two strong engineers got rotated onto a bigger account in March, and you have burned the only goodwill you were going to get.

Week 0: four reasons an offshore dev team underperforms, and how to tell them apart

All four produce the same symptom: work arrives late, wrong, or both, while the status call says on track. You cannot tell them apart by watching. You can tell them apart by running a test.

Unclear requirements. Pull one ticket that came back clean and one that was a disaster, and read the original descriptions side by side. If the clean one carried a worked example and the disaster was two sentences of prose, you have your answer already. The sharper test: take your worst-performing developer, write one ticket yourself to a genuinely high standard, assign it, and look at what comes back. If the same person does good work on a well-specified ticket, it is not a capability problem. That sentence will save you a month.

Missing capability. Ask the engineer to walk you through code they wrote three weeks ago. Not a status update. Why this approach, what happens if the upstream call times out, what they rejected. Ten minutes is enough. A capable engineer given a bad ticket tells you exactly what was ambiguous and what they assumed. Someone out of their depth describes what the code does rather than why. Have one of your engineers on the call if you are not technical.

Broken feedback loop. Measure the gap between a developer starting work and the first moment anyone on your side saw the result. If the median is over five working days, stop diagnosing capability: nobody has had a chance to correct anything. A team that shows you work once a fortnight looks incompetent whether or not it is. This is the most commonly misdiagnosed of the four.

Wrong incentives. Read the statement of work, then ask the uncomfortable question: does the behaviour that annoys you make the vendor money? Under a fixed bid, refusing to refactor, raising a change request for anything not written down, and declaring a ticket done at the cheapest defensible reading are all rational. That is not a performance problem. It is a commercial arrangement working correctly in a direction you dislike.

Measure the work, not the status report

Whatever the RAG status says, it is a summary written by someone whose bonus depends on it. Instrument the flow instead. Four numbers, pullable from Jira and GitHub in an afternoon:

• Cycle time, first commit to merged. Not “in progress” to “done”, which is self-reported. Commit timestamps do not lie.
• Reopen rate. What share of tickets marked done get reopened or spawn a bug within 14 days? Above 20% and your definition of done is fiction.
• Approval without comment. What proportion of pull requests merge with no substantive review comment? If it is most of them, review is ceremonial.
• Clarifying questions per ticket. Count them. A team asking zero questions did not understand the brief. It has learned that questions are punished, or that guessing is cheaper. Zero is a red flag, not a green one.

If you need an external reference for the exec conversation, DORA publishes five key metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate, the last being the share of unplanned deployments caused by a production incident. Those measure deployment rather than tickets, so treat commit-to-merge time as a proxy. The 2025 report draws on nearly 5,000 technology professionals and over 100 hours of interviews.

Weeks 1 and 2: fix the requirements first, whatever the diagnosis said

Do this even if requirements were not your primary cause. It is cheap, it is entirely within your control, and until the ambiguity is gone you cannot attribute any failure to anybody.

Curtis, Krasner and Iscoe studied 17 large software projects for Communications of the ACM in 1988, across 97 structured interviews. Three problems dominated: thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication breakdowns. Two of the three sit upstream of the developer.

Acceptance criteria written before assignment, not negotiated after delivery. A ticket entering a sprint without them is your failure, not the team’s. Enforce it on yourself first, publicly, so nobody reads it as a new stick.

Examples over prose. A sample request and response beats a paragraph about the API. An annotated screenshot beats a bug description. Five input rows and their exact expected output beat any amount of explanation about rounding rules.

A definition of done short enough to recite. Five items maximum: tests at the level the ticket specifies, CI green, reviewed by a named engineer on your side, deployed to staging by the author, one paragraph in the PR saying what was assumed. Unwritten, “done” quietly becomes “demonstrated on a screen share”, because nobody is being paid for the rest.

The 24-hour show-me. This changes more outcomes than the other three combined. When you assign anything non-trivial, ask the developer to show you what they think you asked for within 24 hours. Not finished. A wireframe, a function signature, a failing test, three bullets in Slack. You are buying a cheap look at their interpretation, and you find the misunderstanding on day one instead of day nine. Damian and Zowghi, studying requirements engineering across sites in a multi-site organisation for Requirements Engineering in 2003, found the recurring failure was not incompetence but the absence of a common understanding of requirements. The show-me surfaces that before it has cost anything.

Weeks 2 to 4: shrink the loop

Most struggling offshore teams are not slow. They are slow to be corrected, which produces the same invoice.

Cut batch size hard. Nothing larger than three days of work. DORA treats working in small batches as a capability that predicts delivery and organisational performance, and recommends units completable in hours to a couple of days, precisely because it shortens time to feedback. A two-week ticket that goes wrong on day two costs you eight days of wrong work. A two-day ticket costs one.

They demo to you, not to the vendor’s delivery manager. When the engineer demos to their own manager who then summarises to you, you get a filtered report and the engineer gets no signal at all. Ask for whoever wrote the code to run the demo, on your call, weekly. You will learn more in one session than in three months of status decks.

A daily 15 minutes beats a weekly hour. Same total time, completely different effect, because the unit that matters is not minutes of contact but the number of days a question can sit unanswered. Herbsleb and Mockus, studying 2,227 and 4,974 modification requests across two departments of a large telecoms software organisation in 2003, found distributed work took roughly two and a half times as long as comparable same-site work, and put it down to more people and more delay rather than to culture. So cut the delay per question. Fifteen minutes a day, same time, engineers present rather than only managers.

One of your engineers reviews every PR. Vendor-internal review is structurally compromised: reviewer and author report to the same delivery manager, who is measured on the milestone date, so approval is the cheapest move available. Put a reviewer outside that P&L in the chain and the bar moves within two sprints.

The capability fix, and asking for someone to be replaced

If, after two clean sprints with proper acceptance criteria and a daily overlap, a specific person is still producing work you would not accept from a junior hire, you have a real capability problem.

Pair them with someone first. Two hours twice a week, screen-shared, on real tickets. Much of what looks like incompetence is an engineer who has never seen how your codebase expects things to be done and has nobody to ask. Then name a senior on your side as technical owner: not a reviewer of last resort, but someone who sets architectural direction, answers questions in the overlap window and can say no. A team with no senior counterpart is making judgement calls with no basis for making them, which is Curtis’s thin spread of domain knowledge in one sentence.

Then the honest conversation. Ask the delivery manager whether the assigned people have done this kind of work before, in these words: “I want to check we have the right profile here, not the right headcount. Has anyone on this team built a payment integration at this volume?” Vendors answer that question. They do not answer “is your team any good?”

When you do need someone replaced, technique matters more than timing. Never name an individual as the problem to their manager. It lands in an appraisal you never see, it makes you the client who gets people fired, and every remaining engineer stops telling you anything true. Ask for a profile instead:

“For the next phase we need someone with production Kafka experience and a strong testing background. Can you look at the roster and tell me who fits? Happy to interview two or three.”

Same outcome, nobody’s rating destroyed. Do it at a natural boundary if one exists, and only after you have removed the other explanations. Swap a person while your requirements are still bad and you get identical output from a new face, having spent your one free change.

Weeks 4 and 5: incentives, the contract, and the account manager

Mid-contract you have less power than you think and more than you use. Rate card, contract value, pricing model and termination terms need a commercial negotiation. Definition of done, ceremony schedule, who demos, ticket format, review chain and the reporting you receive usually do not, because they cost the vendor nothing and improve their own delivery numbers. Nobody needs a signature to let an engineer join your standup.

The one structural item worth fighting for mid-term is named staff: an annex listing individuals with allocation percentages, a minimum assignment term, 30 days’ written notice before any rotation, paid overlap for handover, and your right to interview replacements. A vendor selling a dedicated team signs it without drama. A vendor selling fungible capacity resists, and the resistance answers a question you were already asking. If they will not sign mid-term, queue it for renewal and say so in writing now.

Most PMs treat the account manager as a wall to be gone around. Use them as an instrument. They own revenue on your account, they are measured on renewal, and they have internal authority the delivery manager lacks. Bring numbers, not feelings. A written note saying reopen rate is 31% over three sprints against a target of 10%, with dates and ticket IDs attached, forces a conversation inside their organisation. An email saying you are unhappy with quality produces a deck. Copy your procurement lead, ask for a specific remedy with a date, and let them work out how to deliver it.

When the real problem is on your side

Run this in week two, honestly, because if you skip it the vendor runs it for you in a renewal meeting.

• Your response latency. Take every question the team asked last month and measure time to a decisive answer. Not an acknowledgement, a decision. Median over 24 hours and you are the bottleneck, whatever else is true.
• Ticket churn after assignment. How many tickets had acceptance criteria changed after work started? That is Curtis’s fluctuating and conflicting requirements, and it is one of the few items on his list a single PM can actually fix.
• Blocked-on-you time. Days tickets spent waiting on a decision, an environment, a credential, or a stakeholder who would not take a meeting. Put that number in your own status report before anyone asks for it.

If a design decision has been open three weeks because two of your directors disagree, the team is not underperforming. It is idling, correctly, then building the wrong thing when a deadline forces somebody to guess. Fix that before you touch the vendor relationship, visibly.

Week 6: the go/no-go, and the exit plan if it is no

Six weeks is long enough to see a trend and short enough that you have not burned a quarter. Compare against your week 0 baseline, not against a fantasy.

Recoverable looks like: cycle time down meaningfully, reopen rate falling sprint on sprint, clarifying questions up from near zero to several per ticket, at least one engineer pushing back on a ticket you wrote, and one or two people you can now name as good. That last signal is underrated. When you can say “give this to Priya, she knows billing”, you have a team rather than a supplier.

Not recoverable looks like: no movement on reopen rate after the requirements fix, still zero questions in week six, a third staffing change since you arrived, the delivery manager still answering technical questions the engineers should answer, and every improvement returning as a change request with a price on it. Three of those and you stop investing.

The exit is an operational task, not an emotional one. Run it quietly, in this order.

• Secure access before you say anything. Repository admin held by your organisation, not the vendor. Cloud accounts, DNS, app store listings, CI, monitoring, API keys, and the email addresses those accounts recover to. Check who owns them, not who uses them. This is where exits go wrong.
• Record what was never written down. Knowledge-transfer sessions per module, recorded with consent, the developer walking through the code live rather than writing a document. Ninety recorded minutes with the person who built it beats a 40-page handover pack. Capture decisions, not code: why that retry interval, which customer the special case exists for.
• Re-read the termination clause. Notice period, IP assignment, and whether transition support is billable and at what rate. Most master services agreements carry a transition assistance clause that nobody reads until they need it.
• Stage the wind-down. Overlap the incoming team by at least a month. A clean break on a Friday is how you lose a quarter.

Say nothing about exiting until access and knowledge transfer are secured. Not because the vendor will behave badly, but because motivation drops the moment people know, and the last month is when you need them most.

The six weeks on one page

• Week 0: baseline numbers, read the SOW, run the two-ticket comparison and the code walkthrough. Write down which cause you think you have, and the evidence.
• Week 1: acceptance criteria before assignment, every ticket. Publish the definition of done. Start the daily 15 minutes. Tell the team the first fortnight is on you.
• Week 2: cap batch size at three days. Introduce the 24-hour show-me. Run the on-your-side audit and publish your own numbers.
• Week 3: engineers demo directly to you. Your senior reviews every PR. Start pairing where the walkthrough flagged a gap.
• Week 4: first real read on the metrics. Profile conversation if someone is still failing on good tickets.
• Week 5: named-staff annex requested in writing. Structured note to the account manager with numbers and a remedy date.
• Week 6: go/no-go against the baseline. If go, set two targets and move to monthly review. If no-go, work the access and knowledge-transfer checklist before you tell anyone.

Questions product managers ask next

Should I tell the team I am running a turnaround? Tell them what is changing and why, not that they are on probation. “I am going to write much better tickets, we will talk every day, and I want to see your interpretation within 24 hours so I can catch my own mistakes early” is true, is about your behaviour, and gets cooperation. A performance-improvement framing stops the flow of bad news, which is the thing you need most.

The vendor says my requirements are the problem. Are they deflecting? Possibly, and they may also be right. Test it instead of arguing. Write three tickets to a standard nobody could criticise and see what comes back. If the output is good, they were right and you have found your fix. If it is unchanged, you have removed their best defence.

What if my exec just wants the vendor replaced? Do the six weeks anyway and keep the artefacts. A switch costs months of ramp and knowledge loss, and if the cause was unclear requirements or absent product decisions it follows you to the next vendor unchanged. Your baseline numbers are also the specification you hand to whoever comes after.

AB7 Solutions works the other side of this: named, interviewed engineers who sit in your repo, your standup and your definition of done on a staff-augmentation basis rather than a fixed-bid project, with rotation notice and handover overlap written into the agreement. If you want a second opinion mid-turnaround on which of the four causes you are looking at, or a senior reviewer on your side of the chain while you decide, call +1 321 341 7733 or email ab@ab7solutions.com or director@ab7solutions.com. More at www.ab7solutions.com. If your six weeks says the team is recoverable, keep it. That is cheaper than anything we would sell you.

Sources: DORA, software delivery metrics (the five keys) and “Working in small batches”; Google Cloud, “Announcing the 2025 DORA Report” (nearly 5,000 respondents, 100+ hours of interviews); B. Curtis, H. Krasner and N. Iscoe, “A Field Study of the Software Design Process for Large Systems”, Communications of the ACM 31(11), 1988 (17 projects, 97 structured interviews); D. E. Damian and D. Zowghi, “RE challenges in multi-site software development organisations”, Requirements Engineering 8(3), 2003; J. D. Herbsleb and A. Mockus, “An Empirical Study of Speed and Communication in Globally Distributed Software Development”, IEEE Transactions on Software Engineering 29, 2003 (2,227 and 4,974 modification requests).