Working with an Indian development team from the US: a practical guide

Most offshore engagements that go wrong do not fail on engineering skill. They fail on the gap between two working days. A question asked at 4 pm in Boston is read at 1:30 am in Ahmedabad, answered the next morning, and seen in Boston the day after. One unclear ticket costs a full day instead of five minutes.

This guide is for a US engineering leader who works with a team in India, or is about to. Where we describe how Tankar works, the claim comes from our published process.

The time-zone maths

India Standard Time is UTC+5:30 all year. India does not change its clocks. The US does, on the second Sunday in March and the first Sunday in November, so the gap to India moves by an hour twice a year.

A typical Indian office day runs from about 9:30 am to 6:30 pm IST. On the US East Coast in summer, that is midnight to 9:00 am. With no change on either side, the overlap is zero. Every overlap you get is an overlap that someone has chosen to create.

The window most teams use is the Indian evening, from 6:30 pm to 9:30 pm IST. This is what that window looks like from the US:

Eastern time

From the East Coast, an Indian team that starts later in the day gives you a real morning overlap. A 12:30 pm to 9:30 pm IST shift puts two to three hours of shared time into your morning, depending on the season. Agree which of those hours are protected for calls, and put the November and March shift in the calendar so nobody finds out on the Monday.

Pacific time

From the West Coast, the honest answer is that live overlap is short. At 8:00 am Pacific in summer it is 8:30 pm in India. In winter it is 9:30 pm. You can hold a 30-minute call at the start of your day a few times a week, but you cannot run a team on it. Pacific teams do better with a handover model: the Indian day ends with a written pass, your day ends with a written pass back, and the live call is kept for decisions.

If your company has engineers on both coasts, make an East Coast engineer the overlap anchor rather than asking the Pacific team to start at 6:00 am.

Weeks and holidays

Your Friday afternoon is already Saturday in India, so a question asked late on a Friday is a Monday question. Indian holidays do not match the US calendar, and festival dates such as Diwali move each year. Ask for the holiday calendar in January and put both calendars on the shared board.

What to do live and what to run asynchronously

Overlap hours are the scarcest thing in the engagement. Spend them on work that needs a conversation, and move everything else into writing.

Use the overlap for:

• Decisions that need back-and-forth, such as a data model change or a trade-off in scope
• Sprint planning and backlog refinement
• Unblocking a stuck ticket
• Pairing on a hard bug or a production incident
• The weekly demo

Run these asynchronously:

• Status updates
• Code review, with an agreed turnaround such as a first review within one working day
• Specifications and acceptance criteria, written before a ticket is picked up
• Architecture proposals, as a short written document with a comment period
• Demos nobody could attend, recorded and linked from the ticket

A status meeting in the overlap is the most common waste. Replace it with the written update below and give the time back to decisions.

A communication cadence that works

Three habits close most of the gap: a daily written update, a weekly demo and a shared board.

The daily written update

Each engineer, or the project manager for the whole team, posts a short update at the end of the Indian day, before your morning starts. Keep it to the same four headings every day so it can be read in a minute.

Done today:        merged PR 412, invoice export now paginates
In progress:       PR 418, retry logic for the payments webhook
Blocked:           need a sandbox key for the tax API
Questions for you: should archived customers appear in the export

The last heading does the most work. A question written at 6 pm IST can be answered at 9 am Eastern, so the answer is waiting when the Indian team starts. A question held for a call waits a day.

The weekly demo

Once a week, the team shows working software, merged and running in a shared environment. Record it for anyone who could not attend. Tankar runs a weekly demo and a shared project board on every engagement.

The shared board

One board, in your tool, with the same columns your in-house team uses. Tickets carry acceptance criteria before they move to in progress. The board is the record of what was agreed. A decision made on a call is not a decision until someone writes it on the ticket.

For a dedicated team, Tankar also sends a monthly report of work completed and team changes, and names a project manager with escalation to a director within 24 hours.

Contracts and IP

The contract is where most of the risk is settled, or left open. Four items matter more than the rest.

NDA before discovery

Sign a mutual NDA before you share anything detailed: your architecture, your customers, your pricing or your data. A vendor who wants the details first has told you how they will treat them. Tankar signs the NDA before any detailed discussion.

IP assignment

Read the assignment clause for two things. First, when ownership passes to you: on creation, or on payment. Both are common. Second, whether the chain is complete. The vendor's own employment contracts must assign their engineers' work to the vendor, or the vendor has nothing to assign to you. Ask to see that clause, and ask how pre-existing code and open-source components are licensed.

Code in your repository

The code should live in a repository your company owns from the first commit, not in the vendor's account until handover. If the relationship ends badly, you still have every commit and the CI history. Tankar sets up the repository in your account from week one.

The rest of the contract

A master services agreement with a statement of work per engagement is the usual structure.

Payments and invoicing

Indian vendors serving US clients usually invoice in USD and are paid by international wire. These norms are common, not universal:

• Dedicated teams are usually billed monthly, per person, against an agreed capacity. Fixed-price work is usually billed at milestones.
• Payment terms of 15 or 30 days from invoice are typical.
• Wire fees on both sides should be assigned in the contract, so a short payment does not become a monthly dispute.
• The vendor will usually ask for a purpose description on the wire so its bank can record the payment as an export of services.
• Your finance team will usually ask the vendor for a W-8BEN-E form. Tax treatment depends on your facts, so confirm withholding and reporting with your own adviser.

Data protection

The US has no single federal privacy law. Your obligations come from state laws such as the California Consumer Privacy Act, from sector rules such as HIPAA if you handle health data, and from your own customer contracts. Your vendor has to meet the obligations you already carry.

In practice that means:

• A data processing agreement that says the vendor acts only on your written instructions
• A business associate agreement if the team will touch protected health information
• Access through your identity provider, with individual accounts and no shared logins
• No production personal data in development or test environments; use masked or synthetic data
• Access removed on the day someone leaves the team, and a way for you to verify it
• A named security contact and an agreed time to notify you of an incident

India's Digital Personal Data Protection Act 2023 applies to processing that happens in India. When a vendor processes data inside a system it builds or runs for you, you are the controller and the vendor is the processor, acting under the data processing agreement.

Tankar holds ISO/IEC 27001 certification. What ISO 27001 changes about how we handle your code explains what that means day to day.

How to run a two-week trial

A short paid trial on real work tells you more than any number of sales calls. Two weeks is enough to see the cadence working and short enough to stop cleanly.

Before day one. Pick one bounded piece of real work from your backlog: a feature behind a flag, an integration, or a set of bugs with clear reproduction steps. Write the acceptance criteria. Agree the overlap hours, the daily update format and who on your side answers questions. Grant access to the repository, the board and a non-production environment.

Week one. Watch the first 48 hours. A good team asks questions early, and in writing. Look at the first pull requests for size, tests and how they respond to review comments. Hold the first demo at the end of the week, even if there is little to show.

Week two. The work should move to merged and running. Look for whether problems are raised before they become late, and whether the written updates match what you see on the board.

At the end. Score the trial against the criteria you wrote before it started, not against how the calls felt. Decide to continue, change the team shape, or stop.

Failure modes to watch for

Most troubled engagements show one of these early. Each has a signal you can see in the first month.

A team that says yes to everything. Every estimate is accepted and no ticket is questioned. The signal is an empty "questions for you" section day after day. Ask directly what the team would push back on.

Silence until the deadline. Problems surface on the day something is due. The signal is a board where tickets sit in progress for days without comments. Ask for blockers to be raised the day they appear.

People who keep changing. A rate too low to retain engineers shows up as new names every quarter and lost context each time. Track who is on the team month by month.

No named owner. Questions queue because nobody on the vendor side can decide. Ask who that person is before you sign.

A vague statement of work. Both sides read it their own way until the invoice arrives. If a new engineer could not tell from the document what is in and out of scope, rewrite it.

Demos of work that is not merged. A demo from a local branch is a promise, not progress. Ask for the demo to run in the shared environment.

What to do next

If you want a named team that works in your repository, your board and your hours, read how our dedicated development teams work. If you have a piece of work in mind, get a proposal and we will reply with a written estimate within 48 hours of the scoped call.