Plan Your Delivery Pod Around Shared Working Hours

In a study of 675 people across 108 projects, published in 2009, Cummings, Espinosa and Pickering found that synchronous web conferencing reduced coordination delay between people in different cities whose hours overlapped.

Email helped pairs with overlap too, but didn't reduce delay for pairs with no shared hours. The authors, studying a multinational semiconductor firm, concluded that time boundaries were harder to bridge with communication technology than distance.

For a nearshore or offshore pod, that gap can turn a short question into a day of waiting. A developer who reaches an ambiguous requirement after the client's working day ends has to leave that part open until someone can answer.

Count the hours people can answer each other

Who's online during the overlap, and what can they decide?

A lead working in the client's time zone can resolve questions while the client is available. If every answer still requires approval from someone asleep, the lead passes the question on and the task keeps waiting. Count the hours shared with that decision-maker too.

And give the lead explicit authority for the decisions they can make. Put that authority in the pod's working agreement. That lets the team bring a question to someone who can settle it during the shared window.

Put the uncertain work into the shared window

Design discussions belong in the overlap because an answer can expose another question. The same goes for an unclear requirement. With the people involved still online, the team can work through the follow-up while the task is in front of them.

Schedule reviews early enough in the window for that exchange. Leave time for follow-up. Written context sent ahead helps the client arrive knowing which behavior the team proposes and which business rule is unresolved.

Well-specified work fits outside the shared hours. Once the expected behavior is clear, a developer can build it and check the result independently. For work still waiting on a rule, the handoff can point to another task that's ready.

Incident handoffs also belong in the shared window. The incoming shift has to understand what's still open before the outgoing shift leaves, with time to ask about the work it's taking over.

Write the handoff around the unanswered question

A handoff contains:

• What has been done and where the current work stands.
• The exact question holding up the next part.
• The requirement and proposed interpretation, with enough context to decide.
• Who can answer, and which work can continue in the meantime.

For example, a handoff might propose that active_customer includes a customer with an unshipped order. The client can accept that reading or explain why the rule excludes those orders, giving the returning developer an answer they can apply.

Put the agreed interpretation on the task after the conversation. Any limit on it belongs there too, so a decision about the current work doesn't quietly become a rule for unrelated features.

Watch how long the questions wait

Deloitte's 2024 Global Outsourcing Survey reported increased adoption of outcome-based delivery models. On an outcome-based contract, a day lost waiting for an answer comes out of the vendor's margin: the team incurs the time while payment is tied to the result. Tracking that wait shows where the engagement is absorbing avoidable delay.

Log when a question was raised and when an answer reached the developer. Repeated waits across shifts can show that the shared window misses someone with decision authority. They can also show that the handoff leaves out context, forcing another exchange the following day.