Managing an Offshore Engineering Team You Cannot Be Online With

Most offshore engineering problems are diagnosed as quality problems and are actually latency problems. The team is capable, the work is understood, and then someone hits an ambiguity at 10:00 their time and the only person who can resolve it is twelve hours away. What happens in the next four hours determines whether the sprint holds.

"Requirements questions pile up overnight and the sprint slips."

Where offshore engagements actually fail

Ask a team why an offshore engagement is underperforming and you will hear about seniority, communication, or commitment. Ask the offshore engineers and you hear something much more specific: they are blocked on answers, and they have learned that waiting for an answer loses a day, so they make a reasonable assumption and continue.

Those assumptions are the source of almost everything later attributed to quality. Work built on a wrong interpretation looks like bad work in review, and the reviewer, who was asleep when the question was asked, experiences it as carelessness. The engineer experiences it as having been left without an answer. Both are right, and the process is what is wrong.

The round trip, priced

Put a number on it before you design anything. For one sprint, ask the offshore team to note every question they had to park for lack of an answer, along with what they did instead.

A useful rule of thumb on a ten-person team: one parked question per person per day, each costing between one and three hours of either waiting or rework, is roughly a full engineer-day lost per day. Over a two-week sprint that is ten days of capacity. Nobody plans for that, and no board shows it, because the time is spread across everybody as small interruptions and small reworks rather than concentrating anywhere visible.

The number is also the argument. Offshore arrangements are usually justified on cost, so a loss expressed in engineer-days per sprint is the one form of evidence that reliably moves the conversation.

Specify for the gap, not for the room

A specification good enough for a co-located team is not good enough across a twelve-hour gap, because the co-located version relies on a follow-up conversation that will never happen. Three practical additions.

• State the non-goals. Half of overnight questions are "does this include X". Say what it does not include.
• Say what to do when uncertain. A default instruction beats an ambiguity. "If the field is missing, skip the record and log it" resolves a whole category of questions before it is asked.
• Name the decider per ticket. Not the team, a person, and where possible a person in the offshore zone.

Then read your own spec at the point the other team will read it, which is the start of their day with nobody available. The gaps become obvious immediately.

Move the authority, not the hours

The standard response to this problem is an overlap call, usually early morning for one side. It helps and it does not scale, because it batches answers into a window rather than making them available when the question arises.

The structural fix is to move decision authority into the zone doing the work. For each recurring class of question, write down who decides and within what bounds. "Library choices within the approved list: the offshore lead decides. New dependencies: the onshore architect decides." That converts a category of overnight questions into local decisions, which is the only genuine way to remove the round trip. The mechanics are in the DRI model in distributed teams, and the consequences of leaving authority undocumented are in why decisions keep getting revisited.

The questions that arrive while you sleep

Specification and authority remove most of the round trips. They do not remove all of them, because some questions are genuinely about context: what was decided last month, why the previous approach was abandoned, where a colleague left something. Those answers exist. They are in threads, tickets, and a colleague's head, none of which are reachable at 10:00 in the offshore zone.

This is what StandIn addresses. Each person spends ninety seconds at the end of their day confirming a brief that is mostly drafted from the work they already did. While they are off, their StandIn answers questions from that brief in their words, with a source under every answer, and it never guesses. When the answer is not there, it says so and names the person to ask, which means the offshore engineer learns immediately that this one really does need to wait, instead of discovering it four hours later.

The effect on the sprint is direct: the questions asked overnight get answered overnight, from what the team wrote down, and the engineer keeps working. See working across time zones.

Common Questions

Should we require overlap hours from an offshore team?

A small, fixed, mutually inconvenient window for decisions is reasonable. Requiring several hours of overlap every day is a shift pattern, and it tends to drive out exactly the senior people whose judgement would have reduced the questions in the first place.

How do we tell a latency problem from a capability problem?

Look at what happens after an answer arrives. If the work is good once the question is resolved, you have a latency problem. If the work is still wrong after a clear answer, you have a capability or specification problem. Most teams assume the second without checking the first.

Is a daily handover call enough?

It helps at the edges and it does not solve the middle of the day. A handover call moves information at one fixed moment. Questions arrive throughout the offshore working day, and the ones that arrive an hour after the call cost just as much as they did before.

What should the offshore team do when they are blocked and nobody is awake?

Have a written rule, and make it explicit: check the record, apply the stated default if there is one, and if neither resolves it, park the item, note the exact question, and move to the next thing. What you want to avoid is silent interpretation, because that cost lands in review where it is most expensive.