Your remote team is not slower. Your questions are

Remote teams are often blamed for moving slowly. It is easy to assume that distance, time zones, or a lack of face to face interaction are the problem. However, the evidence suggests something more specific is happening.

Research into distributed software teams found that work involving multiple locations took around two and a half times longer than comparable work completed at the same site. The difference was not explained by developers working less or being less capable. Instead, cross site work involved more people, which created more coordination and longer delays.

The problem is also not that remote teams encounter more obstacles. Research suggests distributed and colocated teams are blocked at similar rates. The difference is how long those blocks take to resolve when a question needs to move between people, teams, or locations.

This does not mean remote development produces worse software. Studies have found little difference in post release failures between distributed and colocated teams. The real cost is time spent waiting for information, decisions, reviews, and clarification.

Adding more meetings is unlikely to solve this. The better approach is to look at how work is divided and where dependencies create unnecessary questions. When teams reduce the number of people required to unblock a piece of work, development can move faster without asking people to work longer hours.

Key stats

In this article

• The month-four problem

• What actually slows a distributed team down?

• What the delay really costs

• The handover protocol

• What to stop doing

• Where we fit, and it is narrower than usual

• Conclusion: Your remote team does not need more hours. It needs fewer waits.

• FAQ

Why does everything take longer than it did in month one?

In the beginning, your remote team may feel fast. New engineers are working on clearly defined tasks, such as building a screen or completing a feature that has already been planned. They can make progress without relying heavily on other people. That changes as the team and product grow.

Engineers gradually become more dependent on each other's work. A task that once involved one person may now require information from another developer, approval from a manager, or clarification from someone in a different timezone. Small questions begin creating delays, especially when the person with the answer is unavailable.

Research by Herbsleb and Mockus found that software work spanning multiple locations took around two and a half times longer to complete than comparable work completed within a single location. The researchers did not attribute this difference to remote developers working less or producing lower quality work. Instead, the evidence pointed to a structural problem: distributed work requires more coordination.

Their earlier research illustrates the difference clearly. Work completed at a single site took an average of around five days from the start of development to the final change. Work involving multiple sites took approximately 12.7 days. The exact figures should not be treated as a universal rule, as the research focused on a particular organisation and was conducted before modern collaboration tools became widespread. However, the underlying problem remains relevant.

The issue is not simply physical distance. It is dependency.

As work becomes more interconnected, people need answers from colleagues who may be working elsewhere. A developer cannot continue until they understand how another part of the system works. A decision cannot be made until the right person responds. A small unanswered question can turn into hours of waiting.

This is why a remote team can appear to slow down even when nobody is working less. The work itself has changed. What began as independent tasks has become interconnected work that crosses people, teams, and locations.

Distributed work is also no longer unusual. Remote and hybrid arrangements are now a standard part of the technology industry, which means the challenge is not whether companies should expect coordination costs. They should. The more important question is how those costs can be reduced.

The answer is not necessarily more meetings or longer working hours. It starts with understanding where questions and dependencies are creating delays, then changing the way work is structured to reduce unnecessary waiting.

If you are still deciding where to build your team rather than trying to improve an existing one, our guide to choosing the right location for your development team covers the geography question separately.

What actually slows a distributed team down?

Distributed teams are not necessarily slower because their developers work fewer hours or have less skill. The main problem is usually much simpler: more people become involved in each piece of work, and questions take longer to get answered.

Research into 2,227 software change requests by Herbsleb and colleagues tested several possible explanations for why work spanning multiple locations took longer. Cross-site changes were not significantly larger, and they did not affect more parts of the codebase. The strongest explanation was the number of people involved. When work crossed sites, more people had to participate, which increased coordination and added delays.

In practical terms, the real cost is often a question that cannot be answered immediately.

The cost of a question

A team can encounter the same number of problems regardless of where its members are located. What changes is how long it takes to resolve those problems.

The 2001 study found that developers experienced a similar number of blocking delays when dealing with colleagues at their own site and colleagues at another site. However, local delays lasted an average of 0.9 days, while cross-site delays lasted 2.4 days.

This distinction matters. A distributed team is not necessarily getting stuck more often. It is spending longer waiting each time it gets stuck.

That means the usual fixes can miss the problem entirely. Adding processes designed to prevent mistakes will not necessarily reduce delays if the real issue is that developers are waiting for answers.

The number of people available to answer a question also matters. In the same research, developers reported interacting with an average of 16 people at their own location each week, compared with just 4.9 people at remote locations. When a question crosses sites, the pool of people who can quickly provide an answer becomes much smaller.

Later research has found a similar pattern. A 2022 study of more than 61,000 Microsoft employees found that remote work made collaboration networks more siloed. Employees communicated more asynchronously and developed fewer connections between different parts of the organisation. This can make it harder for information to move between teams. Time zones can make the problem even more complicated.

A question sent across a geographical distance creates the same physical distance in either direction. Time differences do not work that way. Depending on when a question is asked, one person may receive an answer during their working day while the other has to wait until the next day.

This creates an uneven flow of information. A team may appear to collaborate well in one direction while experiencing significant delays in the other.

Time separation can also increase the cost of misunderstandings. When clarification takes longer, developers may continue working with incomplete information. By the time the misunderstanding is discovered, fixing it can require additional work.

Geography, time zones, and cultural differences can all create coordination problems, but they should not be treated as the same issue. Each creates different types of friction and requires a different solution.

Why more meetings makes it worse

When a distributed team starts slowing down, the instinct is often to add more meetings. This can make the problem worse.

The research suggests that the number of people involved in a piece of work is itself a major contributor to longer completion times. A general status meeting may increase awareness of a problem, but it does not necessarily connect the developer with the person who can answer their question.

Meetings also consume the limited hours when distributed teams are available at the same time. If the only overlapping hour between two locations is spent discussing status updates, there is less time available for solving the problems that actually require synchronous communication.

More communication is not automatically better communication. Research into socio-technical congruence found that work moves faster when communication patterns match the actual coordination needs of the work. In other words, the people who need to coordinate should be able to communicate directly about the specific dependencies affecting them.

That does not mean involving everyone in every discussion. It means reducing unnecessary communication while making it easier for the right people to exchange information when a dependency exists.

For a distributed team, the goal should not be to create more opportunities to talk. It should be to reduce the number of questions that need to cross locations in the first place.

The next step is to examine how work is divided, reduce unnecessary cross-site dependencies, and create handovers that contain the information developers need before they have to ask for it.

窗体顶端

How much overlap do you actually need?

You need enough overlap to prevent a simple blocking question from turning into a full day of waiting.

There is no research that identifies an exact number of overlap hours that every distributed team should have. The available evidence explains why delays happen, but it does not say that four or five hours is the universal answer. Any recommended threshold should therefore be treated as a starting point rather than a proven rule.

The practical goal is straightforward: a developer should be able to ask an important question early enough in their working day to receive an answer before that day ends.

Data from our GitHub API review provides some context for how quickly delays can accumulate. Across 599 merged pull requests with a recorded human review in three large open-source repositories, the median wait for the first human review was six hours. Nearly half waited longer than eight hours, while more than a quarter waited longer than a full day.

These figures should not be used as a benchmark for a paid engineering team. Open-source projects rely on contributors with different levels of availability, and the data does not show where reviewers were located. However, it demonstrates an important point: even highly active software projects can experience long delays between a request and the first human response.

Daily overlap and what it makes possible

These ranges are reasoned from the evidence rather than directly measured by a single study. The important point is not reaching a specific number of overlap hours. It is understanding what happens when a team does not have enough time to resolve questions before someone finishes work for the day.

The difference between projects can also be significant. In the GitHub sample, the median wait for a first review ranged from 2.8 hours in Node.js to 12.7 hours in Kubernetes. This shows that response times are influenced by more than geography. Team practices, reviewer availability, and the way work is coordinated all affect how quickly a question receives an answer.

Why follow-the-sun development is harder than it sounds

Follow-the-sun development appears to offer an obvious solution to timezone differences. One team finishes for the day and hands the work to another team elsewhere, allowing development to continue around the clock.

In practice, this is difficult to make work well.

Research into follow-the-sun development has found relatively few documented examples of successful implementation. The core challenge is the handover. Any time saved by having another team immediately continue the work can be lost if the next team needs time to understand the context, clarify decisions, or correct misunderstandings.

For the model to work, the efficiency gained from continuous development must outweigh the additional coordination created by moving work between locations. That is a demanding requirement.

Later research has also highlighted the lack of strong evidence showing when follow-the-sun development is consistently effective in practice. The concept is possible, but it depends heavily on the quality of handovers and the level of coordination required by the work.

Other research points in the same direction. Teams separated by smaller timezone differences tend to communicate more easily than those with larger gaps. Projects spread across fewer locations can also have fewer coordination challenges than those involving several sites.

This does not mean globally distributed teams cannot work effectively. It means that timezone separation should be treated as a real operational constraint rather than something that can be solved simply by adding another team.

The goal is not to maximise the number of hours someone is working somewhere in the world. It is to minimise the amount of time important work spends waiting for an answer.

What does a good handover look like?

A good handover gives the next person enough context to continue working immediately. They should not have to spend the first part of their day figuring out what happened before they arrived.

This is more important than it may seem. Research by Parnin and Rugaber, which analysed 10,000 programming sessions, found that developers often need significant time to resume work after an interruption. Only 10% of sessions reached the first code edit within a minute, while around 30% took more than 30 minutes before editing began.

If developers need time to return to their own work, a colleague taking over several hours later will need even more context. A ticket title and a commit message are rarely enough.

A handover is therefore not administrative work added on top of engineering. It is part of the engineering process. In a distributed team, a few minutes spent documenting the current state can save hours of reconstruction for the next person.

A useful handover should cover five things.

1. State, not status

Describe what is currently true about the code rather than simply listing what you worked on.

For example, instead of writing, "Worked on the parser," explain the actual state: "The parser now handles nested arrays. The remaining failing case is a null value inside a nested object, which is reproduced by the test I pushed."

The next person should be able to understand where the work stands without reading through every commit.

2. Write the next action clearly

The handover should identify exactly what needs to happen next.

Avoid vague instructions such as "Continue investigating the issue." Instead, provide a specific action that allows the next developer to begin immediately.

For example: "Run the failing test, then determine whether the fix belongs in the tokeniser or the validator."

The goal is to remove the need for the next person to spend time deciding where to start.

3. Include open questions with a suggested answer

This is one of the most valuable parts of a handover.

An unanswered question can stop work completely when the person who knows the context has finished for the day. Instead of simply documenting the question, include your best judgement about the answer.

For example, do not write: "Should this go in the tokeniser or the validator?"

Write: "I think this belongs in the tokeniser because the validator does not see raw input. If you disagree, use the validator and explain the reasoning."

The second version gives the next developer permission to continue. They have context, a suggested direction, and a clear decision to make.

A question with a reasonable default is no longer necessarily a blocking question.

4. Document the dead ends

Explain what you already tried and why it did not work.

This can be brief, but it prevents the next developer from repeating work that has already been done.

For example:

• Tried handling the null value in the validator, but the raw input was unavailable at that stage.

• Tested changing the nested array logic, but it introduced failures in existing object parsing.

Without this information, the next person may spend their morning rediscovering the same problems.

5. Explain how to verify the work

The handover should tell the next person how to confirm whether the eventual solution works.

This could be a command, a named test, a URL, or another clear verification method. The important thing is that the next developer does not have to guess how success is measured.

A good handover should leave behind a clear record of the current state, the next action, unresolved decisions, failed approaches, and the test for success.

The end-of-shift handover

The most important step is documenting open questions with a suggested default. Distributed work becomes slow when progress stops while someone waits for an answer. Giving the next person enough context to make a reasonable decision can remove that wait entirely.

The handover should also live somewhere permanent, such as the ticket or pull request. Chat messages are difficult to find later, especially when someone needs information they did not know they would need.

Finally, write the handover for a competent developer who knows the project but has not been involved in this specific piece of work. Do not assume the usual colleague will always be available. The documentation should allow anyone taking over the task to understand the situation and continue without reconstructing the previous day's work.

窗体底端

What should you stop doing?

The solution to a slow distributed team is not necessarily more communication. It is reducing the dependencies that create the need for communication in the first place.

Research on socio technical congruence found that work was resolved faster when communication matched the actual coordination needs of the work. The important point is that this is about how work is organised, not how many meetings a team attends. The dependencies that mattered most were logical dependencies between pieces of work.

There are several habits worth removing.

Stop trusting responsiveness surveys

People often believe they are just as helpful to remote colleagues as they are to people at their own location. The research suggests that this perception can be misleading.

In the 2001 study, developers reported helping local and remote colleagues at similar rates when workloads increased. However, they also reported receiving considerably less help from remote colleagues.

This creates an uncomfortable problem. Everyone can believe they are being responsive while the team as a whole is still experiencing long waits.

Do not rely on asking people whether they are responsive. Measure how long people actually wait for answers.

Stop measuring velocity when the problem is waiting

Velocity can tell you how much work was completed. It does not tell you how much time that work spent waiting.

A distributed team can maintain its output while taking longer to finish each piece of work. The delay is hidden inside the calendar rather than the amount of work completed.

Track blocked time instead.

Record when someone stops because they are waiting for another person, what they are waiting for, and when they can continue. You do not need an elaborate dashboard to start. A simple shared record maintained for a couple of weeks can reveal which dependencies are creating the longest delays.

Stop assuming remote work produces worse code

The evidence does not support making code quality the central problem.

Research examining Windows Vista compared post release failures in components developed by distributed teams with those developed by colocated teams. The researchers found only a negligible difference in failures, with the difference becoming even smaller after accounting for the number of developers working on each component.

The important distinction is that distributed development can take longer without producing worse software.

If your problem is delivery speed, focus on the calendar. Do not spend your energy trying to fix a quality problem that the evidence does not clearly show exists.

Stop using overlap for status updates

Synchronous overlap is one of the most valuable resources a distributed team has. Do not spend it reading out information that could have been written down.

Put status updates in the ticket or project system. Use the shared working window for problems that genuinely benefit from an immediate conversation.

For example, start the overlap period by working through the questions left in the previous shift's handovers. Resolve the decisions that are blocking progress, then let everyone return to their work.

The goal is not more meetings. It is making the limited time when everyone is available useful.

Stop splitting work across sites unnecessarily

Avoid dividing a feature between locations simply because different skills happen to exist at each site.

When possible, give one site ownership of a feature from beginning to end. This reduces the number of handovers and dependencies that have to cross locations.

Sometimes a workstream genuinely needs to be divided. When that happens, create the boundary around an established interface or contract rather than splitting the work arbitrarily. That contract then becomes part of the system and needs clear ownership.

• The broader lesson

The broader lesson is simple: reduce the number of questions that have to cross a timezone.

There is an important limitation to the evidence. Not every study in this area is equally accessible, and some later research was designed specifically to test whether modern collaboration tools and processes could overcome the delays identified in earlier studies. That means the underlying mechanism is well supported, but the exact size of the effect should not be treated as universal.

The practical response is therefore not to assume that every distributed team will experience the same delay. Measure your own team's blocked time, identify where work is crossing locations, and remove the dependencies that repeatedly force people to wait for one another.

Where we fit, and it is narrower than usual

If you already have a distributed team, the question is not whether you should hire one. It is whether the timezone gap is creating enough delay to justify changing how the team works.

The evidence in this article points to a straightforward solution. When distance creates long waits for answers, reducing that distance reduces one source of delay. RocketDevs staffs teams with 100% EU timezone overlap, which removes the timezone gap described in this article. This is a description of how the teams are structured, not an argument that you should replace your existing developers.

Start with the changes that cost nothing. Use the handover process. Track blocked questions. Where practical, keep an entire workstream on one side of the timezone gap. These changes can show you whether the problem is actually the distribution of the team before you make a larger decision.

If the data still shows that timezone separation is causing significant delays, then the timezone gap may be the problem worth addressing. For teams considering a larger restructure, our guides cover building a dedicated development team and building a technology team for a startup.

Conclusion: Your remote team does not need more hours. It needs fewer waits.

Remote work is often blamed when software delivery starts taking longer. The evidence tells a more useful story.

The problem is not that your developers suddenly became less productive when they stopped sitting in the same building. It is not that remote engineers care less, work fewer hours, or necessarily produce lower quality software. The problem is what happens between the moments when one person needs something and another person can provide it.

A question becomes a wait. A wait becomes a delay. A delay creates another dependency, another handover, or another piece of work that has to be reconstructed later. Once enough of these delays accumulate, your team can look slow even when everyone is working hard. This is why adding more communication is rarely the first answer.

More meetings do not automatically create faster decisions. More messages do not guarantee that the right person will see them. More overlap does not help if everyone spends it giving status updates. A distributed team can communicate constantly and still spend large parts of its day waiting. The better approach is to make the work easier to coordinate.

Start by looking at where your team gets blocked. Record the questions that stop work and measure how long they take to resolve. Look for work that repeatedly crosses timezones. Find the dependencies that force developers to wait for someone who has already finished their day, then remove what you can.

Keep related work together where possible. Give one location ownership of an entire workstream instead of creating unnecessary handovers. Put decisions and context somewhere the next person can find them. Make every end of shift handover good enough that the next developer can start working rather than spend their morning reconstructing what happened.

Use synchronous time carefully. If everyone is available at the same time, use that window to resolve the problems that genuinely need a conversation. Everything else can be written down. Under no circumstance start by changing your entire team.

The cheapest fixes are also the most informative. Try the handover protocol. Track blocked questions. Move a workstream across the timezone boundary if the evidence shows that the boundary is creating unnecessary waits. Give those changes enough time to produce useful data.

If the delays remain, then you have something much more valuable than a feeling that remote work is slow. You have evidence showing where the calendar is being lost.

That changes the decision. You do not need to ask whether remote work works. You need to ask whether the way your particular team is distributed creates more coordination cost than the arrangement is worth.

Sometimes the answer will be no. A well structured distributed team can work effectively across locations. Sometimes the answer will be yes. If a timezone gap repeatedly turns simple questions into overnight delays, changing the distribution of the team may be the most practical solution. The important thing is to change the right thing.

Do not make people work longer to compensate for a coordination problem. Do not fill their calendars with meetings to compensate for missing context. Do not measure the wrong numbers and conclude that the team is underperforming.

Measure the wait as that is where the time is going.

Your remote team is not necessarily slower. Your questions are taking longer to get answered. Fix the questions, remove the unnecessary dependencies, and give people enough overlap to keep work moving.

Frequently asked questions

Why does remote work take longer than in office work?

Remote work can take longer because work that crosses locations often involves more people. More people create more coordination points, which can increase the time needed to complete a task.

Research by Herbsleb and Mockus found that cross site work took around two and a half times longer than comparable work completed at one location. Their analysis also found that the difference was not simply because remote work was larger or involved more parts of the codebase. The evidence points to coordination as the main source of delay.

How many hours of timezone overlap do you actually need?

You need enough overlap for a blocking question asked at the beginning of someone's working day to receive an answer before that person finishes work.

There is no published study that establishes a universal number of overlap hours. Two to three hours can provide a useful starting point, while four or more hours gives teams more opportunity to resolve questions during the same working day.

The best way to determine what your team needs is to measure it. Track blocking questions for a couple of weeks and record how long each one takes to resolve. This will show whether your current overlap is creating meaningful delays.

Is follow the sun development worth it?

Usually, it is difficult to make follow the sun development work efficiently.

Research has found relatively few documented examples of successful implementation. The main problem is the handover between locations. Any time gained by allowing another team to continue working can be lost if that team has to reconstruct the previous team's decisions or resolve misunderstandings.

If you are considering this approach, improve your handover process first. Measure how much time is actually saved before restructuring your team around continuous coverage.

How do you hand over work at the end of a shift?

A useful handover should explain the current state of the work rather than simply describing what you did. It should identify the next action, document open questions with your best suggested answer, record approaches that have already failed, and explain how the next person can verify the result.

Allow around ten to fifteen minutes for the handover once the process becomes routine.

This is worthwhile because resuming work takes time even when the developer is returning to their own code. Research by Parnin and Rugaber found that only 10% of programming sessions reached a first edit within a minute, while around 30% took more than half an hour to reach that point.

Someone taking over your work later will need enough context to avoid repeating that reconstruction process.

Should a remote team have daily standups?

A daily standup can be useful, but it should not consume the team's most valuable overlap period simply to exchange status updates.

Research on distributed development suggests that coordination works better when communication matches the actual needs of the work. The people who need to coordinate should be able to communicate about the specific dependencies affecting them.

Put routine status information in writing instead. Use the shared working window for questions that genuinely require a live conversation.

The goal is not to eliminate communication. It is to make sure the communication you do have removes a real blocker rather than simply reporting that the blocker exists.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Herbsleb and Mockus, An empirical study of speed and communication in globally distributed software development, IEEE Transactions on Software Engineering 29(6), 2003

• Herbsleb, Mockus, Finholt and Grinter, An Empirical Study of Global Software Development: Distance and Speed, ICSE 2001

• Herbsleb and Mockus, Retrospective, IEEE Transactions on Software Engineering 51(3), 2025

• Crossref bibliographic record for the 2003 paper

• Cataldo, Herbsleb and Carley, Socio-technical congruence, ESEM 2008

• Espinosa and Carmel, The impact of time separation on coordination in global software teams, Software Process: Improvement and Practice 8(4), 2003

• Carmel, Espinosa and Dubinsky, Follow the Sun Workflow in Global Software Development, Journal of Management Information Systems 27(1), 2010

• Kroll, Richardson, Prikladnicki and Audy, Empirical evidence in follow the Sun software development, Information and Software Technology 93, 2018

• Bird, Nagappan, Devanbu, Gall and Murphy, Does distributed development affect software quality? An empirical case study of Windows Vista, ICSE 2009

• Nguyen, Wolf and Damian, Global Software Development and Delay: Does Distance Still Matter?, ICGSE 2008

• Yang, Holtz, Jaffe, Suri and colleagues, The effects of remote work on collaboration among information workers, Nature Human Behaviour 6(1), 2022

• Parnin and Rugaber, Resumption Strategies for Interrupted Programming Tasks, ICPC 2009

• Holmstrom, O Conchuir, Agerfalk and Fitzgerald, Global Software Development Challenges, ICGSE 2006

• Nordio, Estler, Meyer, Tschannen, Ghezzi and Di Nitto, How Do Distribution and Time Zones Affect Software Development?, ICGSE 2011

• Looi and Szepan, Outsourcing in Global Software Development: Effects of Temporal Location and Methodologies, IJBSS 12(3), 2021

• Stack Overflow Developer Survey 2025, work section

• Eurostat, employed persons working from home, dataset lfsa_ehomp

• GitHub GraphQL API, pull request object reference

• Wikimedia pageviews API, Asynchronous communication