The announcement took eleven minutes. Somewhere in it was a sentence about a “global delivery model,” then a slide with fourteen names on it, then a line saying your role was being “elevated” to managing the new team. Your five people are on notice. You are not. That is somehow worse.

Nobody asked you. You will manage anyway, starting Monday, with no handover plan, no documentation worth the name, and a Teams channel that starts pinging at 11pm.

So, the answer first. Managing an offshore team in India succeeds or fails almost entirely on one variable: whether the knowledge that lived in your old team’s heads gets written down before those people walk out, and it almost never does. Time zones, accents, cultural difference and meeting cadence are all real, all second order, all solvable. Undocumented process knowledge is what sinks these transitions, and your window to recover it is weeks, not months.

The part nobody says out loud

You will feel worse at your job for about three months, because you will be worse at it. Not the new job. The old one. The thing you were excellent at, closing fast, catching the weird one before it hit the ledger, knowing without checking that the Henderson account always posts late, stops being what you do.

That is grief, and it is also a status problem. Your headcount went from five to zero to fourteen people you do not employ, cannot promote and did not choose. “Manager of fourteen” reads as a demotion in the room, and people in your building will treat it as one for a while.

Two honest things. It stops hurting around month four, when a process runs cleanly without you touching it and you get a Tuesday afternoon back. And the person who owns the process design, the controls and the authority to say “that number is wrong” is structurally more secure than the person producing the number. Your employer just built a model that needs exactly one onshore person to hold it together. Be unambiguously that person, and do not spend ninety days sulking, because those are the only ninety days in which the knowledge is recoverable.

Week one: ask, do not build

Do not draw a process map in week one. Do not run a kickoff with a mission statement. Find out how bad the hole is. Ask your vendor or offshore lead these in writing, and keep the answers.

• Who is actually on my team, by name, and what has each person personally done that resembles this work? Not the CV. Last quarter. Is anyone here also staffed on another account, and at what percentage?
• Who writes their performance review and decides their next assignment? You are almost certainly neither.
• What shift do they work, stated in IST, and who can change it?
• What is the notice period, the replacement commitment, and is there a named backup shadowing each primary?
• What is this team’s holiday calendar for the next twelve months? It varies by state and employer in India.
• What documentation were they handed? Send the files, not a summary.
• What access do they lack, and what work is blocked right now waiting on it?
• Is anyone measuring error and rework rates today? Show me the raw log.

And internally, the time-sensitive one: which of my outgoing people are still on payroll, until when, and can I book their calendars today? An hour from someone who is leaving is worth roughly ten hours of archaeology later.

Your old team is being asked to train their replacements, which is an awful thing to ask of anyone. Some will do it generously, some minimally, and you cannot blame either. Push for retention payments tied to a completed documentation deliverable rather than to a last day. It is the one lever that reliably works.

The knowledge already walked out. Getting it back

Gabriel Szulanski studied 122 best-practice transfers inside eight large firms (271 questionnaires, Strategic Management Journal, 1996), asking why knowledge fails to move between units that genuinely want it to. Practitioners blamed motivation: turf, jealousy, not-invented-here. The data disagreed. The dominant barriers were the recipient’s lack of absorptive capacity, causal ambiguity, and a difficult relationship between source and recipient. Motivation barely registered.

Causal ambiguity is your whole problem in two words. Nobody can fully articulate why the thing works when it works. Your old team did the job correctly for years without being able to state the rule they applied, because it was not a rule. It was two hundred accumulated exceptions and a feel for which ones mattered.

Knowledge transfer sessions that actually transfer

Three rules. The third is the one people skip.

Record everything, stored where the offshore team can search it without asking permission. You will re-staff this team at least once, and the recordings outlast attrition on both sides.

Make it task-based, not tour-based. A session called “overview of the AP process” is worthless. “Post these nine invoices, including the two that are wrong” produces real knowledge, because the exceptions surface.

Reverse-shadow instead of demoing. The default is the outgoing expert sharing their screen while everyone watches, which produces confident nodding and no capability. Flip it after the first pass: the offshore person drives, the expert watches in silence and speaks only when something is about to go wrong. Every intervention marks a documentation gap, precisely located. Have someone writing those moments down.

A process document worth writing

Most process docs are a screenshot tour anyone could have produced from the software manual. This outline holds up. One document per process:

• Name, onshore owner, offshore owner, last reviewed date. An undated doc gets ignored within a year.
• Trigger, timing and inputs. What starts it, on what day, what deadline it feeds, which files from which system and which human, and what to do when they are late.
• Steps. Numbered, each naming the system and screen.
• Judgement points. Every place a person chooses rather than follows. State the rule and the reason behind it. This is the section that matters and the one everybody omits.
• Known exceptions, by name. The entity with the odd year-end. The vendor whose invoices arrive without a PO.
• Output, destination and definition of done, with one fully worked correct example attached.
• When it breaks. First three things to check, then who to ask.

Have the offshore team write the first draft from the recording and you edit it. Write it yourself and you will unconsciously skip everything obvious to you, which is exactly what they need. Their draft also exposes what they misunderstood.

Reviewing the offshore team’s work without becoming the bottleneck

Month one you review everything. Correct, and temporary. The failure mode is still reviewing everything in month fourteen, when the company has two salaries where it had one and you have no evenings.

Tier the review per person and per process, never globally. Someone reliable on bank reconciliations is not automatically reliable on fixed assets, and treating competence as a general trait is how errors get through.

• Tier 1, full review. Every item. Exit criterion is a stated run of clean items, not a date and not a feeling.
• Tier 2, risk-weighted sampling. All items above a materiality or risk threshold set in advance, plus a random sample of the rest. Random genuinely matters: if people can predict what you check, you are measuring the wrong things.
• Tier 3, exception review. Flagged items and outliers only, plus a periodic re-sample confirming the tier is still earned.

Write the re-tightening trigger before you need it: any error that reached a client or the ledger, or two material errors in a month, drops that person and that process back to Tier 1. Applied automatically, it stops being a judgement about someone and becomes a rule, which is far easier to live with.

Error rates, not vibes

“Quality is improving” is not something you can take into a vendor meeting. Errors per hundred items is. Split it material versus cosmetic and track first-pass yield, the share of items you accept with no rework. The six-month trend is the argument, not the month-one number.

The high-value move is tagging every logged error with a cause: documentation missing; documentation wrong or ambiguous; documented correctly but not followed; judgement call went the wrong way; upstream input was bad. If most errors sit in the first two categories you do not have a capability problem, you have a documentation problem, and no amount of feedback to individuals will fix it. Managers who skip this step spend a year concluding the offshore team is weak, when the honest finding is that nobody ever wrote the process down.

The overlap window, and the honest arithmetic

India Standard Time is UTC+5:30 and India does not observe daylight saving at all. The United States does, 2am on the second Sunday of March to 2am on the first Sunday of November under the Energy Policy Act of 2005. The consequence people miss: the gap is not fixed. It is 9.5 hours from US Eastern in summer, 10.5 in winter, and stretches to 13.5 from US Pacific in winter. On 1 November 2026 every recurring meeting you set up shifts by an hour for one side or the other, and it will again every March and November.

Now the uncomfortable maths. A normal Indian day of 10:00 to 19:00 IST lands at 00:30 to 09:30 US Eastern in summer. If you work nine to five, your natural overlap is about thirty minutes, and in winter it is zero. Pacific is worse. No tool fixes this. Somebody’s day moves, and it is worth being explicit about whose.

• They shift late, you shift slightly early. India works 12:30 to 21:30 IST, you start at 08:00 Eastern. About three and a half hours of real overlap in summer with nobody on a night shift. Sane default for East Coast teams.
• A fixed overlap block rather than a whole shifted day. Normal Indian hours plus a protected two-hour evening window four days a week. Kinder on morale, but it evaporates unless you defend it.
• Rotate the pain when it cannot be removed. West Coast teams rarely avoid unsocial hours entirely. Rotating that quarterly, and paying for it, is the difference between a team that stays and one you retrain twice a year.

Do not spend the window on status, which goes in writing before the call. Use live time for what is expensive asynchronously: judgement calls, ambiguity, disagreement, anything where you need to see a face. A rhythm that works: twenty to thirty minutes daily on blockers and escalations only; sixty minutes weekly walking three actual errors and their cause categories; monthly on documentation debt and review tiers; quarterly on their careers, even though you do not write their appraisals. Especially because you do not.

Why written-first is not a preference

Herbsleb and Mockus analysed software change requests across two departments of a large firm and found work spanning multiple sites took roughly 2.5 times as long as comparable same-site work: 12.7 days against about 5 in one department, 18 against about 7 in the other, across 2,227 and 4,974 requests. Developers reported delays waiting on a remote site averaging 2.4 days against 0.9 locally. The strongest predictor of duration was not distance but how many people had to be involved.

That is the case for writing things down. A question only one human in one time zone can answer costs you a day. Answered in a searchable document, it costs you once. So when you answer something verbally, it goes into the process document that day, or you will answer it again in six weeks to a different person.

Feedback and escalation across a hierarchy gap

You will notice quickly that nobody tells you something cannot be done. The deadline is accepted. The estimate is agreed. Then the work is late.

Part of that is structural: your reports are graded by managers you will never meet, and telling the client’s manager his plan is unrealistic is not obviously career-enhancing. Part is cultural. The GLOBE research programme surveyed over 17,000 middle managers in roughly 950 organisations across 62 societies, measuring power distance both as practised and as people say it should be, and consistently finds a gap between the two. Treat that as averages, never a prediction about the individual on your call and never an excuse. Plenty of your team will push back hard once they believe it is safe.

What makes it safe is small and early. Thank the first person who tells you something is wrong, publicly and by name, within a day. Never correct anyone in a group call if a direct message will do. Ask questions that cannot be answered with “yes”: “walk me through how you’d do it” rather than “does that work for you?” And attach feedback to the document, not the person. “The doc is wrong about step 6 and I’m fixing it” gets you the truth much faster than “you got step 6 wrong.”

The escalation rule of thumb: two real attempts, then ask. If the next step would be a guess that affects a number leaving the building, stop and escalate. Escalating is never the wrong call. Guessing is. Publish that sentence, repeat it, then honour your half by answering every escalation inside the overlap window, every day. One ignored escalation kills the rule for a quarter.

Watch the volume too. If escalations from someone fall to zero, that is rarely mastery. Zero escalations alongside a rising error rate is the clearest early warning you get.

When it is genuinely not working

Give it four full cycles before judging, whatever the natural unit is in your function. Anything shorter measures the transition, not the team.

Real failure signals, as opposed to normal transition pain: the same error cause recurring after you fixed the documentation; zero escalations with a flat or rising error rate; and above all, training a third cohort inside twelve months. That last one is not a management problem you can solve. The vendor is rotating people off your account, and the fix is contractual: named people with a minimum tenure, funded backup shadows, consequences attached. Take the error data into that conversation. Take feelings and you get a slide deck back. If nothing shifts, the honest options are narrowing scope, bringing one high-judgement process back onshore, or changing provider. None is an admission that you failed.

Then your own position. What you are building reads well on a CV, provided you write it down as you go: transitioned N processes offshore, built the documentation and QA framework from nothing, moved review from 100% to risk-based sampling, cut error rate from X to Y over Z months. That is a portfolio rather than a job description, and it is scarce. If at eighteen months you are still reviewing everything, the vendor still swaps people quarterly and your title has not moved, your employer has told you what the next five years look like. Read it as data, not a verdict on you.

Questions people ask next

How long before the team is genuinely productive?

For transactional, well-documented work, expect meaningful independent output within one to two full cycles and something near steady state around six months. Judgement-heavy work takes longer, and some never fully transfers, which is a scoping decision rather than a failure. The biggest variable is documentation quality at handover, not the team’s ability.

Should I read up on Indian culture before Monday?

Lightly, and with suspicion of anything shaped like a listicle. The high-value preparation is practical: know the holiday calendar, know the shift in IST, learn to pronounce fourteen names correctly, and find out who writes their appraisal. India is not one culture, and treating people as individuals beats every cultural cheat sheet.

Can I give someone on the team a raise or a promotion?

Not directly. They are the vendor’s employees. What you can do still carries weight: written praise sent to their manager, expanded scope, naming them process owner, and telling their delivery lead explicitly that you want this person kept on your account. Cheapest retention lever you have, and almost nobody uses it.

AB7 Solutions builds and runs offshore delivery teams, so the person we most often end up talking to is the onshore manager who inherited one. If that is you, the useful conversation is not about rates. It is which processes were documented well enough to move, how to rebuild the ones that were not, how to design a review layer that can actually taper, and where the overlap window has to sit for your time zone. Call +1 321 341 7733, or email ab@ab7solutions.com or director@ab7solutions.com. More at www.ab7solutions.com.

Sources: G. Szulanski, “Exploring internal stickiness: impediments to the transfer of best practice within the firm”, Strategic Management Journal 17(S2), 1996 (271 questionnaires, 122 transfers, 8 firms); 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; 92 survey respondents); R. J. House et al., Culture, Leadership, and Organizations: The GLOBE Study of 62 Societies, 2004 (17,000+ middle managers, ~950 organisations); timeanddate.com, India Standard Time; NIST, Daylight Saving Time (DST), and the Energy Policy Act of 2005.